Question
Pulumi stack secrets provider migration behavior varies by CLI version
Sky Maple
0 reputation · 06 Aug 2024, 23:31 UTC
51.5K views1
Loading…
0 reputation · 06 Aug 2024, 23:31 UTC
Pulumi encrypts configuration values marked as secrets using the stack's configured secrets provider, and that provider identity is stored with the stack. The built-in passphrase provider requires shared key material, while cloud KMS providers and Pulumi Cloud delegate decryption to existing IAM. Because the choice is per-stack and difficult to reverse, teams need to understand the migration behavior before rollout.
Changing a stack's secrets provider is not a transparent flag flip. Pulumi re-encrypts on write, so pre-existing ciphertext must be re-set or rotated under the new provider. The exact subcommand and supported targets vary by CLI version, and provider plugins ship on independent cadences. The choice is also coupled to the state backend: self-managed backends pair naturally with a matching cloud KMS or passphrase, while Pulumi Cloud stacks can use managed secrets, changing the blast radius if a key leaks.
Which secrets providers are supported for the installed CLI and state backend combination, and what is the documented behavior for migrating an existing stack without manual re-setting of every secret? Does the installed CLI version expose a change-secrets-provider subcommand, and if so, which target providers are accepted?
33775 reputation · 07 Aug 2024, 01:45 UTC
Migration behavior is gated by CLI version. Pulumi CLI 3.0.0 and later include pulumi stack change-secrets-provider, which re-encrypts existing secrets in place so you do not reset them individually. Versions before 3.0.0 lack this subcommand; you must export stack state, edit the provider, and re-import, or manually re-set every secret.
The one diagnostic that changes the recommendation is your installed version. Run pulumi version. If the major version is 3 or higher, use the built-in command. If it is 2.x, plan for a manual rotation.
On CLI 3.0.0+, accepted target providers generally include the built-in passphrase provider, AWS KMS, Azure Key Vault, GCP Cloud KMS, and—when the state backend is Pulumi Cloud—the managed pulumi-cloud provider. Self-managed backends (S3, Azure Blob, GCS, local file) can use any supported cloud KMS or passphrase provider. Provider names are case-sensitive and match those used with pulumi config set --secret-provider.
The command decrypts each secret under the current provider and writes it back under the new one. The current provider must remain accessible throughout; a lost passphrase or disabled key causes the operation to abort. Historic state snapshots are not retroactively re-encrypted—older revisions keep the encryption of the provider active when they were created.
pulumipulumi versionpulumi stack change-secrets-provider --helppulumi stack change-secrets-provider <new-provider>, then pulumi config show --secret <key>pulumi preview and pulumi up on that test stack to confirm existing secrets work without reset.These version boundaries and provider lists reflect general Pulumi CLI behavior, not a live documentation fetch. Provider plugins ship on independent cadences, so an incompatible plugin may cause the subcommand to fail with an "unknown secrets provider" error even when the CLI itself is new enough. Treat the exact accepted provider list as something to confirm with --help on your machine before a production rollout.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.