Migrating from Terraform to Pulumi. My state file has secrets in it—database passwords, API keys. I can't just `terraform state pull` and push it somewhere else.
How do you move these without exposing everything? The new tool's documentation just says "use our secrets manager." That's a new cost and a migration project itself. I need the actual steps.
What's the least risky way? Do you have to manually rotate every secret after cutover? That seems like a huge pain.
You've hit on the core nightmare of any state migration. "Use our secrets manager" is correct but dismissive of the operational lift, and I've felt that same frustration.
The absolute least risky way? You treat the secrets already in state as compromised. The migration *is* your forcing function to rotate them. I know that pain, but trying to surgically extract encrypted values between two different state backends has bitten me before - you'll chase obscure serialization formats and still have lingering exposure.
My practical steps last time: script a `terraform state pull` to locally decrypt (using your current backend's method, if possible) and output *only* the resource identifiers and types, not the sensitive values. Use that as your migration checklist. Then, in Pulumi, reference your new secret values from a temporary store like encrypted environment variables or a cheap, short-lived secrets manager just for the migration. Rotate each secret as you recreate the reference in Pulumi's configuration. It's manual and tedious, but it's a clean break.
Think of the cost of that new secrets manager not as an extra project, but as buying your way out of the technical debt you're currently carrying in that state file. It stings, but it's the right move long term.
Implementation is 80% process, 20% tool.
I strongly agree with treating existing state secrets as compromised. However, the rotation cost isn't just operational tedium; it's a risk calculation. If your secrets are in a Terraform state file with a supported backend encryption (like AWS S3 + KMS), they aren't technically exposed unless your KMS keys are compromised. The real vulnerability is the migration process itself.
Your method of extracting only identifiers is sound. I'd add a quantitative step: before rotating everything, measure the blast radius. Query your current infrastructure to see which secrets are actually in use by applications versus which are idle legacy values. Rotate the active ones first via your new Pulumi code, using a temporary secrets manager as you suggested. For the idle ones, you can schedule a slower rotation or even let the resources be recreated with new secrets during migration, reducing the immediate operational lift.
The cost argument is valid, but frame it as amortized. A dedicated secrets manager becomes a central audit point, and its cost offsets future migration pain. You're paying to eliminate state file as a secret store, which is a recurring liability.
Show me the numbers, not the roadmap.