Pulumi Blog: Claire Gaestel

Now Generally Available: Store Terraform State in Pulumi Cloud

Claire Gaestel — Thu, 05 Mar 2026 00:00:00 +0000

Platform engineering teams managing infrastructure across Terraform and Pulumi now have a way to unify state management without rewriting a single line of HCL. Starting today, Pulumi Cloud can serve as a Terraform state backend, letting you store and manage Terraform state alongside your Pulumi stacks. Your team continues using the Terraform or OpenTofu CLI for day-to-day operations while gaining the benefits of Pulumi Cloud: AI-powered infrastructure management with Pulumi Neo — our infrastructure agent — encrypted state storage, update history, state locking, role-based access control, audit policies, and unified resource visibility through Insights.

This feature is now generally available.

Why this matters

Most organizations adopting Pulumi are not starting from scratch. They have years of Terraform deployments spread across teams, and migrating everything to a new IaC tool overnight is not realistic. We have heard from customers who are excited about the power of Pulumi Cloud but have had to manage migration projects before they can fully benefit from centralized visibility and governance.

The Terraform state backend in Pulumi Cloud changes that equation. Instead of requiring a full code conversion before teams see value, you can migrate your state in minutes and immediately unlock Pulumi Cloud capabilities for your existing Terraform infrastructure — including Neo, Pulumi’s AI infrastructure agent. Once your Terraform state is in Pulumi Cloud, Neo can reason about those resources the same way it does for Pulumi IaC stacks: finding resources, troubleshooting issues, understanding dependencies, and writing infrastructure code PRs. Teams that prefer Terraform can keep using it, while platform engineers get a single AI-powered control plane across the entire infrastructure estate.

What you get

When you store Terraform state in Pulumi Cloud, your Terraform-managed resources get the following added functionality:

Agentic infrastructure with Neo. Neo, Pulumi’s AI infrastructure agent, works across your entire cloud footprint — Terraform and Pulumi IaC alike. Once your Terraform state is in Pulumi Cloud, you can ask Neo to find resources across both tools, trace dependencies that span Terraform and Pulumi stacks, troubleshoot configuration issues, and generate new infrastructure code informed by your existing resources. This means platform teams get a single AI-powered interface regardless of which IaC tool manages each piece of infrastructure.

Encrypted state with update history. State is encrypted in transit and at rest. Every change is tracked as a versioned checkpoint visible in the stack activity tab, giving you full rollback capability. This is a common concern for teams currently storing state in S3 buckets.

Automatic state locking. Pulumi Cloud prevents concurrent Terraform operations from corrupting state, without requiring you to configure DynamoDB tables or other external locking mechanisms.

Role-based access control. Control who can read or modify each stack using teams and RBAC, applying the same access policies you use for Pulumi stacks.

Unified resource visibility. View Terraform-managed resources alongside Pulumi-managed resources in Resource Search. Each Terraform resource appears in the console using a pulumi:terraform:<tf-type> naming convention, so you can search and filter using the attribute names you already know.

Audit policies. Run audit (detective) policy packs against your Terraform-managed stacks, including Pulumi’s pre-built compliance packs for CIS, PCI, and more. Pulumi Cloud performs a best-effort schema mapping from Terraform resource shapes to Pulumi provider equivalents, so existing policy packs work without modification in most cases.

Stack outputs and references. Terraform root module outputs are automatically mapped to Pulumi stack outputs, making them available via stack references and the pulumi-stacks ESC provider. This is useful for sharing foundational infrastructure like VPC IDs or DNS zones between Terraform and Pulumi stacks, and for incremental migrations where legacy infrastructure stays in Terraform while new stacks are written in Pulumi.

How it works

Pulumi Cloud implements the Terraform remote backend API. You point the Terraform CLI at Pulumi Cloud using the standard backend "remote" configuration block, and no changes to your Terraform code or workflow are required.

Each Terraform workspace maps to a Pulumi stack. The workspace name follows the convention <project>_<stack>. For example, networking_prod creates a stack named prod in the networking project.

Get started

Migration from S3, Azure Blob, GCS, local backends, or HCP Terraform (Terraform Cloud) takes minutes and is documented in the Terraform state backend guide. From S3, Azure Blob, GCS, or local state, back up your state, update your backend block to point to Pulumi Cloud, set TF_TOKEN_api_pulumi_com, and run terraform init -migrate-state. From HCP Terraform, export state manually and push it to Pulumi Cloud.

Each Terraform resource stored in Pulumi Cloud counts as a resource under management, the same as a Pulumi-managed resource. See the pricing page for details.

Store Terraform State in Pulumi Cloud

If you have questions or feedback, join us in the Pulumi Community Slack or open an issue on GitHub.

Introducing the Terraform State Provider for Pulumi ESC

Claire Gaestel — Fri, 13 Feb 2026 00:00:00 +0000

Many organizations have years of infrastructure built and managed with Terraform. Outputs such as VPC IDs, subnet lists, database endpoints, and cluster names are the connective tissue between infrastructure layers. Getting those values into other tools and workflows often means manual copy-paste, wrapper scripts, or brittle glue code.

The terraform-state provider for Pulumi ESC helps bridge that gap. It reads outputs directly from your Terraform state files and makes them available as first-class values in your ESC environments — no scripts, no duplication, no drift. Any output marked as sensitive in your Terraform state is automatically treated as a secret in ESC. If you’ve used pulumi-stacks to read outputs from Pulumi stacks, this is the same idea for Terraform.

How it works

The terraform-state provider uses fn::open::terraform-state to read from a Terraform state file and surface its outputs as ESC values. Here’s an example that reads from an S3 backend, using the aws-login provider for credentials, and exports a KUBECONFIG for an EKS cluster managed by Terraform:

values:
 terraform:
 fn::open::terraform-state:
 backend:
 s3:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/esc-oidc
 sessionName: pulumi-environments-session
 bucket: my-terraform-state-bucket
 key: path/to/terraform.tfstate
 region: us-west-2
 files:
 KUBECONFIG: ${terraform.outputs.kubeconfig}

Once the environment is opened, terraform.outputs contains every output from the Terraform state. In this example we take the kubeconfig output from a Terraform-managed EKS cluster and project it as a file, so any tool that reads KUBECONFIG - kubectl, helm, Pulumi - just works. You can also reference outputs in pulumiConfig to pass values like VPC IDs and subnet lists directly into Pulumi stacks.¹

Terraform Cloud support

If your state lives in Terraform Cloud (or any compatible remote backend), the provider supports that too:

values:
 terraform:
 fn::open::terraform-state:
 backend:
 remote:
 organization: my-terraform-org
 workspace: my-workspace
 token:
 fn::secret: tfc-token-value
 pulumiConfig:
 vpcId: ${terraform.outputs.vpc_id}
 subnetIds: ${terraform.outputs.subnet_ids}

You can point it at any Terraform Cloud-compatible backend by setting the optional hostname property.

Get started

Check out the full terraform-state provider documentation for the complete reference.

You can also consume Terraform outputs directly in a Pulumi program with the Pulumi Terraform provider. ↩︎

Schema Validation Comes to Pulumi ESC with fn::validate

Pablo Terradillos — Thu, 12 Feb 2026 11:00:00 -0300

Pulumi ESC environments can now validate configuration values against JSON Schema with the new fn::validate built-in function. Invalid configurations are caught immediately when you save, preventing misconfigurations from reaching your deployments.

Configuration errors are often discovered too late during deployment or, worse, in production. With fn::validate, you define validation rules directly in your environment, and ESC enforces them at save time. If a value doesn’t match its schema, the environment cannot be saved until the issue is resolved.

How it works

The fn::validate function takes a JSON Schema and a value. If the value conforms to the schema, it passes through unchanged. If not, ESC raises a validation error.

values:
 port:
 fn::validate:
 schema: { type: number, minimum: 1, maximum: 65535 }
 value: 8080

This validates that port is a number between 1 and 65535. The evaluated result is simply 8080.

Validating objects with required fields

For complex configurations, you can enforce structure and required fields:

values:
 database:
 fn::validate:
 schema:
 type: object
 properties:
 host: { type: string }
 port: { type: number }
 name: { type: string }
 required: [host, port, name]
 value:
 host: "db.example.com"
 port: 5432
 name: "myapp"

If any required field is missing or has the wrong type, the environment cannot be saved.

Reusing schemas across environments

Define schemas once and reference them across multiple environments. Using the environments built-in property keeps the schema out of your environment’s output:

Schema environment (my-project/schemas)

values:
 database-schema:
 type: object
 properties:
 host: { type: string }
 port: { type: number }
 required: [host, port]

Environment using the schema

values:
 database:
 fn::validate:
 schema: ${environments.my-project.schemas.database-schema}
 value:
 host: "prod-db.example.com"
 port: 5432

This pattern ensures consistent validation rules across teams and projects.

What happens when validation fails

When a value doesn’t conform to its schema, ESC returns a clear error message:

values:
 port:
 fn::validate:
 schema: { type: string }
 value: 8080

This raises: expected string, got number. The environment cannot be saved until you fix the value or update the schema.

When to use schema validation

Enable fn::validate for:

Values with specific type requirements (numbers, strings, arrays)
Objects that must have certain fields present
Numbers that must fall within a valid range
Configurations shared across multiple environments
Any value where catching errors early prevents downstream issues

Getting started

The fn::validate function is available now in all Pulumi ESC environments. Add schema validation to your existing environments or use it when creating new ones.

For more information, see the fn::validate documentation.

Announcing OpenAPI support for the Pulumi Cloud REST API

Davide Massarenti — Thu, 05 Feb 2026 00:00:00 +0000

We’re thrilled to announce that the Pulumi Cloud REST API is now described by an OpenAPI 3.0 specification, and we’re just getting started.

This is a feature that has been a long time coming. We have heard your requests for OpenAPI support loud and clear, and we’re excited to share that not only do we have a published specification for consumption, but our API code is now built from this specification as well. Moving forward, this single source of truth unlocks better tooling, tighter integration, and a more predictable API experience for everyone.

You can fetch the spec directly from the API at runtime or use it for client generation, validation, and documentation, all from one machine-readable contract.

A single contract for the Pulumi Cloud REST API

The Pulumi Cloud API powers the Pulumi CLI, the Pulumi Console, and third-party integrations. Until now, there was no single, published machine-readable description of that API. We’ve changed that. The API is now defined and served as a standard OpenAPI 3.0.3 document.

Runtime discovery: You can retrieve the spec from the API itself, so your tooling always sees the same surface the service implements.
Client generation: Use your favorite OpenAPI tooling (e.g. OpenAPI Generator, Swagger Codegen) to generate API clients in the language of your choice.
Validation and testing: Validate requests and responses, or build mocks and tests, from the same spec the service uses.
Documentation: The spec is the source of truth, not a separate, hand-maintained API doc that can drift from reality. Load the spec into Swagger UI, Redoc, or another viewer to browse the Pulumi Cloud API interactively.

How to get the spec

Send a GET request to:

https://api.pulumi.com/api/openapi/pulumi-spec.json

No authentication is required. The response is the OpenAPI 3.0 document for the Pulumi Cloud API, describing the supported, documented API surface.

Source of truth and stability

We do not hand-write the OpenAPI spec. We generate it from the same API definition that drives our backend and console code. When we add or change API routes or models, we regenerate the spec so the published document stays in sync with what the service actually implements. That gives you a clear, stable contract for the Pulumi Cloud API.

What we are building next

We are using this spec as the foundation for our own tooling, and have plans to continue leveraging the spec in our toolchain long-term.

CLI: We plan to drive the Pulumi CLI’s API client from the OpenAPI spec so that CLI and API stay in lockstep.
Pulumi Service Provider: We are also building towards day 1 updates to the Pulumi Service Provider so that new and changed API resources are generated from the spec and ship in sync with the service.
Docs Enhancements: Although you can load the spec using Swagger UI for your own browsing, we are intent on shipping enhancements to our public REST API docs that will keep them up-to-date according to the OpenAPI spec.

As we ship those updates, you will get a single source of truth from API to CLI to provider.

If you have questions or feedback about the OpenAPI spec or the Pulumi Cloud API, reach out in our Community Slack or open an issue in the Pulumi repository. We’re excited to see what you build with it.

Introducing ESC Connect: Integrate Any Secret Source with Pulumi ESC

Claire Gaestel — Mon, 01 Dec 2025 00:00:00 +0000

We’re excited to announce ESC Connect — a new capability that lets you integrate any secret source with Pulumi ESC by building simple HTTPS adapter services. If you’ve ever needed to pull secrets from a proprietary system, a legacy tool, or a third-party service that doesn’t have native ESC support, you no longer have to wait for us to build a provider. You can build your own adapter in an afternoon and start using it immediately.

Pulumi ESC has native integrations with popular secret management systems like AWS Secrets Manager, Azure KeyVault, HashiCorp Vault, 1Password, and others. But in real-world infrastructure, you often need to work with systems that fall outside this list. Maybe you built a custom secret management system years ago and it’s still running in production. Maybe you’re using a niche third-party service. Maybe your secrets are locked behind a firewall in a legacy system that predates modern APIs.

ESC Connect changes this by letting you build simple HTTPS adapter services using the external provider. Your adapter handles requests from ESC, fetches secrets from your custom source, and returns them. ESC handles authentication with signed JWT tokens, so you get fine-grained control over access without building a complete security infrastructure.

Building an adapter

Here’s an ESC environment configuration that uses ESC Connect:

values:
 customSecrets:
 fn::open::external:
 url: https://my-adapter.example.com/fetch-secrets
 request:
 secretName: DATABASE_PASSWORD

When you open this environment, ESC makes an authenticated POST request to your adapter. Your adapter validates the JWT token, fetches the secret from your source, and returns it:

const handler = async (event) => {
 // 1. Validate JWT from Authorization header
 const claims = await validateJWT(event.headers.Authorization);

 // 2. Verify audience and body hash for security
 verifyAudience(claims.aud, event.url);
 verifyBodyHash(event.body, claims.body_hash);

 // 3. Fetch secret from your source
 const request = JSON.parse(event.body);
 const secret = await fetchFromYourSource(request.secretName);

 // 4. Return the secret
 return { statusCode: 200, body: JSON.stringify(secret) };
};

The example reference implementation includes an ESCRequestValidator class that handles JWT verification and request integrity checking for you. See the documentation for detailed security requirements and examples in other languages.

Automated rotation

ESC Connect also supports automated secret rotation through fn::rotate::external. Your rotation adapter receives the current credential state, generates new credentials, updates your target system, and returns the new state. ESC handles scheduling and maintains both current and previous credentials during rotation transitions for zero-downtime rotation.

values:
 rotatedCredentials:
 fn::rotate::external:
 inputs:
 url: https://my-adapter.example.com/rotate
 request:
 service: database
 environment: production

Learn more about secret rotation in Pulumi ESC and the external rotator implementation patterns.

Try it out

ESC Connect is available now in Pulumi ESC. We’ve created a deployable reference adapter implementation on AWS Lambda that demonstrates secure request validation:

Check out the documentation for the external provider and external rotator to learn more about building production adapters.

To learn more about Pulumi ESC, explore the ESC documentation or get started for free. If you build an adapter for a system that others might find useful, share it in the Pulumi Community Slack — we’d love to see what you build.

Pulumi ESC: Open Approvals

Pablo Terradillos — Mon, 13 Oct 2025 16:00:00 -0300

Many teams live with the fear that a production environment might be accidentally opened, exposing credentials or sensitive systems before anyone even notices.

We’re excited to announce a new feature for Pulumi ESC: Open approvals. A governance capability that lets organizations require review and sign-off before an environment is opened (i.e. activated or exposed)

Expanding on our mission to enforce compliance and security without slowing teams down

You may recall that earlier this year we introduced Approvals for updates, which allows teams to require review and sign-off before applying modifications to environment configurations. We are now extending Pulumi ESC auditing and governance capabilities to enable Just in time (JIT) access control.

Many organizations require more robust guardrails around when an environment becomes active or accessible. Open Approvals introduces a gate before environment activation, enforcing that every environment open is intentional, reviewed, and governed.

Open Approvals introduces a gate before environment activation, enforcing that every environment open is intentional, reviewed, and governed.

How it works

When configuring Approvals gates for your environments under Settings → Approval Rulesets, you can now gate Open actions in addition to Updates. From this very same UI, you can define the approvals requirements:

Number of required reviewers
Specific teams or individuals allowed to approve
Whether self-approval is permitted

Once a ruleset is defined, all open operations in the corresponding environment will require to be approved before proceeding.

To create an open request, users need to specify the approval duration, how long they need access after opening the environment, and a description explaining why access is needed.

Approvals can be later review and approved from the Approvals tab.

A request access can also be created from the CLI via the newly introduced pulumi env open-request command.

$ pulumi env open-request org/project/env --access-duration-seconds=2h --grant-expiration-seconds=1h

Closing notes

Open approvals expands on Pulumi ESC support for compliance and governance capability while we stay true to our goal: empower teams to move fast while staying secure and compliant: no matter where or how changes happen.

We’re excited about what’s ahead and look forward to building it together with your feedback.

You can learn more about Approvals in Pulumi ESC Docs.

Introducing Approvals in Pulumi ESC

Pablo Terradillos — Mon, 04 Aug 2025 09:00:00 -0300

Did you know that 80% of unplanned outages aren’t caused by hardware failures or cyberattacks, but by the very changes we make to improve our systems?

Pulumi ESC already enables safer change management with our innovative versioning capability which allows users to track and roll back environment revisions.

Building on this foundation, we’re excited to announce the release of Approvals in Pulumi ESC—a new feature that enables organizations to bring governance and oversight directly into their environment configuration workflows.

With Approvals, teams can require explicit review and sign-off before applying changes to ESC-managed environments, bringing the same rigor to configuration as they already have with infrastructure-as-code and application development.

Enforce Change Management Without Slowing Teams Down

Pulumi ESC helps teams manage environment configurations—such as secrets and application settings—across services and environments, from development through production.

In fast-moving teams, managing these settings safely and consistently is critical. But as the number of contributors grows, so does the risk of accidental or unreviewed changes making it into critical environments.

That’s where Approvals come in.

With Approvals, any proposed change to an ESC environment—whether through the Pulumi Console or CLI—must go through a structured review process before it’s applied. Similar to submitting a Pull Request, contributors can propose changes that are reviewed and approved by designated team members.

This gives you a native, consistent workflow for gating configuration updates without needing external tools or manual oversight.

Why use Approvals?

Teams can use Pulumi ESC Approvals to apply the same rigor of code review workflows to environment configurations and secrets management. Approvals help organizations enforce governance policies, meet compliance requirements, and reduce the risk of misconfigurations by requiring explicit review and sign‑off before applying changes. Each request creates a clear, auditable record of who approved what, when, and why, which is especially valuable for regulated industries or teams with strict change‑management processes.

By introducing a controlled review process, Approvals let developers propose updates while ensuring only authorized reviewers can approve and apply them. This balances collaboration with security and accountability, and works seamlessly in both the Pulumi Cloud console and the Pulumi CLI.

How It Works

To get started, navigate to your environment’s Settings → Approval Rulesets, where you can define approval requirements such as:

Number of required reviewers
Specific teams or individuals allowed to approve
Whether self-approval is permitted
Whether changes require reapproval if modified

Once a ruleset is enabled, any environment update must go through a change request workflow. Instead of directly saving changes, contributors create a draft, which then must be reviewed and approved before being applied.

Changes pending approval are clearly visible to your team, and reviewers can inspect the diff, leave feedback, or revise the request before approving.

Approvals are also fully supported in the Pulumi CLI, using the --draft flag:

$ pulumi env set --draft org/project/env FEATURE_X_ENABLED true

In addition to the CLI, Approvals can be used directly from the ESC SDK—making it easy to integrate change‑management workflows into your own applications or automation scripts.

They are also available through the Pulumi Visual Studio Code Extension, allowing developers to review, approve, and apply configuration changes without leaving their editor.

Finally, the Pulumi Service Provider supports managing approval rules as code. For example:

import * as service from "@pulumi/pulumiservice";
import * as pulumi from "@pulumi/pulumi";

// ...

var approvalRule = new service.ApprovalRule("rule-test", {
 name: "My rule!",
 enabled: true,
 targetActionTypes: ["update"],
 environmentIdentifier: {
 organization: environment.organization,
 project: environment.project,
 name: environment.name,
 },
 approvalRuleConfig: {
 numApprovalsRequired: 3,
 allowSelfApproval: true,
 requireReapprovalOnChange: true,
 eligibleApprovers: [
 {
 rbacPermission: "environment:write",
 },
 {
 user: "pulumi-bot",
 },
 {
 user: "IaroslavTitov",
 },
 ]
 }
})

You can find more examples for different languages at the Pulumi Service Provider Github repository.

Built for Collaboration and Compliance

Whether you’re enforcing separation of duties, complying with industry standards or regulations, or simply want better visibility into changes, Approvals helps bring process to how configuration flows through your systems.

It also integrates seamlessly into existing workflows—no need to reinvent how teams work. Just add governance where it matters most.

What’s Next

Approvals in ESC is just the beginning. We’re exploring how approval workflows can be extended to other areas of the Pulumi ecosystem to provide a consistent, governed experience across the entire software delivery lifecycle.

Our goal is to empower teams to move fast while staying secure and compliant—no matter where or how changes happen. We’re excited about what’s ahead and look forward to building it together with your feedback.

Happy building!

Announcing Snowflake Dynamic and Rotated Credentials with Pulumi ESC

Claire Gaestel — Thu, 01 May 2025 00:00:00 +0000

Snowflake is the data cloud powerhouse for countless businesses, critical for everything from customer dashboards to billing pipelines. The stakes are immense: this data must be strictly secured and always available. But managing this with static credentials or manual key rotation creates persistent security vulnerabilities and introduces operational instability, risking disruptions during clumsy updates. Pulumi ESC eliminates this dilemma with two purpose-built Snowflake integrations:

snowflake-login: Provides dynamic, short-lived OIDC tokens for temporary authentication to Snowflake.
snowflake-user: Automates the rotation of RSA keypair secrets for Snowflake users, essential for secure key-pair authentication.

Pulumi ESC allows you to securely manage and consume these Snowflake credentials in your applications, development workflows through ESC SDK, Pulumi CLI, Kubernetes integrations, and more!

Use the snowflake-login provider when you need temporary, just-in-time credentials to interact with Snowflake, such as from local development environments, CI/CD pipelines, or scripts. It leverages OIDC to mint short-lived access tokens, eliminating the need to store static tokens.

This approach significantly reduces the attack surface by removing long-lived credentials required for authentication.

Setup:

Configure OIDC in Snowflake: Create a Security Integration in Snowflake to trust the Pulumi OIDC provider (https://api.pulumi.com/oidc), map the appropriate user claims and create a Snowflake user. Check out the docs] for more details
Configure ESC Environment: Define the snowflake-login provider in your ESC environment, specifying the Snowflake account and the user configured for OIDC.

# my-org/logins/snowflake
values:
 snowflake:
 login:
 fn::open::snowflake-login:
 oidc:
 account: myorganization-account
 user: ESC_LOGIN_USER
 role: ESC_ROLE  # Optional

When this environment is opened, ESC securely handles the OIDC flow and makes the temporary token available under snowflake.login.token.

snowflake-user: Automated Rotation for RSA Key Secrets

For applications or services using Snowflake’s key-pair authentication, maintaining the security of those RSA keys is crucial. The snowflake-user rotator automates the lifecycle management of these keys as rotated secrets within ESC. This rotater uses the same two-secret rotation strategy we use in rest of ESC’s rotated secrets providers. This eliminates manual rotation toil and ensures keys are regularly refreshed according to policy, enhancing the security of the user secret itself. Check out the rotated secrets blog post to learn more about its benefits.

Setup:

Prepare Snowflake:
- Create the target user (e.g., MY_APP_SNOWFLAKE_USER) whose keys need rotation.
- Set up a dedicated rotation role with OWNERSHIP permission over the users you wish to rotate, so it can modify their keys.
- Create a service user using the rotation role, and setup OIDC to allow ESC to assume the role for rotation.
Rotation Environment: Define the rotation, importing the managing credentials and specifying the target user.

# Environment: my-org/rotators/snowflake-app-key
values:
 rotatedKey:
 fn::rotate::snowflake-user:
 inputs:
 login: ${environments.logins.snowflake.snowflake.login} #reference credentials created using `snowflake-login`
 targetUser: ESC_ROTATION_DEMO_USER # User whose keys rotate

After setup, use the triple-dot menu -> “Rotate Secrets” in the Pulumi Cloud UI and ensure rotation happens. Once you rotate a couple of time and ensured everything works well, navigate to the “Secret Rotation” tab for your Rotation environment in the Pulumi Cloud console and define the rotation schedule.

Feature	`snowflake-login` (Dynamic OIDC Login)	`snowflake-user` (Rotated Secrets)
Credential Type	Short-lived OIDC access token	Long-lived RSA Private Key secret (managed by ESC) + Public Keys (in Snowflake)
Primary Use Case	Temporary authentication to Snowflake (CLI, scripts, dev, CI/CD).	Key-pair authentication for long-lived applications/services connecting to Snowflake.
Ideal Scenario	Short-lived tasks; frequent, temporary access needs.	Applications needing persistent connections; keys required at deploy time; apps sensitive to auth blips.
Lifecycle	Generated on-demand, expires quickly (minutes/hours).	Rotated automatically on a schedule (e.g., days/months).
Connection Impact	Requires re-authentication or new token fetch when token expires.	Rotation is typically seamless; two-key strategy avoids connection drops if apps update keys promptly.
Benefit Focus	Eliminates static authentication tokens/credentials.	Automates lifecycle management of user key-pair secrets, ensures key freshness.

Conclusion

Pulumi ESC’s new Snowflake integrations provide robust solutions for modern credential management challenges. Use snowflake-login for secure, temporary OIDC-based access and snowflake-user to automate the rotation of critical RSA key secrets. By adopting these capabilities, you can significantly enhance your Snowflake security posture, reduce operational overhead, and simplify compliance.

Explore the detailed documentation for snowflake-login and snowflake-user, and see how Pulumi ESC can centralize and secure your configuration and secrets across all your environments. Join the conversation in the Pulumi Community Slack or our GitHub repository.

Introducing Rotated Secrets in Pulumi ESC

Claire Gaestel — Wed, 19 Feb 2025 00:00:00 -0400

Managing secrets effectively is no longer a “nice-to-have”—it’s a must-have for any organization building and scaling applications in the cloud. Static, long-lived credentials like database passwords, API keys, and IAM user credentials are a major security vulnerability. They’re often overexposed, residing in source code, configuration files, or other easily accessible locations. Manual rotation processes are tedious, error-prone, and infrequent, leaving a wide window of opportunity for potential breaches. Today, we’re thrilled to announce a powerful new capability in Pulumi ESC that directly addresses this challenge: Rotated Secrets.

The Challenge with static secrets: A ticking time bomb

Traditional secrets management often relies on static, long-lived credentials. This approach creates several critical problems:

Increased attack surface: The longer a secret remains unchanged, the greater the chance it will be compromised through accidental exposure, phishing attacks, or insider threats.
Manual, error-prone rotation: Manual rotation processes are time-consuming and require significant coordination across teams. A single mistake can lead to application downtime or even data breaches.
Inconsistent practices: Ad-hoc scripts and manual procedures often lead to inconsistent rotation policies, making it difficult to enforce security best practices across the organization.
Compliance headaches: Many compliance regulations (like SOC 2, GDPR, and HIPAA) require regular secret rotation. Manual processes make it difficult to demonstrate compliance and can lead to costly penalties.

These challenges are amplified in complex, multi-cloud, hybrid, or on-premises environments where secrets are distributed across numerous systems. While Pulumi ESC’s Dynamic Secrets addresses all of these challenges and makes secret management much easier, static secrets remain a reality for many organizations. Legacy applications, compliance mandates, or integration limitations often prevent a full switch to dynamic credentials. In such cases, Rotated Secrets provide a second-best option—automating credential rotation to minimize risk while integrating seamlessly with existing workflows.

Introducing ESC Rotated Secrets

Pulumi ESC’s new Rotated Secrets feature provides an elegant solution to the challenges of secret lifecycle management. It enables automated, seamless rotation of credentials, ensuring that your secrets are always up-to-date and secure. Here’s how it solves the problems outlined above and more:

Automated rotation schedules: Define flexible rotation schedules tailored to your security and operational requirements. This eliminates manual effort and ensures consistent, frequent rotations.
On-demand rotation: Need to rotate a secret immediately due to a suspected breach or policy change? ESC allows you to trigger rotations on demand, giving you immediate control.
Seamless integration with ESC Environments: Rotated secrets are seamlessly integrated into your existing ESC environment definitions. This allows you to leverage the power of ESC’s composability, allowing you to manage rotated secrets alongside your other configuration values.
Two-secret strategy: ESC Rotated secrets uses a two-secret strategy in which two secrets are active and valid at any point in time. This is especially useful when multiple instances of an application share a credential but not all instances pull in the latest credential at the same time, allowing you to rotate a secret without worrying about some instances being unavailable due to invalid credentials.
Auditing and tracking: Gain complete visibility into credential usage, including a full history of generated credentials, active credentials, and the principals accessing them. This enhances governance and simplifies compliance.
Admin and creator control: Admins and creators/writers of rotated secrets can configure rotations using privileged user credentials and keep those credentials private while ensuring the consumers can still consume the resulting rotated secrets. This provides a clear separation of concern for administration and individual usage.
Configure webhooks for automation: Notify teams, trigger custom workflows, or trigger a Pulumi Deployment to update your IaC stacks whenever rotations occur, ensuring dependent teams and systems are updated on a timely basis

With today’s launch, we support AWS IAM user credential rotation with many more databases and cloud integrations on the way. Upvote on our GitHub issues to get support for new integrations.

How to Use ESC Rotated Secrets

Below are the steps to configure AWS IAM user rotated secrets using best practices. You can also configure this via Pulumi IaC. Check out the example program.

1. Provision an AWS IAM User on your AWS console

Create an AWS IAM user whose access keys you want to rotate.

2. Create a new environment with managing user credentials

In the example environment credentials/aws-creds below, we use the ESC’s aws-login provider using OIDC. This credential was configured with the privileged access to be able to rotate the IAM user credentials.

The minimal permissions the managing credential requires are IAM List, Create, and DeleteAccessKeys over the IAM user you created.

# credentials/aws-creds

values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: arn:aws:iam::12345689:role/test-managing-role
 sessionName: pulumi-environments-session
 subjectAttributes:
 - currentEnvironment.name

3. Create a new environment with the IAM user rotation configuration

Define the rotation using rotated secrets aws-iam provider. Below is an example definition. Notice how the managing user credentials created in step 2 is referenced in the rotation provider input. This credential will only be used during rotation and never be exposed to the consumers of the rotated IAM user credential.

Providing current and previous credentials is optional. If you already have IAM user access keys that are actively used, you can specify them in the state field as current and previous. If not, you can leave the state empty.

values:
 rotated-creds:
 fn::rotate::aws-iam:
 inputs:
 region: us-west-1
 login: ${environments.credentials.aws-creds.aws.login}
 userArn: arn:aws:iam::{accountId}:user/{username}
 # state section below is optional.
 state:
 current:
 accessKeyId: AKIA...
 secretAccessKey:
 fn::secret: ASIA....
 previous:
 accessKeyId: AKIA...
 secretAccessKey:
 fn::secret: ASIA....

4. Test the setup with a manual rotation

In the Environment Editor screen, open the triple-dot menu and select Rotate Secrets. Alternatively, you can perform the rotation from the ‘secrets rotation’ tab or use the rotate CLI command. Every rotation creates a new revision.

If you did not provide current or precious credentials in step 3, rotation will generate new credentials automatically.

5. Monitor rotations

Perform multiple rotations to observe how access keys move from current → previous → deleted. Use the Environment Revision History to track changes.

6. Schedule rotations

Now that you’ve correctly configured your rotated secrets, set up an automated rotation schedule from the Secrets Rotation tab.

Rotated Secrets vs. Dynamic Credentials: Choosing the right tool

Pulumi ESC offers both Dynamic Secrets and Rotated Secrets. While both enhance security, they serve different purposes:

Dynamic secrets: These are short-lived, ephemeral credentials with a Time-To-Live (TTL) typically ranging from 1 to 8 hours. A new set of credentials is generated every time the environment is opened. This is ideal for minimizing the impact of compromised credentials, as they quickly become invalid.
Rotated secrets: These are longer-lived credentials, potentially lasting for days, weeks, or even months. The same latest credential is returned every time the environment is opened until the next scheduled rotation occurs. This provides stability and predictability for applications that need consistent credentials over a longer period.

Here are scenarios where rotated secrets are the preferred choice:

Legacy applications: Many legacy applications were built before modern secret management practices existed and cannot easily be rewritten to support dynamic secrets. For these applications, Rotated Secrets offer a practical way to enhance security without requiring a full application redesign or re-architecture.
Applications that can only update credentials during restarts and redeployments: Some applications require credentials to be available at startup and cannot refresh them dynamically. Rotated Secrets works well for this scenario, providing rotations and ensuring applications always have a valid credential when restarted.
Applications requiring persistent connections: High-performance applications or applications that have a long-lived database connections cannot afford to fetch fresh credentials every few hours. Rotated Secrets ensure such applications continue to function as needed while boosting security.
Third-Party API keys (Support coming soon): Some external services cannot provision dynamic short-term credentials. Rotated Secrets provide a way to comply with periodic key rotation policies without requiring real-time credential generation.
Databases in private networks (Support coming soon): Many Enterprise databases are not connected to the internet, thereby requiring a proxy or an agent running in their internal network to perform the rotation. Rotated Secrets offer stability in such environments by reducing the number of external calls, even when routed through a proxy.

What’s next?

This is just the beginning! We’re committed to expanding the capabilities of Rotated Secrets. Here’s a glimpse of what’s on the roadmap:

Database Secrets Rotation: Automated secrets rotation support for a wide range of databases including PostgreSQL, Snowflake, MySQL, and more!
Secret rotations for databases running in private networks
3rd party API key rotation (example: Twilio)
Other cloud provider support: Azure, GCP

Upvote integrations here. Want an integration not mentioned? Click here to raise a request.

Conclusion

Pulumi ESC’s Rotated Secrets feature represents a significant advancement in modern secrets management. By automating a traditionally manual and error-prone process, ESC reduces operational risks, strengthens your security posture, and helps you achieve compliance – all without slowing down development.

We encourage you to explore the docs and try out Rotated Secrets. Share any feedback or open new issues in our GitHub repository. We’re excited to see how you use this powerful new feature to build more secure and resilient applications!

Secret Rotation with Pulumi ESC

Claire Gaestel — Tue, 10 Dec 2024 15:43:02 -0800

Pulumi ESC now natively supports secrets rotation that makes secrets lifecycle management much easier. Check out the launch blogpost and docs.

Managing secrets in modern cloud applications can be challenging, particularly when it comes to rotation policies. While dynamic secrets (like AWS IAM temporary credentials) handle this automatically, many systems still rely on static secrets that require periodic rotation.

Static secrets, like database passwords or API keys, should be rotated regularly to maintain security, and services depending on these secrets need time to transition to new credentials to avoid downtime. This makes rotating credentials error-prone, and often forgotten.

In this post, we’ll explore an approach for automating static secret rotation using Pulumi ESC combined with Pulumi IaC.

A pattern for extending ESC

We can take advantage of ESC’s integration with Pulumi Deployments to create an ergonomic way of managing rotation schedules ourselves.

We’ll start by defining a custom declarative configuration format for managing a rotation schedule:

# we'll create our own "extended" fn config for ESC
xfn::pulumi-scheduled-update:
 # stack reference to a pulumi program that manages a rotated secret
 stack: "example-rotator-stack-reference/dev"
 # schedule that will drive an automatic scheduled deployment
 scheduleCron: "0 0 * * 0"
 # trigger a manual unscheduled rotation whenever this value changes
 trigger: "break-glass"

Using webhooks, we’ll monitor when the environment is updated, then search for these configuration blocks, and use them to drive scheduled deployments of a stack that rotates credentials. Using ESC’s composition primitives, we can combine this rotation schedule config with a fn::open::pulumi-stacks provider to read the current secret value from the rotator stack to provide to our application.

Here is how the solution fits together: Let’s break down each component and see how they work together to solve our rotation challenges.

The Rotator: Managing Credential Lifecycles

At the heart of our solution is a generic Rotator component that manages credential pairs. It’s designed to handle any type of static secret while ensuring zero-downtime rotations. The way it does this is by maintaining two versions of each secret: “current” and “previous”. Each time the stack is deployed, “current” is replaced with a newly provisioned credential, the old value is demoted to “previous”, and the old previous credential is decommissioned. Crucially, the demoted secret remains valid, which allows consuming services enough time to switch over to the new secret.

const creds = new Rotator("rotating-creds", {
 // rotate credentials on every deployment.
 trigger: Date().toString(),
 // create a set of equivalent credentials that will be rotated between.
 // a particular credential should be replaced whenever `trigger` is updated.
 construct: (name, trigger) => {
 // in this example we're just creating passwords,
 // but these could be mysql users or anything else.
 return new random.RandomPassword(name, {
 length: 10,
 keepers: {trigger}
 })
 },
})

// export when the last rotation happened
export const lastUpdate = creds.lastUpdate.apply(date => date.toISOString());
// export the currently active credential, which will be imported by the downstream ESC environment.
export const current = creds.current.result;

The Scheduler: Orchestrating Rotations

The scheduler component acts as an orchestrator, watching an ESC environment for updates and managing deployment schedules of the rotator stacks. Whenever a change to the environment is saved, a webhook invokes the scheduler, which parses the environment definition to find xfn::pulumi-scheduled-update configuration blocks. Based on these schedule configurations, it creates scheduled deployments for the referenced rotator stacks automatically.

Bringing It Together: Environment Configuration

Once wired together, the magic happens in the ESC environment configuration, where we compose a rotation schedule with dynamic credential retrieval, creating a rotated credential that is automatically kept up to date:

values:
 db-credentials:
 stack: database-credential-rotator/dev
 schedule:
 xfn::pulumi-scheduled-update:
 stack: ${db-credentials.stack}
 scheduleCron: "0 0 * * 0" # weekly rotation
 trigger: "break-glass" # manual trigger
 secrets:
 fn::open::pulumi-stacks:
 stacks:
 credentials:
 stack: ${db-credentials.stack}

 api-keys:
 stack: api-key-rotator/dev
 schedule:
 xfn::pulumi-scheduled-update:
 stack: ${api-keys.stack}
 scheduleCron: "0 0 1 * *" # monthly rotation
 secrets:
 fn::open::pulumi-stacks:
 stacks:
 keys:
 stack: ${api-keys.stack}

 environmentVariables:
 DB_CONNECTION_STRING: ${db-credentials.secrets.credentials.current}
 API_KEY: ${api-keys.secrets.keys.current}

This configuration demonstrates how our custom extension is able to seamlessly integrate with ESC to manage multiple rotating secrets with different schedules declaratively, co-located with dynamic retrieval of the latest credentials from the rotator stack outputs. Applications consuming this environment will automatically receive the latest credentials without any additional configuration.

Trying it out

Open the example environment and take note of the current secrets:

❯ pulumi env open esc-rotation-demo/test db-credentials.secrets
{
"credentials": {
"current": "OBA=wxS:VT",
"lastUpdate": "2024-11-26T17:49:03.000Z",
"previous": "MUgPXkJ+kE"
}
}

Now lets force a rotation by changing the manual trigger:

❯ pulumi env set esc-rotation-demo/test \
db-credentials.schedule.xfn::pulumi-scheduled-update.trigger \
break-glass2

After a few minutes we can see that the secret has rotated successfully! We can also observe that the previous secret remains valid, giving currently deployed consumers time to update to the new credentials.

$ pulumi env open esc-rotation-demo/test db-credentials.secrets
{
"credentials": {
"current": "X2WSmF3+29",
"lastUpdate": "2024-11-26T17:57:05.000Z",
"previous": "OBA=wxS:VT" <---- old "current" has been demoted
}
}

Conclusion

Secret rotation doesn’t have to be a manual, error-prone process. By leveraging Pulumi ESC and this component architecture, we can automate and streamline the rotation of static secrets while maintaining system stability and security. The solution is flexible enough to handle various types of secrets while being simple to configure and maintain. This approach offers several advantages:

Automated: Set-and-forget secret rotation
Zero-downtime: Smooth transitions between credentials
Flexible: Works with any type of static secret
Declarative: Configuration through ESC environments
Auditable: Clear tracking of rotation history
Scalable: Easy to manage across multiple environments

The complete example is available for your perusal here.

This pattern of extending ESC through configuration-driven components is a powerful technique that can be applied to other use cases. We’re excited to see what else you come up with 🙂

Pulumi Blog: Claire Gaestel

Now Generally Available: Store Terraform State in Pulumi Cloud

Why this matters

What you get

How it works

Get started

Introducing the Terraform State Provider for Pulumi ESC

How it works

Terraform Cloud support

Get started

Schema Validation Comes to Pulumi ESC with fn::validate

How it works

Validating objects with required fields

Reusing schemas across environments

What happens when validation fails

When to use schema validation

Getting started

Announcing OpenAPI support for the Pulumi Cloud REST API

A single contract for the Pulumi Cloud REST API

How to get the spec

Source of truth and stability

What we are building next

Introducing ESC Connect: Integrate Any Secret Source with Pulumi ESC

Building an adapter

Automated rotation

Try it out

Pulumi ESC: Open Approvals

Expanding on our mission to enforce compliance and security without slowing teams down

How it works

Closing notes

Introducing Approvals in Pulumi ESC

Enforce Change Management Without Slowing Teams Down

Why use Approvals?

How It Works

Built for Collaboration and Compliance

What’s Next

Announcing Snowflake Dynamic and Rotated Credentials with Pulumi ESC

snowflake-login: Dynamic OIDC Authentication for Temporary Access

snowflake-user: Automated Rotation for RSA Key Secrets

When to Use Dynamic Login vs. Rotated Secrets

Conclusion

Introducing Rotated Secrets in Pulumi ESC

The Challenge with static secrets: A ticking time bomb

Introducing ESC Rotated Secrets

How to Use ESC Rotated Secrets

1. Provision an AWS IAM User on your AWS console

2. Create a new environment with managing user credentials

3. Create a new environment with the IAM user rotation configuration

4. Test the setup with a manual rotation

5. Monitor rotations

6. Schedule rotations

Rotated Secrets vs. Dynamic Credentials: Choosing the right tool

What’s next?

Conclusion

Secret Rotation with Pulumi ESC

A pattern for extending ESC

The Rotator: Managing Credential Lifecycles

The Scheduler: Orchestrating Rotations

Bringing It Together: Environment Configuration

Trying it out

Conclusion