Pulumi Blog: Configuration management

Preview ESC Changes with Environment Overrides

Sean Yeh — Thu, 23 Jul 2026 00:00:00 +0000

Pulumi ESC makes it easy to store configuration and secrets for your Pulumi programs, and with Approvals for ESC you can review and approve changes before they go live. The new --override-env flag lets you preview any environment change, including an unapproved draft, to see exactly how it would affect your stack before it becomes the latest version.

Example scenario

Your team stores production app configuration in ESC and has enabled Approvals to keep bad values out of critical infrastructure. But one important question remains: how can reviewers properly validate a configuration change before approving it?

Introducing: draft references and the –override-env flag

We are introducing a new --override-env flag to the Pulumi CLI that works with every Pulumi operation that can consume ESC environments: preview, up, refresh, and destroy. This makes it easy to test configuration changes on the fly, giving your team the confidence to validate them as part of the review process.

Example usages

The basic usage is --override-env <env>=<replacement>, and you can override multiple environments at once! In this example, we are running a pulumi preview with environments app/myenv and app/myenv2 replaced by their draft versions (denoted by @draft:<draft-id>).

pulumi preview \
--override-env "app/myenv=app/myenv@draft:123e4567-e89b-12d3-a456-426614174000" \
--override-env "app/myenv2=app/myenv2@draft:123e4567-e89b-12d3-a456-426614174000"

The --override-env flag not only works with draft references, but for any environment too! Here is an example of deploying your stack with your AWS test environment:

pulumi up --override-env "aws-login/prod=aws-login/testing"

Note: --override-env can also override environments that are imported (directly or indirectly) from the ESC environment in your stack config. This allows you to override any environment in the import chain for full flexibility.

Ways to use it

Validate a draft ESC environment with your stack before approving
One-off debugging without editing stack config

Get started

Draft references and --override-env are available today in the Pulumi CLI. Upgrade to the latest release and try it out! To learn more:

Announcing Doppler Providers for Pulumi ESC: Dynamic Login and Dynamic Secrets

Robert Harris — Thu, 26 Jun 2025 00:00:00 +0000

We are excited to announce support for Doppler within Pulumi ESC! Pulumi ESC centralizes secrets and configuration management, providing a unified source of truth across your environments. With the addition of Doppler, a popular secrets management platform, ESC further extends its ecosystem, enabling seamless and secure access to secrets stored across diverse systems.

This release introduces two distinct dynamic providers for Doppler, each designed to improve security and streamline your workflows:

doppler-login (Dynamic Login): This provider securely generates short-lived OIDC access tokens for authenticating to Doppler. Static, long-lived credentials are a significant security risk. The doppler-login provider directly addresses this by generating temporary, just-in-time credentials using OIDC. Use this provider when you need temporary credentials to interact directly with Doppler, for instance, using the Doppler CLI or SDKs in local development or CI/CD pipelines, without storing long-lived static tokens. ESC manages the OIDC flow, providing a fresh token when needed.
doppler-secrets (Dynamic Secrets): This provider dynamically fetches secrets stored within your Doppler configs and makes them available within the Pulumi ESC environment. Use this provider when you need specific secrets from Doppler to configure your applications or infrastructure managed via ESC. This centralizes secret consumption, allowing you to access Doppler secrets using the same consistent ESC patterns used for AWS, Azure, GCP, Infisical, Vault, 1Password, and more.

Pulumi ESC acts as a robust secrets broker provider consistent API interface for all your tools, applications and workflows. It securely handles both the generation of temporary authentication credentials (like with doppler-login) and the fetching of application secrets (like with doppler-secrets) from various providers such as Doppler, cloud platforms (AWS, Azure, GCP), and other secret managers (Infisical, Vault, 1Password). Once centralized in ESC, these secrets and configurations are consistently available for you to consume via ESC’s many developer friendly methods including the ESC SDK, Pulumi CLI, Kubernetes External Secrets Operator, CSI Driver, or sync them to various platforms where they are needed such as GitHub Secrets, AWS Secrets Manager, and more!

Getting Started: Using the Doppler Providers

Let’s walk through how to configure and use each provider.

Prerequisites

Your Doppler workplace must be on the Team or Enterprise plan in order to use OIDC (via service account identities).

Configure Doppler for OpenID Connect(OIDC) before you try out the providers. Follow the steps in Doppler OIDC documentation. This involves creating a Service Account Identity in Doppler, with OIDC authentication pointing to https://api.pulumi.com/oidc, and configuring the audience and subject claims. Note down the Identity ID.

Create a Pulumi ESC environment (e.g., pulumi-org/doppler-auth/oidc-login) with the following environment definition and update the identityId.

# Environment: pulumi-org/doppler-auth/oidc-login
values:
 doppler:
 # Configure the Dynamic Login provider using OIDC
 login:
 fn::open::doppler-login:
 oidc:
 identityId: <your-identity-id> # Replace with your Doppler Identity ID

 # Expose the token as an environment variable for easy consumption
 environmentVariables:
 DOPPLER_TOKEN: ${doppler.login.accessToken}

Save the environment.
Validate the environment by clicking on Open in the Pulumi Cloud console, or running pulumi env open pulumi-org/doppler-auth/oidc-login in your CLI. The output will include the doppler.login.accessToken.

Usage Example: Run Doppler CLI commands dynamically:

pulumi env run pulumi-org/doppler-auth/oidc-login -- doppler secrets download --no-file --format=json --project=<your-project-id> --config=<your-config-id>
# The DOPPLER_TOKEN env var is automatically injected

How to Use the doppler-secrets Provider (Dynamically Fetching Secrets)

Use this provider to pull secrets from Doppler into your ESC environment for consumption by your applications, CI/CD systems, Pulumi IaC, Terraform and more!

Create an ESC environment where you need the secrets (e.g., pulumi-org/my-app/dev).
Import the dynamic login environment (if using OIDC for authentication, which is recommended). This makes the temporary Doppler token available.
Configure the doppler-secrets provider, referencing the imported login details. See example below.

Specify the secrets to fetch using the get block. Replace placeholders.

# Environment: pulumi-org/my-app/dev
imports:
 # Import the environment performing Dynamic Login (recommended)
 - pulumi-org/doppler-auth/oidc-login # Use the path to your login environment

values:
 # Define a structure to hold secrets fetched from Doppler
 dopplerSecrets:
 fn::open::doppler-secrets:
 # Authenticate using the token from the imported Dynamic Login environment
 login: ${doppler.login} # Pass the login object from the import
 # Specify the Doppler project and config to retrieve secrets from
 project: example-project
 config: dev
 # Specify secrets to retrieve from Doppler
 get:
 # Define names for the secrets as they will appear in ESC's output under 'dopplerSecrets'
 apiKey: # This is the name within ESC
 name: API_KEY # The name of the secret in Doppler
 appSecret: # Pull another secret into ESC
 name: APP_SECRET

 # Optionally, map fetched secrets to environment variables for application consumption
 environmentVariables:
 API_KEY: ${dopplerSecrets.apiKey}
 APP_SECRET: ${dopplerSecrets.appSecret}

Save the environment.
Validate the environment by clicking on Open in the Pulumi Cloud console, or running pulumi env open pulumi-org/my-app/dev in your CLI. The output will show the imported doppler.login, the fetched secrets under dopplerSecrets, and the mapped environmentVariables.

Usage Example: Run an application that needs these secrets:

pulumi env run pulumi-org/my-app/dev -- node app.js
# The API_KEY and APP_SECRET env vars are automatically injected

Conclusion

The new doppler-login and doppler-secrets providers for Pulumi ESC offer powerful and secure ways to interact with Doppler. Use doppler-login for dynamic, short-lived OIDC authentication when interacting directly with Doppler APIs or CLIs. Use doppler-secrets to securely fetch secrets from Doppler into your centralized ESC environment. Together, they enhance your security posture and simplify configuration management.

We encourage you to explore these new capabilities. Dive into the doppler-login, doppler-secrets for detailed configuration options, check out the broader Pulumi ESC Documentation, and share your feedback or ask questions in the Pulumi Community Slack.

From Configuration Chaos to Programming Languages

Daniel Ward — Tue, 03 Jun 2025 00:00:00 +0000

This post is based on our video interview with Daniel Ward, a Software Developer/Consultant at Lean TECHniques and Microsoft MVP. Daniel shares his strategies for moving teams from configuration chaos to programming languages for infrastructure, including the 10% rule for change, viral adoption, and why Pulumi beats YAML for complex systems. Watch the video below or read on. - Adam Gordon Bell

Since this post was published, Pulumi has added first-class support for HashiCorp Configuration Language (HCL). You can now write Pulumi programs in HCL directly, alongside general-purpose languages like TypeScript, Python, Go, and C#. To see how it works, see Pulumi HCL.

Imagine your infrastructure codebase has evolved from a few files to thousands of lines across dozens of configuration files. Your team spends hours deciphering CloudFormation templates, your AWS CDK deployments take 30+ minutes, and introducing any change becomes a multi-day effort. This is the reality many organizations face when their infrastructure-as-code approach outgrows their tooling.

As a consultant and developer who helps organizations improve their software delivery processes, I’ve seen firsthand how the right technologies—specifically using actual programming languages like C#—can transform infrastructure management instead of forcing teams to use declarative configuration files.

My Background: Coaching Teams Through Technical Transformation

My background is primarily as a .NET developer—I’m now a Microsoft MVP in my first year—though I work with TypeScript and other languages as needed. About six years ago, I moved into consulting, or what we call “coaching” at Lean Techniques.

The idea isn’t just to write code for clients or tell them what to do and leave. Our goal is that once we leave, they don’t need us anymore. We’re essentially trying to put ourselves out of a job.

Organizations bring me in for various reasons—from implementing automated testing after costly failures to migrating from mainframes to the cloud. Sometimes it’s about product delivery challenges, like month-long sprints that never complete on time.

It’s about bringing places up to a modern standard. As we say at Lean Techniques, turning IT from a cost center into a competitive advantage.

If you’re ready to move from sprawling configuration files to code-centric infrastructure, here are eight practical steps to guide you:

1. Follow the 10% Rule for Sustainable Change

One of my guiding principles comes from Gerald Weinberg’s book “The Secrets of Consulting”: the 10% rule. When entering a new team or organization, don’t try to improve more than 10% at a time.

There are a few reasons for this. One is that you can actually end up making the client look bad. If you improve everything at once, their boss might ask why this consultant fixed everything in six months when the team couldn’t fix it in five years.

But there’s a deeper reason related to social dynamics. Any social group, in programming or outside of work—if you come in new and try to change how the group works before familiarizing yourself with it, people will be resistant. They’ll ask “Who do you think you are? You just got here!” And they’re right—you could be wrong about some things. You have to understand how they work to understand what the problems are.

This applies directly to introducing new technologies like infrastructure as code. Rather than overhauling everything at once, I recommend starting small.

If a place is completely new to infrastructure as code, I’ll tell them to start small. None of their engineers know how to do this yet, and I’m not going to do all the work for them and leave, because then none of their engineers will know how to maintain it.

2. Quantify the Cost of Inaction to Overcome Resistance

Even with a measured approach, resistance is inevitable. I’ve experienced teams that are exceptionally open to improvement, often coming from difficult situations and eager for change. I’ve also worked with teams that resist most suggestions, where engineers feel the consultant was forced upon them by management.

It’s always easier if you can do pull-based versus push-based change—where the team has asked for your help instead of the manager telling them “I’m inflicting this help on you.”

For those looking to influence change within their organization, I’ve found that influencing upper-level management comes down to numbers. They deal with too many teams to get into specifics—they want numbers. If you can show how many hours your team spends each week manually pushing code or waiting on another team, and multiply that by engineer salaries, you’re showing how much money is being wasted.

This approach is far more effective than what can come across as “Here’s a new tool I want to play with”—an anti-pattern that reinforces the stereotype of technical people just wanting to use new technologies.

3. Build Consensus with Nemawashi Conversations

I’ve found a Japanese concept called “nemawashi” (literally “turning the roots”) provides another effective approach to organizational change:

Before introducing an idea to a manager or the whole team, individually go to every person on the team first and get their thoughts. If most people respond positively, you can then approach the decision-maker saying, “Everyone on the team wants this—what do you think?”

This isn’t just about collecting checkmarks but genuinely gathering feedback. If you’re getting pushback from every single person, maybe it’s not as great an idea as you thought. Either way, you learn something from it.

4. Drive Viral Adoption Through Early Wins

Rather than forcing change on resistant teams, I prefer what I call “viral adoption”:

We try to work with teams that ask for our help instead of being pushed onto teams. People are way less resistant if you can show them you’re making their job easier. We work with one team who wants our help, make them really effective, and then other teams notice: “How come they’re releasing so many times a week? How do they have so few defects? How is their pipeline so fast?”

This success creates natural curiosity, leading other teams to either request similar help or study and adopt the successful team’s practices. Either way, I’m happy that things are improving.

5. Align Dev and Ops with Infrastructure as Code

When it comes to infrastructure as code specifically, I’ve noticed it’s becoming table stakes for many organizations, though implementation quality varies widely.

It’s hard to have actual continuous delivery without infrastructure as code. Without it, developers can’t define their own infrastructure and have to wait on another team to do it. By continuous, I mean teams should be able to deploy every 30 minutes if they want. If you have to wait one to three business days for the operations team to create your resources, that’s not continuous.

Resistance to infrastructure as code typically comes from two directions:

From developers: “I already have my plate full—now I have to learn cloud and deployment too?”
From operations: “That’s my job—I don’t want to lose it.”

I see this as a win-win opportunity for both sides. For operations teams, the job shifts from mundane tasks like “create a lambda for me” or “replace this code bundle” to more creative platform engineering work. For developers, the benefit is clear: no more waiting on operations to proceed with their work.

6. Invest in Platform Engineering for Reusable Components

Platform engineering has emerged as a solution to these challenges. Instead of every team reinventing solutions for common needs like logging, monitoring, or deployment pipelines, platform teams create standardized, reusable components.

It seems wasteful if every single team has to manage their own side of the Splunk instance or Dynatrace. These are solved problems that every team needs. A platform team can look across the organization, see what can be standardized, and remove those problems from individual teams.

This approach is particularly powerful with tools like Pulumi, which allows creating reusable component resources for common patterns: “It’s very common for teams to create a Lambda-backed API Gateway or a Lambda hooked up to SQS. These are super common things, so here’s a component resource for that so you don’t have to write it yourself.”

The key difference in mindset is that platform teams aren’t enforcing rules—they’re building tools that make developers’ lives easier. Instead of saying “You must do logging this way,” it’s “Here’s an endpoint you can use—you’re good to go.”

7. Avoid YAML Pitfalls: Embrace Programming Languages

One of my pain points is the limitations of configuration languages like YAML for complex infrastructure. I recently gave a presentation about a GitHub Actions workflow that grew to over 1,000 lines, calling shared actions that call other shared actions, making it nearly impossible to understand what’s happening.

I couldn’t use breakpoints or the normal libraries I would use. I’ve seen a 69,000-line YAML file for Prometheus and Kubernetes—that’s an auto-generated example, but even a thousand lines calling several other files is too much.

The fundamental issue is abstraction. Programming languages allow loops, conditionals, and functions to remove repetition and build larger structures. Configuration languages often lack these capabilities, leading to copy-pasting and unmanageable growth.

With declarative approaches, you end up using a lot of magic strings. It’s easy to forget one when you change values. The tooling is also an issue—I’m familiar with IDEs and libraries for programming languages, but the equivalent tools for YAML just aren’t as mature.

8. Choose Pulumi for Flexible, Code-First IaC

When comparing infrastructure-as-code options, I see three major players: AWS CDK, Terraform, and Pulumi. While AWS CDK offers similar capabilities to Pulumi for AWS resources, it relies on CloudFormation under the hood:

CloudFormation is just a black box—it’s proprietary. If something goes wrong, you have to hope someone’s already asked about it on GitHub. When deployments take 15-30 minutes, there’s not much you can do—it’s just how CloudFormation works.

Compared to Terraform, which uses HCL (HashiCorp Configuration Language), Pulumi offers the flexibility of actual programming languages:

There’s nothing wrong with declarative approaches in some cases, but at a certain point—when you have big systems and chunks of resources you want to share between teams—it becomes more cumbersome than helpful. That’s why Terraform is working on their own CDK now.

What sets Pulumi apart is its flexibility: Even if you have platform teams who aren’t developers and want to set standards, they can use YAML with Pulumi and then transform those component resources into other languages for dev teams to use. You get the best of all worlds.

Start Small, Think Big: Small Changes, Big Impact

Whether you’re introducing infrastructure as code or any significant technical change, my advice remains consistent: start small, focus on solving real problems, and let success spread naturally.

By understanding the human elements of change—the 10% rule, nemawashi, and viral adoption—you can transform resistance into enthusiasm. And by choosing tools like Pulumi that bridge the gap between developers and operations, you can create infrastructure that’s both powerful and maintainable.

I’m currently writing a blog series on Pulumi at daninacan.com. I also speak at conferences occasionally, so check out my speaking page if you’re interested.

Ready to escape configuration chaos? Start small, focus on solving real problems, and get started with Pulumi to leverage the full power of programming languages for infrastructure. Join our community Slack to connect with engineers making the same transformation.

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.

Announcing Infisical Providers for Pulumi ESC: Dynamic Login and Dynamic Secrets

Boris Schlosser — Mon, 28 Apr 2025 00:00:00 +0000

We are thrilled to announce enhanced integration support for Infisical within Pulumi ESC! Pulumi ESC centralizes secrets and configuration management, providing a unified source of truth across your environments. With the addition of Infisical, a popular open-source secrets management platform, ESC further extends its ecosystem, enabling seamless and secure access to secrets stored across diverse systems.

This release introduces two distinct dynamic providers for Infisical, each designed to improve security and streamline your workflows:

infisical-login (Dynamic Login): This provider securely generates short-lived OIDC access tokens for authenticating to Infisical. Static, long-lived credentials are a significant security risk. The infisical-login provider directly addresses this by generating temporary, just-in-time credentials using OIDC. Use this provider when you need temporary credentials to interact directly with Infisical, for instance, using the Infisical CLI or SDKs in local development or CI/CD pipelines, without storing long-lived static tokens. ESC manages the OIDC flow, providing a fresh token when needed.
infisical-secrets (Dynamic Secrets): This provider dynamically fetches secrets stored within your Infisical projects and makes them available within the Pulumi ESC environment. Use this provider when you need specific secrets from Infisical to configure your applications or infrastructure managed via ESC. This centralizes secret consumption, allowing you to access Infisical secrets using the same consistent ESC patterns used for AWS, Azure, GCP, Vault, 1Password, and more.

Pulumi ESC acts as a robust secrets broker provider consistent API interface for all your tools, applications and workflows. It securely handles both the generation of temporary authentication credentials (like with infisical-login) and the fetching of application secrets (like with infisical-secrets) from various providers such as Infisical, cloud platforms (AWS, Azure, GCP), and other secret managers (Vault, 1Password). Once centralized in ESC, these secrets and configurations are consistently available for you to consume via ESC’s many developer friendly methods including the ESC SDK, Pulumi CLI, Kubernetes External Secrets Operator, CSI Driver, or sync them to various platforms where they are needed such as GitHub Secrets, AWS Secrets Manager, and more!

Getting Started: Using the Infisical Providers

Let’s walk through how to configure and use each provider.

Prerequisites

Configure Infisical for OpenID Connect(OIDC) before you try out the providers. Follow the steps in Infisical OIDC documentation. This involves creating an Identity in Infisical, adding OIDC authentication pointing to https://api.pulumi.com/oidc, and configuring the audience and subject claims. Note down the Identity ID.

Create a Pulumi ESC environment (e.g., pulumi-org/infisical-auth/oidc-login) with the following environment definition and update the identityId.

# Environment: pulumi-org/infisical-auth/oidc-login
values:
 infisical:
 # Configure the Dynamic Login provider using OIDC
 login:
 fn::open::infisical-login:
 oidc:
 identityId: <your-identity-id> # Replace with your Infisical Identity ID

 # Expose the token as an environment variable for easy consumption
 environmentVariables:
 INFISICAL_TOKEN: ${infisical.login.accessToken}

Save the environment.
Validate the environment by clicking on Open in the Pulumi Cloud console, or running pulumi env open pulumi-org/infisical-auth/oidc-login in your CLI. The output will include the infisical.login.accessToken.

Usage Example: Run Infisical CLI commands dynamically:

pulumi env run pulumi-org/infisical-auth/oidc-login -- infisical secrets get API_KEY --projectId=<your-project-id>
# The INFISICAL_TOKEN env var is automatically injected

How to Use the infisical-secrets Provider (Dynamically Fetching Secrets)

Use this provider to pull secrets from Infisical into your ESC environment for consumption by your applications, CI/CD systems, Pulumi IaC, Terraform and more!

Create an ESC environment where you need the secrets (e.g., pulumi-org/my-app/dev).
Import the dynamic login environment (if using OIDC for authentication, which is recommended). This makes the temporary Infisical token available.
Configure the infisical-secrets provider, referencing the imported login details. See example below.

Specify the secrets to fetch using the get block. Replace placeholders.

# Environment: pulumi-org/my-app/dev
imports:
 # Import the environment performing Dynamic Login (recommended)
 - pulumi-org/infisical-auth/oidc-login # Use the path to your login environment

values:
 # Define a structure to hold secrets fetched from Infisical
 infisicalSecrets:
 fn::open::infisical-secrets:
 # Authenticate using the token from the imported Dynamic Login environment
 login: ${infisical.login} # Pass the login object from the import
 # Specify secrets to retrieve from Infisical
 get:
 # Define names for the secrets as they will appear in ESC's output under 'infisicalSecrets'
 apiKey: # This is the name within ESC
 projectId: <your-infisical-project-id>
 environment: prod # The Infisical environment slug (e.g., 'prod', 'dev')
 secretKey: api-key # The key of the secret in Infisical
 appSecret: # Pull another secret `app-secret` into ESC
 projectId: <your-infisical-project-id>
 environment: dev
 secretKey: app-secret

 # Optionally, map fetched secrets to environment variables for application consumption
 environmentVariables:
 API_KEY: ${infisicalSecrets.apiKey}
 APP_SECRET: ${infisicalSecrets.appSecret}

Save the environment.
Validate the environment by clicking on Open in the Pulumi Cloud console, or running pulumi env open pulumi-org/my-app/dev in your CLI. The output will show the imported infisical.login, the fetched secrets under infisicalSecrets, and the mapped environmentVariables.

Usage Example: Run an application that needs these secrets:

pulumi env run pulumi-org/my-app/dev -- node app.js
# The API_KEY and APP_SECRET env vars are automatically injected

Conclusion

The new infisical-login and infisical-secrets providers for Pulumi ESC offer powerful and secure ways to interact with Infisical. Use infisical-login for dynamic, short-lived OIDC authentication when interacting directly with Infisical APIs or CLIs. Use infisical-secrets to securely fetch secrets from Infisical into your centralized ESC environment. Together, they enhance your security posture and simplify configuration management.

We encourage you to explore these new capabilities. Dive into the infisical-login, infisical-secrets for detailed configuration options, check out the broader Pulumi ESC Documentation, and share your feedback or ask questions in the Pulumi Community Slack.

Pulumi ESC: Discovering Environment Imports

Sean Yeh — Fri, 13 Dec 2024 00:00:00 -0700

Managing secrets and configuration across multiple environments and stacks can easily become complex, leading to duplicated values, inconsistencies, and security risks. Pulumi ESC solves this with composable environments via imports, allowing you to define configuration once and reuse it organization-wide. Now, with the new capabilities to discover environment imports, you gain unprecedented visibility and control, simplifying the management of even the most complex infrastructure and applications.

Understanding Pulumi ESC Imports

Pulumi ESC lets you define secrets and configuration as code collections called environments. These environments can import other environments, creating a hierarchical structure that promotes reusability, and reduces duplication and sprawl. You can centralize secrets and configuration within ESC and use them across Pulumi IaC Stacks, Pulumi Insights Accounts, and various other platforms through our integrations.

By using version tags, imports can target specific versions of an environment. This locks down the configuration used by dependents, ensuring stability and preventing unintended changes from rolling out to your critical environments.

What’s New?

We’ve added powerful discoverability features to give you clear insight into your environment dependencies:

New “Imported By” tab: Easily understand downstream dependencies by clicking the “Imported By” tab for each environment. This tab shows all environments and stacks that import a specific environment, including the specific tagged version used. Filter and sort by imported versions and downstream resources to narrow in on the resources that will be affected by a change you are trying to make.
Warnings for deletions and tag movements: Pulumi ESC now warns you about the potential impact of deleting an environment or modifying version tags before you make the change, helping you avoid disruptions.
Enhanced environment page: The Environments page now clearly indicates if an environment is used by other environments, stacks, or insights accounts, providing valuable relationship context at a glance.
Pulumi IaC stack visibility: Environment import information is also available on the Stacks page and within individual stack overview pages.

Conclusion

Pulumi ESC’s import feature is a paradigm shift in how you manage your secrets and configuration. The new suite of import discoverability features gives you the confidence to manage complex deployments with ease. Explore the new features and share your feedback through our Community Slack or GitHub Repo.

Pulumi ESC Table Editor Now Supports Dynamic Credential and Secret Integrations

Kimberley Mackenzie — Tue, 10 Sep 2024 00:00:00 -0700

We are pleased to announce a major update to the Pulumi ESC’s Table Editor: full support for provider configurations is now live! When we first introduced the ESC Table view, our goal was to offer a user-friendly interface for managing complex configuration and secrets for your applications and infrastructure. This has empowered teams to focus on what they do best—building and deploying software.

In our initial launch, the Table Editor allowed you to perform CRUD operations on your secrets and plaintext values, decrypt secrets, import environments, and manage variables—all within a visual interface. Today, we’re taking the next step by enabling full read-write support for provider configurations within the Table Editor. This new capability allows you to add, edit, and manage your provider configurations directly from the table view, offering a more integrated and seamless experience.

Primer on ESC Provider Configuration

Pulumi ESC’s provider ecosystem is one of its most powerful features. It supports two categories of providers:

Dynamic Cloud Provider Credentials: Dynamically acquire credentials from cloud providers like AWS, Azure, GCP, and Vault at runtime, eliminating the need for static, long-lived credentials. This enhances security by removing the reliance on dotenv files, locally stored secrets, or long-lived credentials in CI/CD environments, strengthening your workflows’ overall security.
Dynamic Secret Retrieval: ESC retrieves secrets from external secrets managers, such as AWS Secrets Manager, 1Password, and HashiCorp Vault, securely pulling them directly into your environments. Whether you are migrating or utilizing Pulumi ESC’s rich toolset, you can retrieve sensitive information at runtime and apply it seamlessly to your applications.

Enhancing the Table Editor: Provider Configuration Support

With the addition of provider configuration support in the Table view, incorporating Pulumi ESC provider capabilities into your workflow is now more straightforward. A clean, user-friendly form provides step-by-step guidance, promoting best practices like OIDC adoption and the secure handling of sensitive data. This streamlined approach reduces the need for external documentation, making the entire process more intuitive and efficient.

Conclusion

The new provider configuration support in the ESC Table view marks another step in our efforts to simplify and enhance the developer experience. We’re eager to see how you’ll leverage this new capability to streamline your workflows and strengthen your infrastructure’s security. As always, your feedback is invaluable to our development process, and we’re committed to continually improving the Table Editor and other Pulumi tools based on your needs. Please share your feedback with us here.

Check out our documentation to learn more about Pulumi ESC.

Introducing Pulumi ESC Support in Automation API and the Pulumi Service Provider

Arun Loganathan — Wed, 05 Jun 2024 00:00:00 -0500

We’re excited to announce two powerful new capabilities for Pulumi Environments Secrets and Configurations (ESC) that supercharge how you manage and control your infrastructure and application secrets and configurations:

Pulumi Service Provider Support for ESC Environments: Manage your environments as code right alongside your infrastructure including fine-grained access control using Pulumi Service Provider.
Automation API Enhancements for ESC: Seamlessly integrate ESC Environments into your Automation API-based Pulumi projects.

These updates build upon Pulumi ESC’s commitment to simplify and streamline secrets and configuration management providing you with greater control, security, and automation capabilities.

Manage ESC Environments as Code with the Pulumi Service Provider

You can now manage your Pulumi ESC Environments directly within the Pulumi Service using the powerful Pulumi Service Provider. This means you can define environments, add version tags, and even control access using familiar Infrastructure as Code (IaC) practices ensuring consistency and repeatability across your deployments.

Here’s a glimpse of what you can achieve:

Programmatically create and manage ESC Environments: Define environments alongside your infrastructure code for a unified workflow.
Add version tags to environments: Add tags when you are creating the environment.
Enforce granular team permissions: Control who can read, open, or modify your environments ensuring secure collaboration and preventing unauthorized access.

Bringing Pulumi ESC Environments support into the Pulumi Service Provider empowers you to manage your entire infrastructure and application landscape through a unified approach.

Pulumi Service Provider ESC capabilities are available for TypeScript/JavaScript, Go, Python, C#, Java, and YAML. See our Environment, Environment Version Tag, and Environment Permissions Pulumi Service Provider docs. Here are examples of creating environments in TypeScript/JavaScript, Go, and Python:

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

var environment = new service.Environment("testing-environment", {
 organization: "service-provider-test-org",
 name: "testing-environment-ts",
 yaml: new pulumi.asset.StringAsset(
 `values:
 myKey1: "myValue1"
 myNestedKey:
 myKey2: "myValue2"
 myNumber: 1`
 )
})

import pulumi
from pulumi_pulumiservice import Environment

environment = Environment(
 "testing-environment",
 organization="service-provider-test-org",
 name="testing-environment-py",
 yaml=pulumi.StringAsset("""
 values:
 myKey1: "myValue1"
 myNestedKey:
 myKey2: "myValue2"
 myNumber: 1
 """)
)

package main

import (
 "github.com/pulumi/pulumi-pulumiservice/sdk/go/pulumiservice"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := pulumiservice.NewEnvironment(ctx, "testing-environment", &pulumiservice.EnvironmentArgs{
 Name: pulumi.String("testing-environment-go"),
 Organization: pulumi.String("service-provider-test-org"),
 Yaml: pulumi.NewStringAsset(`
 values:
 myKey1: "myValue1"
 myNestedKey:
 myKey2: "myValue2"
 myNumber: 1`),
 })
 if err != nil {
 return err
 }
 return nil
 })
}

Streamline Automated Workflows with Automation API Enhancements

We’re expanding the powerful Pulumi Automation API to include new methods for interacting with Pulumi ESC Environments programmatically. This enables you to seamlessly integrate environment management into your automated workflows and build sophisticated custom tooling.

The new Automation API methods for ESC include:

addEnvironments(...): Append environments in order to your Pulumi stack’s import list.
listEnvironments(): Retrieve a list of environments currently imported into your stack.
removeEnvironment(environment): Remove a specific environment from your stack’s import list.

These additions provide the building blocks for advanced automation scenarios such as dynamically configuring applications based on environments, managing environment dependencies, and integrating ESC into CI/CD pipelines.

Pulumi ESC Automation API capabilities are available for TypeScript/JavaScript, Go, and Python. Here are some examples:

import * as pulumi from "@pulumi/pulumi";
import * as automation from "@pulumi/pulumi/automation";

async function manageEnvironments() {
 const projectName = "myProject";
 const stackName = "dev";

 // Set up your stack options. Here we're using an empty program
 // since we're only manipulating environments, not deploying resources.
 const stackArgs: automation.InlineProgramArgs = {
 stackName,
 projectName,
 program: async () => { },
 };

 // Create or select an existing stack.
 const stack = await automation.LocalWorkspace.createOrSelectStack(stackArgs);

 // Add environments to your stack's configuration.
 // This is like adding them to the `imports` section of an ESC environment.
 await stack.addEnvironments("env1", "env2");
 // The stack's configuration now includes `env1` and `env2`.

 // List the environments currently configured for the stack.
 const environments = await stack.listEnvironments();
 console.log("Current environments:", environments); // Output: ["env1", "env2"]

 // Remove an environment from the stack's configuration.
 await stack.removeEnvironment("env1");
 // The stack's configuration now only includes `env2`.

 // List environments again to confirm the removal.
 const updatedEnvironments = await stack.listEnvironments();
 console.log("Updated environments:", updatedEnvironments); // Output: ["env2"]
}

// Call the async function to execute.
manageEnvironments().catch(console.error);

import pulumi
from pulumi.automation import LocalWorkspace, ProjectSettings, Stack

def manage_environments():
 stack_name = "dev"
 project_name = "myProject"

 # Define the project settings.
 project_settings = ProjectSettings(
 name=project_name,
 runtime="python",
 )

 # Create a LocalWorkspace with the project settings.
 workspace = LocalWorkspace(
 work_dir=".", # Use the current directory as the working directory
 project_settings=project_settings,
 )

 # Create or select an existing stack.
 stack = Stack.create(stack_name=stack_name, workspace=workspace)

 # Add environments to the stack's configuration.
 stack.add_environments("env1", "env2")

 # List the environments associated with the stack.
 environments = stack.list_environments()
 print("Current environments:", environments) # Output: ['env1', 'env2']

 # Remove an environment from the stack's configuration.
 stack.remove_environment("env1")

 # List the environments again to verify the removal.
 updated_environments = stack.list_environments()
 print("Updated environments:", updated_environments) # Output: ['env2']

# Run the function to manage environments.
manage_environments()

package main

import (
 "context"
 "fmt"
 "log"
 "github.com/pulumi/pulumi/sdk/v3/go/auto"
 "github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
 "github.com/pulumi/pulumi/sdk/v3/go/common/workspace"
)

func main() {
 ctx := context.Background()
 projectName := "myProject"
 stackName := "dev"

 // Define the project configuration.
 project := workspace.Project{
 Name: tokens.PackageName(projectName),
 Runtime: workspace.NewProjectRuntimeInfo("go", nil),
 }

 // Create a workspace with the project configuration.
 // Here we're using an empty program since we're only manipulating environments, not deploying resources.
 ws, err := auto.NewLocalWorkspace(ctx, auto.Project(project), auto.Program(nil))
 if err != nil {
 log.Fatalf("Failed to create workspace: %v", err)
 }

 // Create or select an existing stack.
 stack, err := auto.UpsertStack(ctx, stackName, ws)
 if err != nil {
 log.Fatalf("Failed to create or select stack: %v", err)
 }

 // Add environments to the stack's configuration.
 // This is like adding them to the `imports` section of an ESC environment.
 err = stack.AddEnvironments(ctx, "env1", "env2")
 if err != nil {
 log.Fatalf("Failed to add environments: %v", err)
 }
 // The stack's configuration now includes `env1` and `env2`.

 // List the environments associated with the stack.
 envs, err := stack.ListEnvironments(ctx)
 if err != nil {
 log.Fatalf("Failed to list environments: %v", err)
 }
 fmt.Println("Current environments:", envs) // Output: map[env1:{env1} env2:{env2}]

 // Remove an environment from the stack's configuration.
 err = stack.RemoveEnvironment(ctx, "env1")
 if err != nil {
 log.Fatalf("Failed to remove environment: %v", err)
 }
 // The stack's configuration now only includes `env2`.

 // List the environments again to confirm the removal.
 envs, err = stack.ListEnvironments(ctx)
 if err != nil {
 log.Fatalf("Failed to list environments: %v", err)
 }
 fmt.Println("Updated environments:", envs) // Output: map[env2:{env2}]
}

What’s Coming in the Future

We have exciting plans to further enhance these capabilities. Here’s a sneak peek at what’s on the horizon:

Pulumi service Provider: Capabilities to Open, Read, and List any environment versions and version tags
Automation API: Capabilities to author new environments, and assign version tags

Need more features or want to share feedback? We encourage you to open new issues on our GitHub repository or upvote existing ones.

Get Started Today!

These powerful new features are available now! We’re excited to see how you leverage these updates to simplify your secrets and configuration management, enhance your security posture, and unlock new levels of automation.

To learn more and start leveraging the enhanced capabilities of Pulumi ESC check out the following resources:

Pulumi Service Provider for ESC Environment, Environment Version Tag, and Environment Permissions
Pulumi ESC Automation API in TypeScript/JavaScript, Go, and Python

Introducing the Table Editor for Pulumi ESC

Arun Loganathan — Tue, 26 Mar 2024 00:00:00 -0700

We’re excited to announce the launch of the Pulumi Environments, Secrets, and Configurations (ESC) Table Editor. At Pulumi, we’re committed to providing flexible solutions that cater to diverse development needs and practices. This latest addition underscores our dedication to this principle by offering a user-friendly interface for managing complex configurations and secrets.

Pulumi ESC simplifies the management of secrets and configurations by reducing duplication and drift, empowering development teams to focus on building and deploying. The existing YAML-based code editor offers a native way for developers to author and manage configurations.

The Table Editor we are launching today introduces an alternate visual interface for handling configuration tasks, enabling the direct input of plaintext and secret values. Key capabilities of the Table Editor include:

CRUD Operations: Perform Create, Read, Update, and Delete (CRUD) operations on your secrets and plaintext values
Decrypting Secrets: Safely decrypt secrets one at a time, directly within the editor
Environment Imports: Import environments and define the order of imports to suit your project’s needs
Variables Projections: Make variables available as Pulumi Config, environment variables, and files, streamlining your deployment and runtime configuration.
Interpolations and References: Add references to existing path-values, or add interpolations to dynamically generate values

In the current release of the Table view, provider configurations and functions are set to read-only.

What’s Next?

Looking to the future, we are already working on the next set of enhancements for the Table view. Soon, you will have the capability to add and edit provider configurations directly within the table view.

Pulumi ESC’s diverse array of providers not only allows teams to dynamically acquire cloud provider credentials at runtime, thus eliminating the need for static, long-lived credentials but also enables retrieving secrets from external secrets managers, such as AWS Secrets Manager and HashiCorp Vault, directly within ESC. This means users can seamlessly pull and utilize secrets within ESC, enhancing security and flexibility. The upcoming provider configuration support in the Table view will offer a guided experience, simplifying the process of leveraging Pulumi ESC’s comprehensive set of providers.

Conclusion

The launch of the Table view marks an important step in our mission to make infrastructure as code more accessible and manageable for developers.

Your feedback is the cornerstone of our development process. As we look ahead, we’re focusing on incorporating your insights to further enhance the Table view. Together, we can continue to refine and advance Pulumi ESC, making it an even more powerful tool for the developer community.

Check out our documentation to learn more about Pulumi ESC.

Pulumi Blog: Configuration management

Preview ESC Changes with Environment Overrides

Example scenario

Introducing: draft references and the –override-env flag

Example usages

Ways to use it

Get started

Announcing Doppler Providers for Pulumi ESC: Dynamic Login and Dynamic Secrets

Getting Started: Using the Doppler Providers

Prerequisites

How to Use the doppler-login Provider (Dynamic Authentication)

How to Use the doppler-secrets Provider (Dynamically Fetching Secrets)

Conclusion

From Configuration Chaos to Programming Languages

My Background: Coaching Teams Through Technical Transformation

1. Follow the 10% Rule for Sustainable Change

2. Quantify the Cost of Inaction to Overcome Resistance

3. Build Consensus with Nemawashi Conversations

4. Drive Viral Adoption Through Early Wins

5. Align Dev and Ops with Infrastructure as Code

6. Invest in Platform Engineering for Reusable Components

7. Avoid YAML Pitfalls: Embrace Programming Languages

8. Choose Pulumi for Flexible, Code-First IaC

Start Small, Think Big: Small Changes, Big Impact

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

Announcing Infisical Providers for Pulumi ESC: Dynamic Login and Dynamic Secrets

Getting Started: Using the Infisical Providers

Prerequisites

How to Use the infisical-login Provider (Dynamic Authentication)

How to Use the infisical-secrets Provider (Dynamically Fetching Secrets)

Conclusion

Pulumi ESC: Discovering Environment Imports

Understanding Pulumi ESC Imports

What’s New?

Conclusion

Pulumi ESC Table Editor Now Supports Dynamic Credential and Secret Integrations

Primer on ESC Provider Configuration

Enhancing the Table Editor: Provider Configuration Support

Conclusion

Introducing Pulumi ESC Support in Automation API and the Pulumi Service Provider

Manage ESC Environments as Code with the Pulumi Service Provider

Streamline Automated Workflows with Automation API Enhancements

What’s Coming in the Future

Get Started Today!

Introducing the Table Editor for Pulumi ESC

What’s Next?

Conclusion