Pulumi Secrets
You manage pulumi secrets by marking sensitive values during setup so the state file encrypts them. The tool uses a chosen key provider to lock and manage these values during each run. Most teams start by storing database passwords and API tokens right inside their stack files. This setup works well until broad team roles let too many people decrypt state files. How pulumi secrets work in your stack Every project uses a stack file to store settings and a state file to track resources. When yo
K8s Secrets Management + Pulumi Policy as Code: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You manage pulumi secrets by marking sensitive values during setup so the state file encrypts them. The tool uses a chosen key provider to lock and manage these values during each run. Most teams start by storing database passwords and API tokens right inside their stack files. This setup works well until broad team roles let too many people decrypt state files.
How pulumi secrets work in your stack
Every project uses a stack file to store settings and a state file to track resources. When you mark a value as a secret, the engine encrypts that plain text right away. It writes only the cipher text into your state file and your project settings. Each stack gets its own unique salt or uses a cloud key management service.
During an update, the engine reads the encrypted value and asks the key provider to manage it. The unlocked value stays in memory only while the engine talks to your cloud provider. You can use the default service key or bring your own key from a cloud provider. You can also use a local passphrase when you test things on a laptop.
The engine tracks that secret marker as the value moves from one resource to another. If you pass a secret database password into an app setting, the output stays encrypted too. This tracking stops plain text keys from showing up in terminal logs during a plan.
Choosing a key provider for your team
Teams need to pick a key provider before they create a new stack for an app. The default service handles keys for you and links permissions to your team account roles. Many companies prefer to use a cloud key service from AWS, Azure, or Google Cloud. Using a cloud key lets you manage rotation rules and audit logs in one place.
When you switch key providers, you must re-encrypt all existing secrets in that stack file. Every engineer and build runner needs permission to use that specific cloud key during a run. If a build runner lacks permission to use the key, the deployment fails right away. Teams often share one broad cloud role across many stacks to avoid permission errors. That shortcut makes setup fast, but it gives every project access to every secret key.
K8s Secrets Management + Pulumi Policy as Code: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native state encryption solves and what it misses
Native state encryption solves the big problem of plain text keys sitting in code repos. Your team can commit stack files to git without leaking API tokens to the whole company. It also keeps secrets out of standard build logs when your pipeline runs a preview.
Still, state encryption only protects values while they sit at rest inside your state files. Once an engineer or runner can decrypt the stack, they can export the plain text values. Anyone with state read access and key permissions can view the database password or cloud token. The native setup decides who can manage the stack, not what commands they run next.
When an engineer needs to fix a live database or check a cluster, they often grab credentials from the stack. Once they log in with that password, the deployment tool cannot see what queries they run. It cannot mask emails, phone numbers, card numbers, or national IDs in query results. It also cannot ask a manager to approve a risky command before it runs in production.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Do pulumi secrets stay encrypted inside the state file?
Yes, the engine encrypts all marked secret values before it writes them to the state file. Plain text values only exist in memory while a deployment or preview command is running.
What happens if a secret value is not marked before deployment?
The engine saves unmarked values as plain text in both the stack file and state file. You must mark the value as a secret and rotate the exposed credential right away.
Can engineers read plain text secrets if they have stack access?
Yes, anyone with permission to use the encryption key can export the decrypted stack config. Native encryption protects files at rest, not how users use credentials after unlocking them.