cloudposse/atmos v1.222.0-rc.6

on GitHub

• Add a Custom entry to the Component Library so command-backed custom component types are discoverable alongside Terraform/OpenTofu, Helmfile, Packer, and Ansible.
• New page website/docs/components/custom.mdx explaining custom component types (with a minimal Script Runner example and a native-vs-custom comparison), linking to the existing reference and changelog rather than duplicating them.
• Wire the new page into the Component Library sidebar (website/sidebars.js) after Ansible.
• Surface custom types in the Component Library overview (components-overview.mdx) — a pointer under the Component Types table and a Next Steps bullet.

why

• Custom component types already shipped and are fully documented under cli/configuration/commands#custom-component-types, but a user browsing the Component Library never saw them as a first-class option — the nav didn't match the actual capability.
• This is a docs-only change (no-release): no behavior changes, and the feature already has its own changelog post.

references

• Reference: /cli/configuration/commands#custom-component-types
• Changelog: /changelog/custom-component-types

Summary by CodeRabbit

• Documentation
  • Added a new guide for Custom Component Types, explaining how to define custom component types via custom commands and how stack manifests resolve components.<type>.<name> for use in templates.
  • Documented how merged vars, settings, and env are made available to templates.
  • Expanded the components overview to point to Custom Component Types as an additional learning path.
  • Updated navigation and the file-browser doc links to include the new page and its reference.
  • Refreshed CLI command docs to reflect the updated built-in component types list.

• Add an optional description field to component metadata.
• Update the embedded, test-fixture, and published website JSON schemas to allow metadata.description.
• Document the field in the component metadata reference and quick-start guides, and demo it in the quick-start example.
• Add a schema validation test (pkg/datafetcher/schema_metadata_validation_test.go) verifying both the embedded and website schemas accept metadata.description.
• Add a changelog blog post and a shipped roadmap milestone.

why

• Lets users document the purpose of a component inline, right next to its configuration — especially useful when many components share the same Terraform root module with different configs.
• The field is purely informational: it does not change how a component is processed, planned, or applied, so the change is safe and additive (component metadata is already a free-form map at runtime, so no Go changes were required).
• Schema support gives editors auto-completion and validation for the new field.

references

• Component metadata docs: /stacks/components/component-metadata

Summary by CodeRabbit

Release Notes

• New Features

  • Added an optional metadata.description field for components, allowing human-readable descriptions to appear in listings and editor validation.

• Documentation

  • Updated quick-start and component metadata docs, plus examples, to show how to set metadata.description.
  • Added a blog post explaining the field and where it belongs in stack YAML.

• Tests

  • Added schema validation test coverage to confirm metadata.description is accepted and validated.

• Chores / CI

  • Improved YAML schema validation in the test workflow by using the in-repo schema and adjusting schema modelines for examples.

• Make atmos secret list require no authenticated identity and never decrypt — it only reports whether each secret is set. On a 72-component stack, listing drops from ~21–34s (it previously authenticated every component and decrypted every secret) to effectively instant.
• Disable per-component authentication during secret-list stack enumeration.
• Resolve SOPS initialization status from the file's cleartext key names — no age key, no decryption.
• Rewrite every store's existence check (Has) to a non-decrypting metadata API: SSM GetParameter with WithDecryption=false, Secrets Manager DescribeSecret, GCP GetSecretVersion, Azure Key Vault properties pager, Vault KV metadata read, and a no-reveal 1Password check.
• Add a tri-state STATUS (initialized / missing / unknown) plus a new --verify flag: remote-store status shows unknown by default; --verify contacts backends with a read/describe identity (never a decrypt identity) on a fully-scoped target.

why

• Listing is introspection — it shows which secrets are declared and whether they exist, and never needs a plaintext value, so it should not force authentication or decryption (or require kms:Decrypt-style permissions).
• The old path authenticated per component and fetched+decrypted every secret just to populate the status column, making secret list slow (and prone to hanging) on real-world stacks and unusable without cloud credentials.
• Existence on a remote store still needs a read credential, so those rows now default to unknown (credential-free) and opt into a real check via --verify, while local backends (SOPS) always show accurate status for free.

references

• Supersedes the per-component auth-cache approach in #2644 (its atmos secret list workload is fully addressed here); follows #2642.
• Docs: website/docs/cli/commands/secret/list.mdx; changelog: fast-credential-free-secret-list.

Summary by CodeRabbit

Release Notes

• New Features

  • Added --verify to atmos secret list for authoritative remote initialization checks; remote-backed secrets now show real status when enabled.

• Bug Fixes

  • Improved secret listing to be credential-free by default (no value retrieval/decryption). Remote-backed secrets display unknown unless verified.
  • Standardized “initialized/missing/unknown/error” status behavior and unknown label rendering.

• Documentation

  • Updated atmos secret list docs and added a blog post covering the fast credential-free flow.

• Tests

  • Added coverage for --verify, unknown status, and credential-free/metadata-only existence checks.

• atmos secret and !secret (during terraform plan) against a SOPS cloud-KMS backend now authenticate using the Atmos identity — --identity / ATMOS_IDENTITY, the per-provider secrets.providers.<name>.identity, or the stack/component effective identity — instead of requiring ambient cloud credentials.
• The cloud is inferred from the SOPS file's master-key type at runtime (AWS KMS / GCP KMS / Azure Key Vault); there is no per-cloud kind. Credentials are injected into the in-process getsops encrypt/decrypt via ApplyToMasterKey (no process-environment mutation).
• Refactors SOPS into its own package pkg/secrets/providers/sops/ with a registry of per-cloud key handlers (aws.go / gcp.go / azure.go); the cloud-SDK credential building lives in the depguard-exempt pkg/store/sopsauth/ bridge so the SOPS package imports no cloud SDK directly.
• Threads the auth resolver + effective identity to the provider via a transient AtmosConfiguration.SecretsAuth seam, populated in both the atmos secret and terraform code paths.
• Fixes the SOPS decrypt error to emit identity/permission hints for cloud-KMS files (derived from the file's actual key types) instead of the misleading age-key hint.

why

• Resolves #2637: the documented secrets.providers.<name>.identity field and --identity were silently ignored for the SOPS cloud-KMS track, forcing every command to be wrapped in atmos auth exec even though Track-1 stores (SSM/ASM/Key Vault/Secret Manager) already authenticated via the identity.
• The fix is additive and backward compatible: with no resolvable identity, the SOPS provider falls back to the ambient credential chain exactly as before. kind remains only for the legitimate age-vs-KMS keygen distinction.
• Covered by a Floci KMS end-to-end test (ambient AWS creds cleared, identity-only secret set/get — the exact #2637 scenario, RED before this change) plus unit tests for key-service selection, per-cloud registry dispatch, identity precedence, and kind-aware error hints.

references

• Closes #2637
• docs/fixes/2026-06-20-sops-cloud-kms-identity.md (root cause, fix, and full backend audit)

Summary by CodeRabbit

• New Features
  • Added identity-aware SOPS secret backends for AWS KMS, GCP KMS, and Azure Key Vault.
  • Added backend-agnostic key generation support for secret providers.
• Bug Fixes
  • Fixed cloud KMS SOPS authentication so atmos secret and Terraform execution (including !secret during terraform plan) use the Atmos effective identity instead of ambient credentials.
  • Improved SOPS key-service routing and decrypt/encrypt error hints for cloud KMS vs age.
• Documentation
  • Documented cloud KMS identity precedence and updated SOPS secrets configuration guidance.
• Tests
  • Added/updated identity-selection and SOPS KMS unit tests, plus a Floci KMS end-to-end test.

• Add an Atmos media kit page, blog announcement, brandkit redirect, and generated ZIP download workflow.
• Add logo, wordmark, animated gradient, Atmos CI, and Atmos AI SVG variants for light and dark surfaces.
• Update native Terraform CI summaries and fixtures to use the Atmos CI lockup linking to https://atmos.tools/ci.

why

• Provide a canonical source for Atmos brand assets and usage guidance.
• Align CI summary branding with Atmos instead of the Cloud Posse logo.
• Keep animated treatment assets downloadable and consistent across docs, media kit, and CI output.

references

• Validation: go test ./pkg/ci/plugins/terraform
• Validation: pnpm exec docusaurus build

Summary by CodeRabbit

• New Features
  • Added an Atmos Media Kit page with a downloadable ZIP, logo previews, brand color palettes, and usage guidance.
• Documentation
  • Announced the Atmos Media Kit and added a Media Kit link to the website sidebar, plus a /brandkit redirect to /media-kit.
• Chores
  • Updated website build/dev flow and media-kit generation, increased Node memory for local runs, refreshed site footer/nav layout, and improved Pro logo sizing.
  • Updated CI plan/apply and GitHub step summaries to use Atmos CI gradient branding.
• Tests
  • Updated template and golden-file expectations to match the new Atmos CI branding.