Pulumi Blog: Secrets

Introducing ESC Secret Rotation Webhooks

Sean Yeh — Fri, 26 Jun 2026 00:00:00 +0000

Pulumi ESC centralizes your secrets and configuration, and it can automatically rotate secrets on a schedule so credentials never go stale. But a rotation is only useful if the systems that depend on it know it happened. ESC secret rotation webhooks close that gap by notifying you the moment a secret rotates.

Introducing secret rotation webhooks

With ESC webhooks, you can react to rotations automatically. When ESC rotates an environment’s secrets, a webhook can be configured to trigger on either success or failure. Use it to notify your team in Slack, refresh services that hold the old credential, or catch a failed rotation before it causes an outage.

How to configure

Pulumi Cloud Console

Using the Pulumi Cloud Console, you can now configure webhooks for “Environment rotation succeeded” and “Environment rotation failed” in your ESC Environment’s Settings page (under Settings -> Notifications).

Pulumi Service Provider

You can use the Pulumi Service Provider in your Pulumi program to configure webhooks. Here is an example in TypeScript:

const environmentWebhook = new service.Webhook("env-webhook", {
 active: true,
 displayName: "env-webhook",
 organizationName: "my-org",
 projectName: environment.project,
 environmentName: environment.name,
 payloadUrl: "https://example.com",
 filters: [WebhookFilters.EnvironmentRotationSucceeded, WebhookFilters.EnvironmentRotationFailed],
})

Pulumi CLI

You can also use the Pulumi CLI to configure the webhook:

pulumi env webhook new my-org/project/env env-webhook \
--url https://example.com \
--event environment_rotation_succeeded \
--event environment_rotation_failed

Get started

Secret rotation webhooks are available now for all Pulumi ESC environments. See the webhooks documentation to get started, and share your feedback on our GitHub repository.

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.

Deletion Protection for Pulumi ESC Environments

Fausto Núñez Alberro — Mon, 03 Nov 2025 14:00:00 -0700

Pulumi ESC environments can now be protected from accidental deletion with a new deletion protection setting.

Environments often contain configuration that supports production workloads or is shared across multiple stacks. Deleting these environments by mistake can disrupt services and require time-consuming recovery. Deletion protection provides a safeguard against these scenarios.

How it works

When deletion protection is enabled for an environment, any attempt to delete it fails until protection is explicitly disabled. This applies to deletions from both the Pulumi Cloud console and the Pulumi CLI.

Protected environments display a shield icon in the environment list and on stack pages where the environment is imported. The icon links directly to the deletion protection settings.

Managing deletion protection

In the Pulumi Cloud console, navigate to your environment’s settings to enable or disable deletion protection with a toggle.

From the CLI, use the new pulumi env settings commands:

# Enable protection
pulumi env settings set myorg/myproject/prod deletion-protected true

# View current setting
pulumi env settings get myorg/myproject/prod deletion-protected

# Disable protection
pulumi env settings set myorg/myproject/prod deletion-protected false

Attempting to delete a protected environment returns a clear error message with instructions.

When to use deletion protection

Enable deletion protection for:

Production environments
Environments imported by multiple stacks
Environments shared across teams
Any environment containing configuration that should persist

Permissions

Only environment admins can modify deletion protection settings. This ensures that protection cannot be removed without appropriate authorization.

Getting started

Deletion protection is available now for all Pulumi ESC environments. Visit your environment settings or use the Pulumi CLI to enable it.

For more information, see the deletion protection documentation.

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.

Bring Your Own Keys With Pulumi ESC

Pablo Terradillos — Wed, 18 Jun 2025 13:25:26 -0300

Today we’re excited to launch support for Customer-Managed Keys (CMKs) in Pulumi ESC. This feature gives your organization full control over how your secrets and state are encrypted — empowering you to meet the most demanding compliance requirements like HIPAA, GDPR, and FedRAMP, all while maintaining the ease-of-use that Pulumi is known for.

Why Customer-Managed Keys?

Pulumi encrypts secrets and other sensitive information stored in ESC using data keys, which are encrypted with Pulumi-Managed Keys using strong security standards. However, customers might need to use their own keys to gain full control over their lifecycle and revocation, maintain a centralized audit trail, and enforce custom rotation policies. This is especially important to meet compliance requirements or specific regulations (e.g., HIPAA, GDPR, FedRAMP, etc.). Customer-Managed Keys give customers that control while keeping these aspects transparent for the consumers of those secrets.

How It Works

Customer-Managed Keys integrate seamlessly with your Pulumi Cloud Organization. Once enabled, all existing data keys used to encrypt your ESC secrets, previously encrypted with the Pulumi-managed key, will be automatically re-encrypted with the new CMK.

Setting it up takes just a few minutes:

Create a KMS key in your AWS account.
Grant access to the KMS key using OIDC in your AWS account.
Configure your Pulumi Cloud organization to use your new KMS key.

Available Today

Customer-Managed Keys with support for AWS KMS are available today for all organizations on the Pulumi Enterprise or Business Critical plans. You can set it up by following the instructions in the Pulumi Cloud documentation.

We expect to add support for more cloud providers in the future. Please vote on the following GitHub issues for your favorite to support prioritization:

We’re excited to see how Customer-Managed Keys help you and your organization meet your compliance goals with Pulumi Cloud. Your feedback is essential as we continue to evolve this feature:

Connect with us in the Pulumi Community Slack
Open an issue on GitHub
Read the full documentation on Customer-Managed Keys

Try this today, Get Started with Pulumi for free

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 Automated Database Credential Rotation for PostgreSQL and MySQL in Pulumi ESC

Sean Yeh — Wed, 30 Apr 2025 00:00:00 +0000

Securing access to critical data stores is paramount in today’s cloud-native world. Yet, managing database credentials often involves static, long-lived passwords – a significant security blind spot. These static secrets, frequently embedded in application configurations or accessible to multiple team members, represent a prime target for attackers. Manually rotating these credentials is a cumbersome, error-prone task that’s often neglected, leaving databases vulnerable for extended periods. Building on our commitment to robust secrets management, we are excited to launch Automated Database Credential Rotation for PostgreSQL and MySQL in Pulumi ESC!

The Persistent Challenge of Static Database Secrets

Relying on static database credentials introduces substantial risks, which automated rotation helps mitigate:

Security Vulnerabilities & Exposure: Static credentials, if compromised through leaks, phishing, or unauthorized access, provide long-term access to attackers. Automated rotation significantly shrinks this window of opportunity.
Operational & Compliance Burdens: Manually rotating database credentials is complex, error-prone, and requires careful coordination to avoid downtime. These manual rotations are hard to audit and demonstrate compliance with regulations like SOC 2, GDPR, or HIPAA (which often mandate rotation).
Network Complexity & The DIY Burden: Databases in private networks (like AWS VPCs) require secure access for rotation. We provide an open-source Lambda connector for AWS VPCs. While homegrown solutions can bridge the network gap, building and maintaining the actual rotation logic (state, error handling, two-secret strategy) is complex. Crucially, DIY approaches typically lack integrated revision history, centralized auditing, and unified management provided by platforms like Pulumi ESC, increasing operational overhead.
Tooling, Ecosystem, and Cloud-Native Connectivity: Despite cloud IAM authentication options, many standard tools (GUIs, BI, ETL), legacy apps, and even certain cloud-native configurations (multi-cloud, specific Kubernetes setups) still rely on username/password. Direct IAM integration isn’t always feasible or practical, making automated rotation of traditional credentials essential for broad compatibility and security.

Pulumi ESC addresses these challenges by automating the secrets rotation process, including connectivity options for databases in private AWS networks using our Lambda connector, and allows you to consume them in your applications through ESC’s various developer-friendly methods including ESC SDK, Pulumi CLI, Kubernetes External Secrets Operator, CSI Driver, etc.

Introducing ESC Rotated Secrets for Databases

Pulumi ESC’s Rotated Secrets capability now extends to your critical databases, bringing automation and enhanced security to credential lifecycle management. We are adding support for the following databases and connectivity options:

Database	Publicly Accessible	AWS VPCs	Azure VNETs	GCloud VPCs
PostgreSQL	✅	✅ (via Lambda)	Planned (upvote issue)	Planned (upvote issue)
MySQL	✅	✅ (via Lambda)	Planned (upvote issue)	Planned (upvote issue)

Key benefits include:

Automated Rotation Schedules: Effortlessly define rotation frequencies (daily, weekly, monthly) that align with your security policies, eliminating manual toil and ensuring consistency.
On-Demand Rotation: Instantly rotate credentials in response to security events, personnel changes, or policy updates with a single click or command.
Seamless ESC Environment Integration: Manage rotated database credentials alongside all your other application configurations within ESC Environments, leveraging composition and environment inheritance.
Two-Secret Strategy: ESC maintains both the current and previous valid credentials simultaneously. This prevents application downtime during rotation, as instances can gracefully transition to the new credential.
Auditing and Tracking: Maintain a complete audit trail of credential rotations, including who initiated the rotation and when, simplifying compliance and governance.
Admin and Creator Control: Securely configure rotation using privileged database “managing user” credentials stored within ESC, keeping them separate from the rotated credentials consumed by applications.
Configure Webhooks for Automation: Trigger notifications, CI/CD pipelines (e.g., Pulumi Deployments to update application stacks), or custom workflows upon successful rotation, keeping dependent systems synchronized.

The following setup guide provides a detailed walkthrough for rotating PostgreSQL credentials for an AWS RDS instance hosted within a private VPC, which requires the AWS Lambda-based connector. For publicly accessible databases (PostgreSQL or MySQL), you can use the simpler Direct Connect method documented on the respective integration pages. Please refer to the MySQL documentation page for specific instructions on MySQL rotation (both Direct Connect and Lambda Connector).

How to Set Up and Use Rotation for AWS RDS PostgreSQL running in VPC

Setting up rotation for AWS RDS or Aurora PostgreSQL databases running inside an AWS VPC involves creating the required users within your database, deploying the AWS Lambda connector infrastructure via a Pulumi template, configuring ESC environments, and scheduling the rotation.

Understanding the AWS Lambda Connector: The open-source ESC Lambda connector acts as a secure proxy for database credential rotation within your VPC. It enables Pulumi ESC to safely rotate database credentials without needing direct network access from ESC to your database and without exposing your database to external networks. This connector is currently required to rotate credentials for PostgreSQL or MySQL databases hosted within an AWS VPC. Note: The AWS Lambda Connector is only available to Enterprise and Business Critical customers.

Step 1: Prepare Your PostgreSQL Database Users

You’ll need two types of users configured, resulting in three specific database user accounts:

Managing User: A privileged user that ESC will use (via the Lambda connector) to perform the password rotations. This user needs permissions to change the passwords of the application users.
Application User 1 and Application User 2: The two application users whose passwords ESC will manage. ESC rotates between these two users, ensuring two users are always active as applications gradually phase out the previous user credentials.

Connect to the database as a superuser and run the following SQL commands:

Create the application users whose passwords you want ESC to rotate automatically:

```sql
CREATE USER user1 WITH PASSWORD 'initial_password';
GRANT SELECT, INSERT, UPDATE ON yourDatabase TO user1;
CREATE USER user2 WITH PASSWORD 'initial_password';
GRANT SELECT, INSERT, UPDATE ON yourDatabase TO user2;
```

Create the designated “managing user” account with privileges to modify passwords for the application users:

```sql
CREATE USER managing_user WITH PASSWORD 'manager_password';
ALTER USER managing_user WITH CREATEROLE;
GRANT user1 TO managing_user WITH ADMIN OPTION;
GRANT user2 TO managing_user WITH ADMIN OPTION;
```

Step 2: Bootstrap Rotation Infrastructure (Lambda Connector) and Create ESC Environments

To rotate credentials for PostgreSQL databases within AWS VPCs securely, you need to configure an AWS Lambda function (the connector) within your VPC and create the corresponding ESC environments.

If your PostgreSQL instance is running on AWS RDS, we recommend using our Pulumi Template to simplify the process of creating the Lambda function, associated AWS IAM Roles, Security Groups, and the basic ESC environment structure. You can start it from the Pulumi console or by running the following command in your terminal:

Run pulumi new esc-connector-lambda-typescript in your terminal.
This command initializes a new Pulumi project designed to provision the necessary AWS Lambda connector resources and create the ESC environments.
Follow the prompts. You will first provide a Pulumi project name (e.g., my-db-rotation-infra). Then, you will be prompted for configuration values like:
- Your target AWS Region (aws:region)
- The RDS Database Identifier (rdsDbIdentifier)
- The specific name for the ESC rotation environment (e.g., postgresrotation/Rotator). This environment will contain the two application users’ credentials and configuration for rotation.
- The specific name for the ESC managing credentials environment (e.g., postgresrotation/ManagingCreds).
Run pulumi up to deploy the AWS resources and create the ESC environments using the names you provided.

Step 3: Configure ESC Environments and Test

The Pulumi template creates two ESC environments with most of the configuration pre-filled. You need to update them with your specific PostgreSQL user credentials and database name.

Managing Credentials Environment (e.g., postgresrotation/ManagingCreds): Navigate to this environment in the Pulumi Cloud console. Update the managing user’s username and password. The awsLogin section, which provides credentials for the Lambda connector to assume, should be pre-filled by the template.

# postgresrotation/ManagingCreds
values:
 managingUser:
 username: managing_user # Replace with your managing user's name
 password:
 # Securely replace the placeholder with your managing user's password using fn::secret
 fn::secret:
 ciphertext: ZXNjeA... # Replace with your encrypted password
 awsLogin:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: arn:aws:iam::616138583583:role/PulumiEscSecretRotatorLambda-InvocationRole-7e4646f # Example Role ARN populated by template
 sessionName: pulumi-esc-secret-rotator-${esc.context.environment} # Example Session Name populated by template

Rotation Environment (e.g., <project-name>/Rotator): Navigate to this environment. Most fields related to the Lambda connector (Lambda ARN, host, port, references) are pre-filled by the template outputs. You must update the database name and the application usernames mapping. Note the connector.awsLambda block indicating the use of the Lambda connector.

# postgresrotation/Rotator
values:
 dbRotator:
 fn::rotate::postgres:
 inputs:
 database:
 # Configure the AWS Lambda connector for private VPC access
 connector:
 awsLambda:
 login: ${environments.postgresrotation.ManagingCreds.awsLogin}
 lambdaArn: arn:aws:lambda:us-west-2:616138583583:function:PulumiEscSecretRotatorLambda-Function-d9932fe # Example Lambda ARN populated by template
 # Database connection details (used by the Lambda connector)
 database: mydb # Replace with your DB name
 host: tf-20250428212643894700000001.cluster-chuqccm8uxqx.us-west-2.rds.amazonaws.com # Example Host populated by template
 port: 5432 # Example Port populated by template
 managingUser: ${environments.postgresrotation.ManagingCreds.managingUser}
 # List of application users whose passwords will be rotated
 rotateUsers:
 username1: user1 # Replace DB username if different from logical name
 username2: user2 # Replace DB username if different from logical name

 # state section is automatically managed by ESC after first rotation
 # Do not provide state unless migrating existing, known credentials.
 # state:
 # current:
 # password:
 # fn::secret:
 # ciphertext: ZXNjeAAAA...
 # username: user1
 # previous:
 # password:
 # fn::secret:
 # ciphertext: ZXNje21AA...
 # username: user2

Test with Manual Rotation:
- Use the triple-dot menu -> “Rotate Secrets” in the Pulumi Cloud UI for the Rotator environment.
- Alternatively, use the Pulumi CLI: pulumi env rotate <your-org>/<project-name>/Rotator> (e.g., pulumi env rotate myorg/postgresrotation/Rotator). Remember to replace <your-org> and <project-name>.
- Perform a rotation. If you didn’t provide the state block, this first rotation generates a new password for the user designated as current (e.g., user1 associated with username1) and updates it in the database via the Lambda connector. The dbRotator value in ESC will now show this user/password under current, and the state block will be populated.
- Perform a second rotation. Observe how the previous current user (user1/username1) and its password become the previous entry in the ESC value. The system now rotates the password for the other user (user2/username2), makes it the new current, and updates the database accordingly. Subsequent rotations cycle between user1 and user2.
- Check the Environment Revision History in the Pulumi Cloud console to track the changes to the current and previous state fields after each rotation.

Step 4: Schedule Automated Rotations

Once you are satisfied that manual rotations via the Lambda connector are working correctly, navigate to the “Secret Rotation” tab for your Rotator environment (e.g., postgresrotation/Rotator) in the Pulumi Cloud console.
Define your desired automated rotation schedule (e.g., every 30 days). ESC will automatically trigger rotations according to this schedule, ensuring your credentials stay fresh without manual intervention.

What’s Next?

This launch significantly enhances database security posture through automation for PostgreSQL and MySQL, but we’re just getting started. We plan to expand our rotated secrets capabilities:

More Databases: Support for MongoDB, Microsoft SQL Server, Oracle, and others.
Databases in Private Networks on Other Clouds: Rotation solutions for databases hosted in private networks within Azure, Google Cloud, and more.

Have a specific database or integration in mind? Upvote existing issues or open a new request in our GitHub repository!

Conclusion

Pulumi ESC’s Automated Database Credential Rotation drastically simplifies a critical security task. By automating the rotation of PostgreSQL and MySQL credentials, ESC reduces operational overhead, minimizes the risk associated with static secrets, and helps you meet compliance requirements more easily. Whether your databases are publicly accessible (using Direct Connect) or in private AWS networks (using the Lambda connector), ESC provides a unified way to manage their lifecycle securely.

We encourage you to explore the Pulumi ESC documentation and try out rotated database secrets for PostgreSQL and MySQL. Your feedback is invaluable – please share your experiences and suggestions on our GitHub repository. Secure your databases with automated rotation and build with confidence!

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.

Why Every Cloud Engineer Needs Pulumi ESC for Secrets Management

Sara Huddleston — Mon, 17 Mar 2025 07:28:56 +0000

Managing secrets is one of the most critical responsibilities in cloud engineering. Secrets like API keys, database credentials, and encryption tokens are the backbone of secure and seamless cloud operations. Yet they are so often an afterthought. They get replicated across cloud-specific secrets managers and stuffed in GitHub secrets, compromising security for the sake of simplicity. ¿Por que no los dos? Why can’t secrets management be secure and simple?

Enter Pulumi ESC (Environments, Secrets, and Configuration)—a breakthrough in taming secrets sprawl and streamlining configuration management across infrastructure. Let’s explore why Pulumi ESC is a necessity for cloud engineers, helping make secrets management secure while keeping it simple.

The Challenge of Secrets Management in Modern Cloud Environments

Secrets management has changed significantly over the past decade. Gone are the days when secrets could be hardcoded, manually maintained in static configuration files, or left floating around in plaintext on dev machines. Nowadays, cloud environments demand a higher level of sophistication:

Distributed Systems: Even in multi-cloud and hybrid setups, secrets must be accessible across varied platforms without exposing vulnerabilities.
Dynamic Infrastructure: Kubernetes, serverless architectures, and ephemeral environments must have secrets that adapt dynamically.
Security Risks: Hardcoded or poorly managed secrets can lead to catastrophic breaches, costing companies millions in data recovery and compliance penalties.
Operational Burdens: Manual secrets management is error-prone, inefficient, unscalable, and needs to align with DevOps and DevSecOps best practices.

Pulumi ESC addresses these issues head-on, redefining how cloud engineers manage secrets efficiently, securely, and at scale.

Jk Jensen, Team Lead at Mysten Labs, said:

“Pulumi ESC has been a lifesaver for us. It’s nice to throw everything behind an ESC environment and eliminate one-off granting/IAM permissions and other issues related to static credentials. It gives us peace of mind knowing that we can grant permissions quickly and revoke easily limiting blast radius for any access.”

What is Pulumi ESC?

Pulumi ESC simplifies how organizations manage secrets and configurations. It is designed to secure sensitive configurations across modern cloud environments and supports seamless integration, enabling engineers to:

Access, share, and manage secrets, passwords, API keys, and configuration settings like network and deployment options.
Synchronize secrets and configuration from any secrets manager to any app, tool, or CI/CD platform.
Access secrets securely through CLI, API, Kubernetes operator, the Pulumi Cloud UI, and in-code with Typescript/Javascript, Python, and Go SDKs.
Connect to cloud providers and secrets stores via OIDC to generate dynamic, short-lived, auto-expiring credentials.
Set role-based access controls (RBAC), making securing secrets and configurations easy by assigning permissions to users based on their roles.

Whether integrated with Pulumi’s Infrastructure as Code (IaC) platform or used as a standalone service, Pulumi ESC enables cloud engineers to streamline secrets management with centralized control.

Key Features of Pulumi ESC

1. Seamless Integration with External Platforms

Pulumi ESC integrates with popular secrets providers, including AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, and HashiCorp Vault, making it adaptable for multi-cloud and hybrid cloud architectures.

2. Dynamic Secrets Synchronization with ESO

Partnering with the External Secrets Operator, Pulumi ESC synchronizes secrets securely into Kubernetes clusters. This eliminates hardcoding secrets into manifests or relying on unsecured manual processes.

3. Safely Roll Back to a Previous Version

Pulumi ESC Versioning gives you unprecedented control over your secrets and configuration. Every change is captured in an immutable revision history, allowing you to audit modifications, compare versions, and safely roll back.

4. Secure by Design

Pulumi ESC follows a “secure by default” model, employing encryption, access control, and detailed audit trails. Engineers can meet compliance regulations effortlessly while gaining full visibility into secret access patterns.

5. Automated Rotation and Expiry

Pulumi ESC minimizes security risks by automating the rotation of secrets. This feature aligns secrets management with CI/CD processes for cloud engineers focused on DevOps, ensuring credentials remain valid only when needed.

6. Configuration-as-Code, Automation, and Integration Everywhere

Pulumi ESC embraces an “as-code” approach, enabling configuration and secrets management using TypeScript, JavaScript, Go, Python, or YAML. The ’esc’ CLI and API support automation in CI/CD environments, reducing credential duplication and ensuring a single source of truth.

7. Dev Tools Integrations

Pulumi ESC’s metadata and support for popular configuration formats enable seamless integration with tools like Direnv, Docker, and GitHub, allowing easy management of environment variables, secrets, and configurations.

8. Infrastructure Tools Integrations

Pulumi ESC extends its capabilities beyond Pulumi IaC by integrating with other infrastructure tools such as Cloudflare, Terraform, and OpenTofu. These integrations enable seamless provisioning of cloud credentials and input variables directly from ESC environments.

Why Cloud Engineers Need Pulumi ESC

Enhanced Security and Compliance

Cloud engineers often have to balance security and operations. Pulumi ESC centralizes secrets in a secure vault, ensuring encrypted storage, access control, and audit visibility. It also complies with industry standards like SOC 2, PCI-DSS, and MTCS.

Streamlined Multi-Cloud Management

Managing secrets across AWS, Azure, and GCP can quickly become chaotic. Pulumi ESC’s cross-platform integration simplifies this process, ensuring engineers can manage and sync secrets from a single interface.

Simplified Kubernetes Secrets

Kubernetes’ default secrets offer limited security and scalability. Pulumi ESC with ESO and Secrets Store CSI Driver overcomes these limitations by securely synchronizing and managing secrets within Kubernetes clusters. This prevents unauthorized access and provides automated updates.

Zero Downtime Through Automation

Manual secrets management often leads to errors such as expired credentials or outdated tokens. Pulumi ESC automates the entire lifecycle of secrets—creation, rotation, replication, and expiry—guaranteeing uninterrupted services.

Developer-Friendly Workflows

Tools should make engineers’ lives easier, not harder. Pulumi ESC’s CLI, SDKs, and API provide intuitive ways to integrate into existing workflows. For cloud engineers leveraging Infrastructure as Code with Pulumi, managing secrets alongside the stack becomes effortless.

Thomas Meckel, Senior Cloud Architect at Ophios GmbH, explains:

“Pulumi’s built-in encryption of secrets sets it apart as a leader in secure infrastructure management. Unlike other tools that leave sensitive data exposed or require complex configurations, Pulumi ensures secrets are encrypted by default, leveraging flexible options like Azure Key Vault or AWS KMS. This eliminates the risk of plaintext exposure and simplifies secure deployments. For any organization serious about cloud security, Pulumi’s approach to secrets management is a critical differentiator, combining ease of use with robust protection against breaches.”

Kubernetes Secrets Management

For secrets management in Kubernetes environments, Pulumi ESC becomes even more powerful when paired with External Secrets Operator (ESO) or the Secrets Store CSI Driver. Here’s how it works:

Using Pulumi ESC with External Secrets Operator

External Secrets Operator is an open-source Kubernetes operator that syncs secrets from external providers (like Pulumi ESC) into Kubernetes as native secrets.

Centralized Storage: Store secrets securely in Pulumi ESC and synchronize them with Kubernetes across multiple clusters.
Dynamic Updates: Whenever a secret is updated in ESC, ESO automatically replicates the changes into Kubernetes, eliminating manual intervention.
Granular Management: Define which secrets are synchronized and to which namespaces, ensuring tight access controls and minimizing risk.
Automated Secret Rotation: By leveraging ESC’s rotation capabilities, ESO ensures Kubernetes receives refreshed credentials without requiring downtime.

Learn how to manage Kubernetes secrets with Pulumi ESC and External Secrets Operator: The Perfect Solution for Today’s Cloud-Native Secret Management.

Using Pulumi ESC with Secrets Store CSI Driver

The Secret Store CSI Driver mounts secrets, certificates, and keys from external stores into Kubernetes pods as volumes.

Automated Secrets Injection: Secrets Store CSI Driver enables Pulumi ESC to automatically inject secrets into Kubernetes pods as mounted volumes or environment variables. This reduces the manual overhead of managing secrets directly in Kubernetes.
Secure and Dynamic Secret Access: By leveraging Pulumi ESC, Kubernetes applications can securely fetch secrets from external providers, ensuring dynamic access without exposing credentials in pod specifications.
Streamlined Operations: This integration simplifies the process of synchronizing secrets from Pulumi ESC with Kubernetes-native constructs. The automation reduces errors and boosts efficiency.

Learn how to Master Kubernetes Secrets with Pulumi ESC + Secrets Store CSI Driver.

The Future of Secrets Management with Pulumi ESC

Pulumi ESC is more than just a secrets management tool — it’s the foundation of secure, scalable, and agile cloud operations. For cloud engineers grappling with multi-cloud complexity, Kubernetes deployments, and compliance concerns, it provides a streamlined, automated approach that enhances efficiency and security.

With rising cyber threats and stricter data regulations, adopting tools like Pulumi ESC is no longer optional. It’s a competitive advantage for cloud engineers and organizations aiming to lead in today’s cloud-native world.

Next Steps to Secure Your Secrets

Secrets management doesn’t have to be a headache! With Pulumi ESC, you can safeguard your infrastructure, ensure compliance, and eliminate manual errors—all while enhancing security and agility.

Get started with Pulumi ESC today and experience the future of secrets management. Take control of your cloud environment—securely and effortlessly.

Faster Secrets in Pulumi IaC

Daniel Bradley — Thu, 13 Mar 2025 01:00:00 -0700

Pulumi now handles secrets more efficiently through optimized encryption and decryption processes, reducing deployment times while maintaining security standards. Users of Pulumi Cloud for state management will notice the most improvement due to new batch API capabilities.

Secrets Management in Pulumi

Pulumi Infrastructure as Code (IaC)’s built-in secrets management encrypts individual secrets within the stack for fine-grained protection. Pulumi Cloud transmits and stores stack state securely, ensuring that sensitive information—such as database passwords, API keys, and access tokens—remains protected even if someone gains access to your stack file. For organizations with more complex secrets management needs, Pulumi also offers Pulumi ESC (Environments, Secrets, and Configuration), which provides centralized secrets management with hierarchical environments and dynamic credential generation.

Beyond simple encryption, Pulumi tracks the transitive use of secrets to prevent accidental exposure of sensitive values. This tracking works across your entire infrastructure definition, ensuring secrets remain protected:

Within the stack state
In CLI output
In the Pulumi Cloud console

When using Pulumi Cloud as your secrets provider, all encryption and decryption operations happen server-side without transmitting the encryption key to the Pulumi program. Combined with Pulumi Cloud’s robust user authorization and SSO integration, this creates a comprehensive security framework that ensures only authorized team members can access sensitive information.

Performance Challenges with Secrets

While security is paramount, performance is equally crucial for developer productivity. Every second spent waiting for encryption or decryption operations is time not spent building and improving your infrastructure.

Previously, when working with stacks containing numerous secrets, users could experience noticeable delays during operations that required encryption or decryption. This was primarily due to:

Individual network requests for each secret operation
Network latency compounding with each separate request

For teams with complex infrastructure containing dozens or hundreds of secrets, these delays could add up to significant wait times.

Our Performance Improvements

We’ve reduced network overhead by batching encryption work into a single request instead of making separate encryption requests for each secret. This batching approach:

Reduces the total number of HTTP requests
Minimizes the impact of network latency
Allows for more efficient server-side processing

This is combined with identifying when no secrets have changed between intermediate deployment steps to bypass the work of re-encrypting all secrets.

Measurable Performance Gains

The performance improvements are particularly noticeable for stacks with many secrets or in environments with higher network latency:

Secrets Count	Network Latency	Typical Time Savings
10	100ms	~1 second
25	150ms	~4 seconds
50+	150ms	10+ seconds
100+	150ms	20+ seconds

The performance improvements are noticeable for stacks with many secrets or in environments with higher network latency. For teams running CI/CD pipelines with frequent deployments, these savings compound throughout the day, potentially saving significant cumulative wait time across your engineering organization.

Getting Started

To benefit from these performance improvements:

Update to Pulumi IaC version 3.155.0 or later
No configuration changes are needed—the optimizations work automatically
Ensure you’re using Pulumi Cloud as your secrets provider for additional speed gains

These improvements maintain complete backward compatibility with existing stacks and secret values. Your existing encrypted secrets will continue to work without any migration steps required.

Conclusion

At Pulumi, we’re committed to providing both robust security and exceptional performance. These secrets management optimizations represent our ongoing effort to improve the developer experience without compromising on security.

By reducing wait times during encryption and decryption operations, we’re helping teams be more productive while maintaining the same high level of protection for sensitive information. This update exemplifies our philosophy that security and performance should complement rather than compete with each other.

Beyond Stack Secrets: Pulumi ESC

While these performance improvements enhance Pulumi’s built-in secrets management, some organizations require more advanced capabilities. If you need secrets to be centrally managed, composable, and reusable across teams and applications, Pulumi ESC (Environments, Secrets, and Configuration) may be a better fit. Pulumi ESC keeps sensitive information out of source control, supports hierarchical environments, and enables dynamic credential generation. It’s designed for organizations that need to share secrets between multiple teams, applications, and infrastructure deployments while maintaining strict access controls and auditability.

Get Started Today

Update to Pulumi IaC 3.155.0 today to experience these performance improvements and let us know what you think!

Announcing the Pulumi ESC GitHub Action

Komal Ali — Wed, 05 Mar 2025 00:00:00 +0000

We’re excited to share our latest addition to the Pulumi Ecosystem: the Pulumi ESC GitHub Action. This Action lets you inject secrets and configuration securely into your GitHub Actions workflows as they are needed, rather than storing them as static, long-lived secrets.

Why we built it

Secret management continues to be a challenge for organizations of all sizes. Storing long-lived credentials in multiple places (e.g., GitHub, third-party CI systems, and internal servers) often leads to “secret sprawl” and potential security gaps. With Pulumi ESC, you can migrate to dynamic credentials, and ensure secrets don’t persist beyond their necessary lifetime. If your process requires longer-lived static credentials, with ESC you can manage credentials in a central place and rotate them automatically.

By packaging ESC functionality into a GitHub Action, we’re enabling teams to inject secrets and run ESC commands directly within their GitHub workflows. This allows for a streamlined approach to environment management and secrets rotation—without leaving GitHub.

Key benefits

Secure Secrets Injection - Inject secrets into your GitHub Actions workflows as they are needed, rather than storing them as static, long-lived secrets. This dynamic approach reduces the risk of secrets leaking in logs or pulled from unauthorized sources.
Automatic Secret Rotation - Pulumi ESC handles rotation for you behind the scenes, ensuring that any secrets or credentials you inject into GitHub Actions are valid at the time of use, but rotated on a regular schedule to avoid the risks that come with long-lived static secrets.
Streamlined CI/CD Pipeline - In addition to injecting environment variables, you can run any Pulumi ESC command directly in your GitHub Actions workflows. Automate the creation, update, or teardown of ESC Environments as part of your CI/CD process.
Seamless Integration with Pulumi Cloud - Combine the Pulumi ESC GitHub Action with pulumi/auth-actions to authenticate securely with Pulumi Cloud. No need for long-lived tokens — simply leverage short-lived tokens provided at runtime.

How it works

At a high level, the Pulumi ESC GitHub Action can do three things:

Install the Pulumi CLI - By default, the action ensures the Pulumi CLI is installed in your GitHub Actions environment. If you provide a specific version, that version is installed.
Inject all environment variables from an ESC environment - If you specify an environment (for example, tinyco/someProject/myEnv), the action will inject all environment variables and projected files associated with that environment into the GitHub Actions context.
Inject specific environment variables from an ESC environment - If you only need certain keys, you can specify them in the action’s inputs to pick and choose what gets injected, giving you fine-grained control.

Example workflow

Below is a minimal workflow that showcases injecting an entire environment’s variables into your GitHub Actions job:

on:
 - pull_request

permissions:
 id-token: write
 contents: read

jobs:
 test-env-injection:
 runs-on: ubuntu-latest
 steps:
 - name: Check out repository
 uses: actions/checkout@v4
 - name: Authenticate with Pulumi Cloud
 uses: pulumi/auth-actions@v1
 with:
 organization: pulumi
 requested-token-type: urn:pulumi:token-type:access_token:organization
 - name: Install and inject ESC environment variables
 uses: pulumi/esc-action@v3
 with:
 environment: 'tinyco/someProject/myEnv@stable'
 - name: Verify environment variables
 run: |
 echo "FOO=$FOO"
 echo "SOME_IMPORTANT_KEY=$SOME_IMPORTANT_KEY"
 echo "TEST_ENV=$TEST_ENV"

The GitHub Action workflow above does the following:

Authenticate with Pulumi Cloud using pulumi/auth-actions. Instead of storing a permanent token, we use a short-lived token to authenticate with Pulumi Cloud.
Inject the environment variables from tinyco/someProject/myEnv into the current GitHub Actions environment, making them accessible to subsequent steps in the workflow.

What’s Next?

Explore More ESC Features: Dive deeper into ESC’s environment management, secret rotation, and dynamic credentials.
Contribute to the GitHub Action: The Pulumi ESC GitHub Action is open source. Feel free to open issues, submit PRs, or suggest enhancements.
Join the Pulumi Community: Connect with other Pulumi users and share best practices in our Community Slack.

We’re thrilled to bring you the Pulumi ESC GitHub Action, allowing you to automate your infrastructure and streamline secrets management from within GitHub. This integration makes it simpler than ever to adopt best-in-class secrets management and environment configuration practices, all while speeding up your CI/CD pipelines.

Have questions or feedback? Feel free to reach out to us in our Community Slack or submit an issue on GitHub. We can’t wait to see what you build!

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!

Master Kubernetes Secrets with Pulumi ESC + Secrets Store CSI Driver

Engin Diri — Wed, 18 Dec 2024 09:58:01 +0100

Welcome to the second blog post of the Pulumi ESC and Kubernetes secrets series. If you haven’t had the chance to read the first blog post, go ahead and read it here.

In the previous blog post, we have learned how to manage secrets with Pulumi ESC and the External Secrets Operator. While the External Secrets Operator is a great tool to manage secrets in a cloud-native way, it still creates Kubernetes secrets in the cluster. Depending on your security requirements, you might want to avoid the use of Kubernetes secrets in your cluster at all. This is the point where you hit the limits of the External Secrets Operator.

But don’t worry, we also have a solution for this problem. In this blog post, we will introduce the Secrets Store CSI Driver.

TL;DR?

Jump straight to the comparison of the External Secrets Operator and the Secrets Store CSI Driver here.

Refresher: Why Should You Avoid Using Kubernetes Secrets?

Before we dive into the Secrets Store CSI Driver, let’s quickly recap why you might want to avoid using native Kubernetes secrets. I wrote in depth about this topic in the previous blog post, but here is a quick summary:

By default, etcd stores them in a base64-encoded format, which is not secure.
Developers create them either manually by using kubectl commands or by using a manifest file, which makes them hard to manage at scale.
Hard to manage and synchronise secrets across different environments and clusters.
There is no default way to rotate secrets automatically.

Point 1 is the most critical one, as there is even a warning in the Kubernetes documentation:

Kubernetes Secrets. Credit: kubernetes.io/docs/concepts/configuration/secret/

What is the Secrets Store CSI Driver?

The first thing you may notice is that in the name of the Secret Store CSI Driver, there is a reference to the Container Storage Interface (CSI) standard.

What is CSI and why it is used in the Secret Store CSI Driver*?*

How to write a Container Storage Interface (CSI) plugin. Credit: arslan.io/2018/06/21/how-to-write-a-container-storage-interface-csi-plugin/

Container Storage Interface (CSI)

The Container Storage Interface (CSI) is a standard to unify the interface between container orchestrators (like Kubernetes) and different storage vendors (like NetApp, Ceph, etc.). This helps to guarantee that implementing a CSI for a storage vendor is going to work with all orchestrators that support CSI.

Before CSI, we needed to create volume plugins for every orchestrator and storage vendor. This meant that developers coupled volume plugin development with the Kubernetes version and made it dependent on it. Bugs in volume plugins could break the Kubernetes components, instead of the volume plugin. Besides, volume plugins had full privileges on the Kubernetes components like the kubelet.

Combining CSI, Kubernetes and Secrets = Secret Store CSI Driver

The Secret Store CSI Driver is a CSI driver that allows you to mount many secrets, certificates, and keys from external secret stores into Kubernetes pods as volumes. After attaching the volume, the system mounts the secrets into the container file system.

The benefits of using the Secret Store CSI Driver are that you manage the lifecycle of the secrets outside of Kubernetes while still providing a Kubernetes-native experience of using the secrets in your pods.

The Architecture of the Secret Store CSI Driver

The Secret Store CSI Driver is a daemonset that lets all kublets communicate with each other and uses gRPC to talk to a provider. A SecretProviderClass custom resource specifies the definition of the external Secret Store. Then the system mounts a volume in the pod as tmpfs, and it injects the secret into the volume. When you delete the pod, the system cleans up the volume and removes the secret from the tmpfs volume.

How to Use the Secrets Store CSI Driver with Pulumi ESC

Before we start, make sure you have the following prerequisites:

A Pulumi Cloud account. If you don’t have one, you can create one for free.
A Kubernetes cluster (I will be using a local KinD cluster, but you can use any Kubernetes cluster)
Pulumi CLI installed. You can use the pulumi env commands to manage secrets and configurations.
kubectl CLI installed for some debugging

Step 1: Deploy the Secrets Store CSI Driver and Pulumi ESC CSI Provider

We will use Pulumi with the pulumi-kubernetes provider to deploy the Secrets Store CSI Driver and the Pulumi ESC CSI Provider to our Kubernetes cluster.

And here we also use the integration of Pulumi ESC with Pulumi IaC to supply the Pulumi access token in a secure way.

First, we need to create a new Pulumi project:

# Choose your favorite Pulumi supported language
pulumi new kubernetes-<your-programming-language> --name

Before we dig into the code, let’s head to the Pulumi Cloud Console and create a new Pulumi ESC project with the name esc-secrets-store-csi-driver-demo.

And create the environment dev:

In the editor add the following yaml into the Environment definition:

values:
 pulumiConfig:
 pulumi-pat:
 fn::secret: <your-pulumi-pat>

Don’t know how to create a PAT? Check out the official Pulumi documentation.

If you prefer to use the Pulumi CLI, you can create the environment by running:

pulumi env init <your-org>/esc-secrets-store-csi-driver-demo/dev

And set the configuration by running the env edit command and copy the above YAML into the editor:

pulumi env edit <your-org>/esc-secrets-store-csi-driver-demo/dev

Now, we need to link the Pulumi ESC project to the Pulumi IaC project. To do this, we need to add the following to your Pulumi.dev.yaml:

environment:
- esc-secrets-store-csi-driver-demo/dev

import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

const secretsStoreCSIDriver = new k8s.helm.v4.Chart("secrets-store-csi-driver", {
 chart: "secrets-store-csi-driver",
 namespace: "kube-system",
 repositoryOpts: {
 repo: "https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts",
 },
 values: {
 nodeSelector: {
 "kubernetes.io/os": "linux",
 },
 },
});

const secretsStoreCSIPulumiESCProvider = new k8s.helm.v4.Chart(
 "secrets-store-csi-pulumi-esc-provider",
 {
 chart: "oci://ghcr.io/pulumi/helm-charts/pulumi-esc-csi-provider",
 namespace: "kube-system",
 values: {
 nodeSelector: {
 "kubernetes.io/os": "linux",
 },
 },
 },
 { dependsOn: secretsStoreCSIDriver },
);

const config = new pulumi.Config();

const mySecret = new k8s.core.v1.Secret(
 "my-secret",
 {
 metadata: {
 namespace: "default",
 name: "pulumi-access-token",
 },
 stringData: {
 "pulumi-access-token": config.require("pulumi-pat"),
 },
 type: "Opaque",
 },
 { dependsOn: secretsStoreCSIPulumiESCProvider },
);

import pulumi
import pulumi_kubernetes as k8s

secrets_store_csi_driver = k8s.helm.v4.Chart(
 "secrets-store-csi-driver",
 k8s.helm.v4.ChartArgs(
 chart="secrets-store-csi-driver",
 namespace="kube-system",
 repository_opts=k8s.helm.v4.RepositoryOptsArgs(
 repo="https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts",
 ),
 values={
 "nodeSelector": {
 "kubernetes.io/os": "linux",
 },
 },
 ),
)

secrets_store_csi_pulumi_esc_provider = k8s.helm.v4.Chart(
 "secrets-store-csi-pulumi-esc-provider",
 k8s.helm.v4.ChartArgs(
 chart="oci://ghcr.io/pulumi/helm-charts/pulumi-esc-csi-provider",
 namespace="kube-system",
 values={
 "nodeSelector": {
 "kubernetes.io/os": "linux",
 },
 },
 ),
 opts=pulumi.ResourceOptions(depends_on=[secrets_store_csi_driver]),
)

config = pulumi.Config()

my_secret = k8s.core.v1.Secret(
 "my-secret",
 metadata=k8s.meta.v1.ObjectMetaArgs(
 namespace="default", name="pulumi-access-token"
 ),
 string_data={
 "pulumi-access-token": config.require("pulumi-pat"),
 },
 type="Opaque",
 opts=pulumi.ResourceOptions(depends_on=[secrets_store_csi_pulumi_esc_provider]),
)

package main

import (
 k8s "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes"
 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apiextensions"
 appv1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/apps/v1"
 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/core/v1"
 chartv4 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v4"
 metav1 "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/meta/v1"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 secretsStoreCsiDriver, err := chartv4.NewChart(ctx, "secrets-store-csi-driver", &chartv4.ChartArgs{
 Chart: pulumi.String("secrets-store-csi-driver"),
 Namespace: pulumi.String("kube-system"),
 RepositoryOpts: chartv4.RepositoryOptsArgs{
 Repo: pulumi.String("https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts"),
 },
 Values: pulumi.Map{
 "nodeSelector": pulumi.Map{
 "kubernetes.io/os": pulumi.String("linux"),
 },
 },
 })
 if err != nil {
 return err
 }

 secretsStoreCsiPulumiEscProvider, err := chartv4.NewChart(ctx, "secrets-store-csi-pulumi-esc-provider", &chartv4.ChartArgs{
 Chart: pulumi.String("oci://ghcr.io/pulumi/helm-charts/pulumi-esc-csi-provider"),
 Namespace: pulumi.String("kube-system"),
 Values: pulumi.Map{
 "nodeSelector": pulumi.Map{
 "kubernetes.io/os": pulumi.String("linux"),
 },
 },
 }, pulumi.DependsOn([]pulumi.Resource{secretsStoreCsiDriver}))
 if err != nil {
 return err
 }

 pulumiPAT := config.Get(ctx, "pulumi-pat")

 mySecret, err := corev1.NewSecret(ctx, "my-secret", &corev1.SecretArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Namespace: pulumi.String("default"),
 Name: pulumi.String("pulumi-access-token"),
 },
 StringData: pulumi.StringMap{
 "pulumi-access-token": pulumi.String(pulumiPAT),
 },
 Type: pulumi.String("Opaque"),
 }, pulumi.DependsOn([]pulumi.Resource{secretsStoreCsiPulumiEscProvider}))
 if err != nil {
 return err
 }


 return nil
 })
}

using Pulumi;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Core.V1;
using Pulumi.Kubernetes.Helm.V3;
using Pulumi.Kubernetes.Helm;
using Pulumi.Kubernetes.Types.Inputs.Meta.V1;
using Pulumi.Kubernetes.ApiExtensions;
using System.Collections.Generic;



return await Deployment.RunAsync(() =>
{
 var secretsStoreCsiDriver = new Release("secrets-store-csi-driver", new()
 {
 Chart = "secrets-store-csi-driver",
 Namespace = "kube-system",
 RepositoryOpts = new Pulumi.Kubernetes.Types.Inputs.Helm.V3.RepositoryOptsArgs
 {
 Repo = "https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts",
 },
 Values = new Dictionary<string, object>
 {
 { "nodeSelector", new Dictionary<string, object>
 {
 { "kubernetes.io/os", "linux" },
 } },
 },
 });

 var secretsStoreCsiPulumiEscProvider = new Release("secrets-store-csi-pulumi-esc-provider", new()
 {
 Chart = "oci://ghcr.io/pulumi/helm-charts/pulumi-esc-csi-provider",
 Namespace = "kube-system",
 Values = new Dictionary<string, object>
 {
 { "nodeSelector", new Dictionary<string, object>
 {
 { "kubernetes.io/os", "linux" },
 } },
 },
 }, new CustomResourceOptions { DependsOn = { secretsStoreCsiDriver } });

 var config = new Config();
 var pulumiPAT = config.Require("pulumi-pat");

 var mySecret = new Secret("my-secret", new SecretArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Namespace = "default",
 Name = "pulumi-access-token",
 },
 StringData =
 {
 { "pulumi-access-token", pulumiPAT }
 },
 Type = "Opaque",
 }, new CustomResourceOptions { DependsOn = { secretsStoreCsiPulumiEscProvider } });

});


class SecretProviderClassArgs : CustomResourceArgs
{
 public SecretProviderClassArgs(): base("secrets-store.csi.x-k8s.io/v1", "SecretProviderClass")
 {
 }

 [Input("spec")]
 public Input<SecretProviderClassSpecArgs>? Spec { get; set; }
}


class SecretProviderClassSpecArgs : ResourceArgs
{
 [Input("provider")]
 public Input<string>? Provider { get; set; }

 [Input("parameters")]
 public Input<InputMap<object>>? Parameters { get; set; }
}

class SecretProviderParametersArgs : ResourceArgs
{
 [Input("apiUrl")]
 public Input<string>? ApiUrl { get; set; }

 [Input("organization")]
 public Input<string>? Organization { get; set; }

 [Input("project")]
 public Input<string>? Project { get; set; }

 [Input("environment")]
 public Input<string>? Environment { get; set; }

 [Input("authSecretName")]
 public Input<string>? AuthSecretName { get; set; }

 [Input("authSecretNamespace")]
 public Input<string>? AuthSecretNamespace { get; set; }

 [Input("secrets")]
 public Input<string>? Secrets { get; set; }
}

Deploy the stack by running:

pulumi up

And you should see that the secret was created in the Kubernetes cluster and the ESO instance was deployed successfully.

kubectl get secret pulumi-access-token -o jsonpath='{.data.PULUMI_ACCESS_TOKEN}' | base64 -d

Step 2: Create a SecretProviderClass

Now, we will create a secret in the Pulumi ESC project and synchronize it into the Kubernetes cluster by creating an SecretProviderClass:

Create a new ESC environment called csi-secrets-store-app in the esc-secrets-store-csi-driver-demo project:

values:
 app:
 hello: world
 hello-secret:
 fn::secret: world

If you prefer to use the Pulumi CLI, you can create the environment by running:

pulumi env init <your-org>/esc-secrets-store-csi-driver-demo/csi-secrets-store-app

And set the configuration by running the env edit command and copy the above YAML into the editor:

pulumi env edit <your-org>/esc-secrets-store-csi-driver-demo/csi-secrets-store-app

Either way, you should see following environment configuration in the Pulumi Cloud Console:

We can now create the SecretProviderClass in the Kubernetes cluster:

const secretProviderClass = new k8s.apiextensions.CustomResource(
 "example-provider-pulumi-esc",
 {
 apiVersion: "secrets-store.csi.x-k8s.io/v1",
 kind: "SecretProviderClass",
 metadata: {
 name: "example-provider-pulumi-esc",
 namespace: "default",
 },
 spec: {
 provider: "pulumi",
 parameters: {
 apiUrl: "https://api.pulumi.com/api/esc",
 organization: "dirien",
 project: "esc-secrets-store-csi-driver-demo",
 environment: "csi-secrets-store-app",
 authSecretName: mySecret.metadata.name,
 authSecretNamespace: mySecret.metadata.namespace,
 secrets: `- secretPath: "/"
 fileName: "hello"
 secretKey: "app.hello"
`,
 },
 },
 },
 { dependsOn: secretsStoreCSIPulumiESCProvider },
);

secret_provider_class = k8s.apiextensions.CustomResource(
 "example-provider-pulumi-esc",
 api_version="secrets-store.csi.x-k8s.io/v1",
 kind="SecretProviderClass",
 metadata=k8s.meta.v1.ObjectMetaArgs(
 name="example-provider-pulumi-esc", namespace="default"
 ),
 spec={
 "provider": "pulumi",
 "parameters": {
 "apiUrl": "https://api.pulumi.com/api/esc",
 "organization": "dirien",
 "project": "esc-secrets-store-csi-driver-demo",
 "environment": "csi-secrets-store-app",
 "authSecretName": my_secret.metadata["name"],
 "authSecretNamespace": my_secret.metadata["namespace"],
 "secrets": '- secretPath: "/"\n fileName: "hello"\n secretKey: "app.hello"\n',
 },
 },
 opts=pulumi.ResourceOptions(depends_on=[secrets_store_csi_pulumi_esc_provider]),
)

 secretProviderClass, err := apiextensions.NewCustomResource(ctx, "example-provider-pulumi-esc", &apiextensions.CustomResourceArgs{
 ApiVersion: pulumi.String("secrets-store.csi.x-k8s.io/v1"),
 Kind: pulumi.String("SecretProviderClass"),
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("example-provider-pulumi-esc"),
 Namespace: pulumi.String("default"),
 },
 OtherFields: k8s.UntypedArgs{
 "provider": pulumi.String("pulumi"),
 "parameters": pulumi.Map{
 "apiUrl": pulumi.String("https://api.pulumi.com/api/esc"),
 "organization": pulumi.String("dirien"),
 "project": pulumi.String("esc-secrets-store-csi-driver-demo"),
 "environment": pulumi.String("csi-secrets-store-app"),
 "authSecretName": mySecret.Metadata.Name().Elem(),
 "authSecretNamespace": mySecret.Metadata.Namespace().Elem(),
 "secrets": pulumi.String(`- secretPath: "/"
 fileName: "hello"
 secretKey: "app.hello"
`),
 },
 },
 }, pulumi.DependsOn([]pulumi.Resource{secretsStoreCsiPulumiEscProvider}))
 if err != nil {
 return err
 }

 var secretProviderClass = new Pulumi.Kubernetes.ApiExtensions.CustomResource("example-provider-pulumi-esc", new SecretProviderClassArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "example-provider-pulumi-esc",
 Namespace = "default",
 },
 Spec = new SecretProviderClassSpecArgs
 {
 Provider = "pulumi",
 Parameters = new InputMap<object>
 {
 { "apiUrl", "https://api.pulumi.com/api/esc" },
 { "organization", "dirien" },
 { "project", "esc-secrets-store-csi-driver-demo" },
 { "environment", "csi-secrets-store-app" },
 { "authSecretName", mySecret.Metadata.Apply(metadata => metadata.Name) },
 { "authSecretNamespace", mySecret.Metadata.Apply(metadata => metadata.Namespace) },
 { "secrets", "- secretPath: \"/\"\n fileName: \"hello\"\n secretKey: \"app.hello\"\n" }
 },
 },
 }, new CustomResourceOptions { DependsOn = { secretsStoreCsiPulumiEscProvider } });

We can check that the secret was successfully synchronized by running:

kubectl get secretproviderclasses example-provider-pulumi-esc

You might also like:

Step 3: Deploy an Application and Mount the Secret

Now, we can deploy an application that references the secret from the Kubernetes cluster. I am going to use busybox that reads mounted file in.

const deployment = new k8s.apps.v1.Deployment("example-provider-pulumi-esc", {
 metadata: {
 name: "example-provider-pulumi-esc",
 namespace: "default",
 labels: {
 app: "example-provider-pulumi-esc",
 },
 },
 spec: {
 replicas: 1,
 selector: {
 matchLabels: {
 app: "example-provider-pulumi-esc",
 },
 },
 template: {
 metadata: {
 labels: {
 app: "example-provider-pulumi-esc",
 },
 },
 spec: {
 containers: [
 {
 name: "client",
 image: "busybox:latest",
 command: ["sh", "-c"],
 args: [
 `set -eux
 ls /run/secrets
 find /run/secrets/ -mindepth 1 -maxdepth 1 -not -name '.*' | xargs -t -I {} sh -c 'echo "$(cat "{}")"'
 tail -f /dev/null`,
 ],
 volumeMounts: [
 {
 name: "data",
 mountPath: "/run/secrets",
 },
 ],
 },
 ],
 volumes: [
 {
 name: "data",
 csi: {
 driver: "secrets-store.csi.k8s.io",
 readOnly: true,
 volumeAttributes: {
 secretProviderClass: secretProviderClass.metadata.name,
 },
 },
 },
 ],
 },
 },
 },
});

export const deploymentName = deployment.metadata.name;

deployment = k8s.apps.v1.Deployment(
 "example-provider-pulumi-esc",
 metadata=k8s.meta.v1.ObjectMetaArgs(
 namespace="default",
 name="example-provider-pulumi-esc",
 labels={
 "app": "example-provider-pulumi-esc",
 },
 ),
 spec=k8s.apps.v1.DeploymentSpecArgs(
 replicas=1,
 selector=k8s.meta.v1.LabelSelectorArgs(
 match_labels={
 "app": "example-provider-pulumi-esc",
 },
 ),
 template=k8s.core.v1.PodTemplateSpecArgs(
 metadata=k8s.meta.v1.ObjectMetaArgs(
 labels={
 "app": "example-provider-pulumi-esc",
 },
 ),
 spec=k8s.core.v1.PodSpecArgs(
 containers=[
 k8s.core.v1.ContainerArgs(
 name="client",
 image="busybox:latest",
 command=["sh", "-c"],
 args=[
 "set -eux\nls /run/secrets\nfind /run/secrets/ -mindepth 1 -maxdepth 1 -not -name '.*' | xargs -t -I {} sh -c 'echo \"$(cat \"{}\")\"'\ntail -f /dev/null",
 ],
 volume_mounts=[
 k8s.core.v1.VolumeMountArgs(
 name="data",
 mount_path="/run/secrets",
 ),
 ],
 ),
 ],
 volumes=[
 k8s.core.v1.VolumeArgs(
 name="data",
 csi=k8s.core.v1.CSIVolumeSourceArgs(
 driver="secrets-store.csi.k8s.io",
 read_only=True,
 volume_attributes={
 "secretProviderClass": secret_provider_class.metadata[
 "name"
 ],
 },
 ),
 ),
 ],
 ),
 ),
 ),
)

pulumi.export("deploymentName", deployment.metadata["name"])

 deployment, err := appv1.NewDeployment(ctx, "example-provider-pulumi-esc", &appv1.DeploymentArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Name: pulumi.String("example-provider-pulumi-esc"),
 Namespace: pulumi.String("default"),
 Labels: pulumi.StringMap{
 "app": pulumi.String("example-provider-pulumi-esc"),
 },
 },
 Spec: &appv1.DeploymentSpecArgs{
 Replicas: pulumi.Int(1),
 Selector: &metav1.LabelSelectorArgs{
 MatchLabels: pulumi.StringMap{
 "app": pulumi.String("example-provider-pulumi-esc"),
 },
 },
 Template: &corev1.PodTemplateSpecArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Labels: pulumi.StringMap{
 "app": pulumi.String("example-provider-pulumi-esc"),
 },
 },
 Spec: &corev1.PodSpecArgs{
 Containers: corev1.ContainerArray{
 &corev1.ContainerArgs{
 Name: pulumi.String("client"),
 Image: pulumi.String("busybox:latest"),
 Command: pulumi.StringArray{
 pulumi.String("sh"),
 pulumi.String("-c"),
 },
 Args: pulumi.StringArray{
 pulumi.String(`set -eux
 ls /run/secrets
 find /run/secrets/ -mindepth 1 -maxdepth 1 -not -name '.*' | xargs -t -I {} sh -c 'echo "$(cat "{}")"'
 tail -f /dev/null`),
 },
 VolumeMounts: &corev1.VolumeMountArray{
 &corev1.VolumeMountArgs{
 Name: pulumi.String("data"),
 MountPath: pulumi.String("/run/secrets"),
 },
 },
 },
 },
 Volumes: &corev1.VolumeArray{
 &corev1.VolumeArgs{
 Name: pulumi.String("data"),
 Csi: corev1.CSIVolumeSourceArgs{
 Driver: pulumi.String("secrets-store.csi.k8s.io"),
 ReadOnly: pulumi.Bool(true),
 VolumeAttributes: pulumi.StringMap{
 "secretProviderClass": secretProviderClass.Metadata.Name().Elem(),
 },
 },
 },
 },
 },
 },
 },
 }, pulumi.DependsOn([]pulumi.Resource{secretProviderClass}))
 if err != nil {
 return err
 }

 var deployment = new Pulumi.Kubernetes.Apps.V1.Deployment("example-provider-pulumi-esc", new Pulumi.Kubernetes.Types.Inputs.Apps.V1.DeploymentArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Name = "example-provider-pulumi-esc",
 Namespace = "default",
 Labels =
 {
 { "app", "example-provider-pulumi-esc" },
 },
 },
 Spec = new Pulumi.Kubernetes.Types.Inputs.Apps.V1.DeploymentSpecArgs
 {
 Replicas = 1,
 Selector = new Pulumi.Kubernetes.Types.Inputs.Meta.V1.LabelSelectorArgs
 {
 MatchLabels =
 {
 { "app", "example-provider-pulumi-esc" },
 },
 },
 Template = new Pulumi.Kubernetes.Types.Inputs.Core.V1.PodTemplateSpecArgs
 {
 Metadata = new ObjectMetaArgs
 {
 Labels =
 {
 { "app", "example-provider-pulumi-esc" },
 },
 },
 Spec = new Pulumi.Kubernetes.Types.Inputs.Core.V1.PodSpecArgs
 {
 Containers =
 {
 new Pulumi.Kubernetes.Types.Inputs.Core.V1.ContainerArgs
 {
 Name = "client",
 Image = "busybox:latest",
 Command =
 {
 "sh",
 "-c",
 },
 Args =
 {
 "set -eux\nls /run/secrets\nfind /run/secrets/ -mindepth 1 -maxdepth 1 -not -name '.*' | xargs -t -I {} sh -c 'echo \"$(cat \"{}\")\"'\ntail -f /dev/null",
 },
 VolumeMounts =
 {
 new Pulumi.Kubernetes.Types.Inputs.Core.V1.VolumeMountArgs
 {
 Name = "data",
 MountPath = "/run/secrets",
 },
 },
 },
 },
 Volumes =
 {
 new Pulumi.Kubernetes.Types.Inputs.Core.V1.VolumeArgs
 {
 Name = "data",
 Csi = new Pulumi.Kubernetes.Types.Inputs.Core.V1.CSIVolumeSourceArgs
 {
 Driver = "secrets-store.csi.k8s.io",
 ReadOnly = true,
 VolumeAttributes =
 {
 { "secretProviderClass", secretProviderClass.Metadata.Apply(metadata => metadata.Name) },
 },
 },
 },
 },
 },
 },
 },
 }, new CustomResourceOptions { DependsOn = { secretProviderClass } });

After deploying the stack, you can get the logs of the busybox pod to see that the secret was successfully mounted:

NAME=$(kubectl get pods -o name | grep example-provider-pulumi-esc | cut -d'/' -f2)
kubectl logs $NAME

You should see the following output:

+ ls /run/secrets
hello
+ find /run/secrets/ -mindepth 1 -maxdepth 1 -not -name '.*'
+ xargs -t -I '{}' sh -c 'echo "$(cat "{}")"'
sh -c echo "$(cat "/run/secrets/hello")"
world
+ tail -f /dev/null

Or you can exec into the pod and check the content of the mounted secret:

kubectl exec -it $NAME -- cat /run/secrets/hello

You should see the following output:

world

Step 4: Clean Up

After you are done with the demo, you can clean up the resources by running:

pulumi destroy

Conclusion

The Secret Store CSI Driver is a great option for managing secrets in a cloud-native way when the use of Kubernetes secrets is not an option due to enhanced security requirements.

Below is a quick comparison of the External Secrets Operator and the Secrets Store CSI Driver to help you decide which one is the best fit for your use case. As always, the best way to find out is to try both solutions and see which one fits your requirements best.

The good part is, whatever you choose, you can use Pulumi ESC to manage your secrets and avoid any secret sprawl in your organization as both solutions are supported by Pulumi ESC.

Comparison of the External Secrets Operator and the Secrets Store CSI Driver

Feature/Aspect	External Secrets Operator	CSI Secrets Driver
Primary Use Case	Synchronizing external secrets into Kubernetes as native secrets.	Mounting secrets directly to pods as files or environment variables.
Integration with External Secret Stores	Supports multiple external secret stores like AWS Secrets Manager, Google Secret Manager, Vault, Azure Key Vault, etc.	Primarily supports integrations defined by the CSI specification (e.g., Vault, AWS, Azure Key Vault, Pulumi ESC).
Mechanism for Secrets Delivery	Secrets are pulled and stored as Kubernetes `Secret` resources.	Secrets are mounted directly into pods as files or injected as environment variables.
Kubernetes Resource Requirements	Requires a custom Kubernetes resource (`ExternalSecret`) and the External Secrets Operator.	Relies on the Kubernetes CSI (Container Storage Interface) standard and requires a specific CSI driver.
Secret Rotation	Supports automatic rotation by polling the external secret store at defined intervals.	Supports rotation, but the application needs to handle reloading mounted secrets.
Security Considerations	Secrets are stored temporarily in Kubernetes as native secrets, which may pose a risk if not properly managed.	Secrets are mounted directly and not stored as native Kubernetes secrets, reducing exposure but relying on file permissions.
Customization and Features	Highly customizable with fine-grained mappings and transformation options.	Limited customization, focused on mounting secrets as-is.
Application Compatibility	Applications access secrets as Kubernetes secrets (e.g., via env variables or volumes).	Applications access secrets directly via mounted files or injected env variables.
Performance Considerations	Potential slight delay due to syncing secrets to Kubernetes secrets.	Faster access as secrets are directly mounted.
Community and Ecosystem	Supported by a growing community; integrates well with diverse secret management solutions.	Part of the Kubernetes ecosystem; supports CSI-compliant secret storage solutions.
Best Use Cases	Ideal for scenarios where secrets need to be accessed as Kubernetes native secrets.	Best for applications requiring direct access to secrets without intermediate storage in Kubernetes secrets.

You can find detailed information about all current available Pulumi ESC Kubernetes integrations in the Pulumi ESC documentation.

Let us know what you think about the Secret Store CSI Driver and how you are managing secrets in your Kubernetes clusters. We would love to hear your feedback and experiences.

Try Pulumi for Free

Announcing AWS Systems Manager - Parameter Store Support for Pulumi ESC

Sean Yeh — Mon, 16 Dec 2024 12:00:00 -0600

We are super excited to announce integration support for AWS Systems Manager - Parameter Store within Pulumi Environments, Secrets, and Configuration (ESC). Parameter Store is a popular managed service by AWS for storing and managing secrets and other configuration, and its integration with ESC has been highly requested among the community.

With the AWS Parameter Store ESC Provider, development teams can now import their AWS Parameter Store parameters as environment variables or as Pulumi Config in their workflows, all in a secure and convenient way.

As we continue to expand our roster of integrations, it’s easier now than ever to manage and use secrets and configuration all in one place by using ESC. If you or your team are users of AWS Parameter Store, say goodbye to managing multiple configuration sources and give this provider a try!

How does it work?

Add parameters to AWS Parameter Store.
Use aws-login to authenticate with AWS.
Define a path name, and enter the parameter name you want to retrieve. This will be imported into the path name that you have defined.

AWS Parameter Store provider syntax:

values:
 params:
 fn::open::aws-parameter-store:
 region: us-west-1
 login: ${aws.login}
 get:
 myKey:
 name: /myNamespace/myKey
 myKeyByVersion:
 name: /myNamespace/myKey:1
 myKeyByVersionLabel:
 name: /myNamespace/myKey:stable
 secureKey:
 name: /myNamespace/secureKey
 decrypt: true

Demo

Now that we know how to use the Pulumi ESC Parameter Store provider, let’s use it to pull some parameters!

Setup OpenID Connect for AWS. We will use OIDC to authenticate with AWS.
Store some parameters in Parameter Store. In the demo, we will store a String /test/api-endpoint and a SecureString /test/api-key
Create a new Pulumi ESC Environment with the following definition. Make sure to replace the OIDC roleArn with your own.

values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: arn:aws:iam::123456789:role/esc-oidc
 sessionName: pulumi-environments-session
 params:
 fn::open::aws-parameter-store:
 region: us-west-1
 login: ${aws.login}
 get:
 api-endpoint:
 name: /test/api-endpoint
 api-key:
 name: /test/api-key
 decrypt: true
 environmentVariables:
 API_ENDPOINT: ${params.api-endpoint}
 API_KEY: ${params.api-key}

Open the environment to ensure we are able to successfully pull the credentials from AWS Parameter Store
Run pulumi env open <project/environment> --format shell to view the exported environment variables from this ESC environment.
Use pulumi env run to run any command with these environment variables. For example, we can now run pulumi env run <project/environment> -- <your command>

pulumi env run passes the configuration stored under the environmentVariables section for use with the provided command, without ever storing them locally on your machine.

Conclusion

We are excited to expand our roster of integrations with the new AWS Parameter Store ESC Provider, providing developers more flexibility and choices. We look forward to seeing what you will create next using Pulumi ESC!

Visit the AWS Parameter Store Provider Page for more detailed documentation on this provider.
Visit our Pulumi ESC docs to learn more about Pulumi ESC and its supported integrations

As always, we deeply value your insights. Your feedback is instrumental in helping us refine and enhance our solutions to better align with your needs.

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.

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 🙂

Announcing the General Availability of Pulumi ESC - Welcome to a New Era of Secrets Management

Arun Loganathan — Wed, 18 Sep 2024 08:59:00 +0000

At Pulumi, we’ve been at the forefront of revolutionizing infrastructure management and DevOps processes. We’ve built the industry’s most comprehensive secrets management solution for IaC, securing production cloud credentials and secrets for countless organizations. Now, we’re taking that expertise and applying it to the broader challenges of managing secrets at scale with an open ecosystem approach.

Pulumi Environments, Secrets, and Configuration (Pulumi ESC), launched in preview in October 2023, is now generally available.

This next-generation secrets management and orchestration service is built with a robust software engineering approach, designed to bring security and simplicity to even the most complex secrets management needs.

Challenges in Secrets Management

In today’s cloud-native world, secrets are the keys to the cloud estate, but managing them effectively is a growing challenge. Modern applications rely on a complex web of secrets, but traditional approaches to secrets management are struggling to keep pace. This complexity creates major challenges for security and engineering teams:

Secrets Sprawl: Secrets scattered across numerous systems and platforms make it nearly impossible to track their usage, enforce consistent security policies, and prevent unauthorized access, significantly increasing the likelihood of a breach.
Long-Lived Credentials: Storing long-lived credentials, especially locally, creates a significant security liability. If these credentials are compromised, they can grant attackers prolonged access to sensitive systems.
The Trade-off Between Speed and Security: Many security measures designed to safeguard secrets can inadvertently impede development velocity. Complex storage and retrieval processes create unnecessary friction, leading to frustration and delays.
Insecure .env File Sharing: Developers often copy/paste secrets across many different files, including formats like .env files stored locally on their machine or shared through insecure channels (like Slack), creating blind spots for security teams and increasing the risk of data leaks.

Introducing Pulumi ESC: A Modern Approach to Environments, Secrets, and Configuration

Pulumi ESC is the modern secret management platform designed to streamline and secure how you manage environments, secrets, and configuration across your entire organization. Built with flexibility and security at its core, Pulumi ESC empowers you to:

Centralize and Simplify Secrets Management:

Unify Your Secrets: Say goodbye to secrets scattered across systems. Pulumi ESC lets you pull and synchronize secrets from any source—HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, 1Password, and more—and consume them securely from anywhere.
Streamline Access and Control: Access secrets seamlessly via CLI, API, Kubernetes operator, the intuitive Pulumi Cloud UI, or directly within your code using our TypeScript, Python, and Go SDKs. Robust RBAC ensures the right people have the right access at all times.
Eliminate .env File Risks: Stop sharing secrets through insecure channels. Pulumi ESC provides a secure and centralized way to manage and access secrets, eliminating the need for risky .env files.

Boost Developer Velocity and Security:

Empower Developers, Not Slow Them Down: Pulumi ESC is designed for developer convenience without compromising security. Access secrets programmatically, integrate with your existing workflows, and leverage flexible authoring options: Pulumi Cloud Editor, VS Code Plugin, SDKs, the Pulumi Service Provider, and our REST API - the choice is yours!
Gain Complete Visibility and Control: Track all secret access and changes with detailed audit logs. Understand the downstream impact of changes and ensure your secrets are used securely and consistently across your organization.
Secrets as Code: Pulumi ESC supports flexible composition of environments by allowing imports between one another. Construct hierarchical environments that avoid the need to copy/paste secrets and configurations, ensuring that changes are consistently propagated across all related environments.

Built for the Modern Cloud, Open by Design:

Use It Your Way: Pulumi ESC integrates seamlessly with other Pulumi products and features such as Pulumi IaC and Pulumi Deployments for a unified infrastructure management experience. But its flexibility extends to any platform or toolset, including HashiCorp Terraform.
Embrace the Open Ecosystem: We believe in freedom of choice. That’s why Pulumi ESC is built on an open-source foundation (Apache 2.0 license) and designed to retrieve and synchronize secrets with various platforms seamlessly. We empower our customers to choose the best tools for their needs and supercharge their workflows with Pulumi ESC.

Customer Stories

Since launch, we’ve seen an exponential increase in our customers using Pulumi ESC. Our users have reduced the duplication of their configuration and secrets by over 90% and made Pulumi ESC a core part of running and managing their mission-critical infrastructure and applications.

Hear from our customers directly what they had to say about Pulumi ESC:

“With Pulumi ESC, our developers get dynamic AWS and Azure credentials on-demand, that removes the need for long-lived tokens and enhances security. Onboarding new developers is quick and secure, with no more manually filling in .env templates, since a common ESC dev environment with RBAC is all we need. The integration with the Pulumi SDKs is a huge productivity boost, and allows us to integrate secrets seamlessly across all of our development workflows." states Liam White, Platform Lead at Tetrate.”
“Pulumi ESC has been a lifesaver for us”; said JK Jensen, Team Lead at Mysten Labs, “it’s nice to throw everything behind an ESC environment and eliminate one-off granting IAM permissions and other issues related to static credentials. It gives us peace of mind knowing that we can grant permissions quickly and revoke easily, limiting the blast radius for any access.”

“With Pulumi ESC, our developers get dynamic AWS/GCP credentials on-demand; that removes the need for long-lived tokens and enhances security. ESC allows for Pulumi programs to share secure credentials and access secrets in their given cloud environments. ESC is a great configuration ‘/and secrets management sharing tool to allow for a DRY (Don’t Repeat Yourself) approach to development,” says Richard Genthner, Lead DevOps Engineer at Boost Insurance.

Watch the snippet from our PulumiUP Keynote that walks you through how to achieve all these benefits our customers have experienced. Sign-up here to watch the full keynote.

Beyond Preview: The Evolution of Pulumi ESC

Since the launch of Pulumi ESC in preview, over the last 11 months, we have launched numerous features and enhancements driven by our customers. Some of the major ones include:

SDKs for TypeScript, Python, and Go to leverage Pulumi ESC within all your applications
Versioning that maintains full history of the changes you have made to your secrets and configuration and rollback to specific versions when needed
Version Tags allow you to assign tags and import specific versions by tags within your applications such that moving tags across versions changes the configuration but requires zero changes in your application code
Syncing your secrets to several external sources including GitHub and AWS SecretsManager
Kubernetes secrets operator to use Pulumi ESC within your Kubernetes applications to retrieve secrets and configuration using external secrets operator during runtime
VS Code Extension to author and view your environments directly from where you code
Webhooks to trigger your automated CI/CD workflows, restart applications with the latest secrets and configuration, notify your teams
Pulumi OIDC Trust relationship to get Pulumi short-term credentials using your existing Identity provider
Projects and Environment Tags to help you organize your Pulumi ESC environments and allow them to scale as your organization evolves
1Password integration to pull secrets stored in 1Password during runtime
In-built Document Editor Enhancements to ease authoring with Pulumi Cloud
Table Editor to support users who prefer point-and-click UI-driven method to secrets management
Pulumi Stack reference provider offering tighter integration with Pulumi IaC
Files support that allows getting Kubernetes credentials dynamically
Audit logs to monitor your environments

Pricing

Starting October 1st, 2024, Pulumi ESC will be billed per secret. We have heard from customers that this is a familiar pricing dimension that aligns to the value customers get out of ESC. To help you get started, we have included a generous free tier of secrets and API calls.

	Free	Team	Enterprise	Business Critical
Price per secret/month	25 free	$0.50	$0.75 / Custom	Custom
Price per plaintext config	Free	Free	Free	Free
Price per 10K API calls	10K free	$0.10	$0.10	$0.10
Commitment discounts			✔	✔

Check out our pricing page for more information about the various packages available. Contact us if you are interested in a demo, have any questions, or would like to discuss volume discounts.

Conclusion

Pulumi ESC represents a significant advancement in secrets and config management. By addressing the challenges faced by organizations today, such as secrets sprawl and the trade-off between speed and security, Pulumi ESC offers a modern, flexible solution. Its unique features, including support for dynamic, short-lived credentials and seamless integration with major cloud providers, GitHub, etc. make it an invaluable asset for teams looking to maintain agility without compromising on security. Pulumi ESC is set to redefine the standards of secrets management, enabling organizations to achieve their security and operational goals more effectively.

We can’t wait to see how you leverage Pulumi ESC. Sign-up for Pulumi Cloud to start using Pulumi ESC and check out our getting started guide to learn more about Pulumi ESC.

Pushing Pulumi ESC Secrets into External Platforms

Komal Ali — Tue, 17 Sep 2024 00:00:00 -0300

This content now lives in the Pulumi docs. See Sync secrets to external platforms for the maintained version.

Managing secrets across multi-cloud infrastructures has long been a challenge for developers and operations teams. This article explores Pulumi IaC-based strategy to centrally define secrets and configuration in Pulumi ESC and automatically sync these values across the external platforms where they will be utilized, effectively reducing secret sprawl and manual overhead.

The Secret Management Conundrum

Traditional secret management often leads to a phenomenon known as secret sprawl. This occurs when secrets are duplicated across multiple systems, including various repositories, cloud providers, and CI/CD pipelines. The result is a tangled web of inconsistencies that makes tracking and managing secrets a Herculean task.

Updating secrets manually across all these systems is not only tedious but also error-prone. Each time a secret changes, it needs to be updated in every repository, cloud platform, and CI/CD tool where it’s used. This process is time-consuming and frustrating, often leading to mistakes that can compromise security.

Moreover, the lack of a centralized system makes it difficult to track where secrets are stored and who has access to them. This complicates security audits and compliance efforts. When a secret is compromised, the process of revoking and rotating it across multiple systems can be slow and disruptive, potentially leading to application downtime.

ESC Sync with Infrastructure as Code

Using Pulumi building blocks like ESC and IaC, we can create a pattern where secrets and configuration can be centrally defined in ESC, and then automatically synced across the external platforms where they will be utilized.

Consider the following ESC environment, which imports an environment “my-project/my-imported-env” and defines a set of secrets and configuration values to be synced:

imports:
 - my-project/my-imported-env@stable
values:
 sync:
 awsSecretsManager:
 value:
 myConfigKey: ${my-imported-env-foo}
 myNestedKey:
 haha: ${my-imported-env-bar}
 mySecret: ${my-imported-env-password}
 name: name-in-secrets-manager

The sync block defines the secrets and configuration values to be synced. In this example, we are syncing values to AWS Secrets Manager. The value field contains the actual values to be synced, while the name field specifies the name of the secret in AWS Secrets Manager.

To automate the synchronization process, we define a Pulumi program that creates a Pulumi ESC environment, Pulumi IaC stack, and Pulumi deployment settings for the target stack. We then define a set of pre-run commands that extract the values from the environment and set them as configuration values in the target stack. The syncCronSchedule variable specifies how often the synchronization process should run.

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

const config = new pulumi.Config();
const orgName = pulumi.getOrganization();

// projectName is the name of the project where the target stack is located
const projectName = config.require("projectName");

// stackName is the name of the target stack
const stackName = config.get("stackName") || "dev";

// repository is the GitHub repository where the target stack is located (for deployment settings)
const repository = config.require("repository");

// how often you want to sync. Default is hourly
const syncCronSchedule = config.get("syncCronSchedule") || "0 * * * *"

// envPath is the path to the environment file that contains the secrets or configuration to be synced
const envPath = config.get("envPath") || "syncEnv.yaml";

const env = new service.Environment("env", {
 organization: orgName,
 project: projectName,
 name: stackName,
 yaml: new pulumi.asset.FileAsset(envPath)
});

const stack = new service.Stack("esc-sync-aws-secretsmanager", {
 organizationName: orgName,
 projectName,
 stackName,
})

const fullyQualifiedStackName = pulumi.interpolate`${orgName}/${projectName}/${stackName}`;
const fullyQualifiedEnvName = pulumi.interpolate`${orgName}/${projectName}/${env.name}`;

const settings = new service.DeploymentSettings("deployment_settings", {
 organization: orgName,
 project: stack.projectName,
 stack: stack.stackName,
 github: {
 repository,
 },
 sourceContext: {
 git: {
 branch: "main",
 repoDir: "sync/target",
 }
 },
 operationContext: {
 preRunCommands: [
 'pulumi login',
 pulumi.interpolate`pulumi config env add ${projectName}/${env.name} -s ${fullyQualifiedStackName} --yes`,
 pulumi.interpolate`pulumi env open ${fullyQualifiedEnvName} sync.awsSecretsManager.value > sync.json`,
 pulumi.interpolate`pulumi config set -s ${fullyQualifiedStackName} secretName $(pulumi env open ${fullyQualifiedEnvName} sync.awsSecretsManager.name)`,
 ]
 }
});

const schedule = new service.DeploymentSchedule("update_schedule", {
 organization: orgName,
 project: settings.project,
 stack: settings.stack,
 scheduleCron: syncCronSchedule,
 pulumiOperation: "update",
})

Finally, we define a Pulumi program that creates the AWS Secrets Manager secret and secret version based on the values extracted from the environment file. The sync.json file contains the values to be synced, which are read and set as the secret string in the secret version. This Pulumi program is executed on a schedule to ensure that the secrets and configuration values are up-to-date between Pulumi ESC and AWS Secrets Manager.

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as fs from "fs";

const config = new pulumi.Config();
const name = config.require("secretName");

// Read a json file from the local filesystem using node.js fs module
const json = fs.readFileSync("sync.json", "utf8");

const secret = new aws.secretsmanager.Secret(name, {
 recoveryWindowInDays: 0,
})

const secretVersion = new aws.secretsmanager.SecretVersion(`${name}-version`, {
 secretId: secret.id,
 secretString: json,
})

// Export the name of the secret
export const secretName = secret.name;

This pattern allows you to define secrets and configuration values in a single location and automatically sync them across external platforms. The same pattern can be extended to create secrets in other platforms like Azure Key Vault, GCP Secrets Manager, GitHub Secrets, HashiCorp Vault and countless others.

Webhooks: An Event-Driven Alternative Approach

In addition to the scheduled synchronization approach, Pulumi ESC also supports webhooks. Webhooks allow you to respond to events in real-time, such as when a secret is updated in ESC, and take immediate action to sync the new value to an external platform.

In the example below, instead of a scheduled deployment, we define a webhook that triggers when the Pulumi ESC environment is updated. This ensures that the secrets and configuration values are always in sync between Pulumi ESC and the external platform.

const webhook = new service.Webhook("webhook", {
 organizationName: orgName,
 projectName: settings.project,
 stackName: settings.stack,
 displayName: "Sync to AWS Secrets Manager",
 environmentName: pulumi.interpolate`${env.project}/${env.name}`,
 filters: [WebhookFilters.ImportedEnvironmentChanged],
 format: WebhookFormat.PulumiDeployments,
 payloadUrl: pulumi.interpolate`${stack.projectName}/${stack.stackName}`,
 active: true,
})

When the webhook is triggered (i.e. the “my-project/my-imported-env” environment is updated), a deployment is automatically triggered, and the secrets and configuration values are synced to AWS Secrets Manager.

Embracing a New Era of Secret Management

Using Pulumi IaC to synchronize secrets and configuration across platform boundaries represents a giant step forward in secret management. By centralizing and automating the handling of sensitive data, it addresses the key challenges of traditional approaches. Secret sprawl becomes a thing of the past, and the risks associated with manual updates are significantly reduced.

Whether you’re working with AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, GitHub Secrets or other platforms, Pulumi ESC provides a streamlined solution that ensures your secrets are always secure and up-to-date. It offers the convenience and security of a single source of truth for all your secrets, allowing you to focus on building and improving your applications rather than wrestling with secret management.

We encourage you to explore Pulumi’s documentation and dive into the Pulumi ESC Sync Examples repository to see how you can implement this powerful tool in your own projects. Join our vibrant community on Slack to discuss your experiences, ask questions, and share insights. Together, we can make secret management simpler, more secure, and more efficient.

Introducing Webhooks for Pulumi ESC

Iaroslav Titov — Fri, 13 Sep 2024 00:00:00 -0300

Managing secrets and configurations across multiple environments and teams can be a complex juggling act for development teams. Pulumi ESC, our developer-friendly secrets management product, simplifies this process and accelerates your development cycle. Today, we’re excited to make this process even easier with the launch of Webhooks for Pulumi ESC, a powerful new feature that allows you to send a custom trigger to any URL endpoint, enabling you to automate workflows and keep your infrastructure and applications up to date. Pulumi ESC Webhooks also integrates seamlessly with popular communication platforms like Slack and Microsoft Teams.

With Pulumi ESC Webhooks, you can now receive real-time notifications and trigger automated actions based on specific events within your Pulumi ESC Environments. For example, you can set up a Webhook to notify your team’s Slack channel or automatically trigger a deployment pipeline via a POST request when a new environment revision is created due to changes in secrets and configuration. Webhooks can be triggered by changes to version tags and environment tags, and can be configured per environment or at the organization level for all environments.

Take your automation further by creating Webhooks that trigger Pulumi Deployments, automatically updating your infrastructure in response to configuration changes in Pulumi ESC—without writing custom code and all within the Pulumi Cloud Console.

Hierarchical configurations where one environment imports others are fundamental to Pulumi ESC. If an environment is importing another environment, any changes made to the imported environment trigger a Webhook configured within the current environment. The Webhook will notify you that the environment has changed, and you can call back to open the environment using SDK, REST API, Pulumi Service Provider, and Automation API, and get the latest secrets and configuration.

Getting Started with Pulumi ESC Webhooks

Setting up Webhooks is straightforward. You can use the Pulumi Cloud Console, the Pulumi Service Provider, or REST API.

Using Pulumi Cloud Console

Navigate to the “Webhooks” tab under settings for organization-wide Webhooks or within an individual environment’s top navigation bar.
Select your desired integration (Slack, Microsoft Teams, Pulumi Deployments, or generic JSON Webhooks).
Configure the Webhook details, including the events you want to trigger notifications on.

Using Pulumi Service Provider

Here is a sample code in TypeScript:

const environmentWebhook = new service.Webhook("env-webhook", {
 active: true,
 displayName: "env-webhook",
 organizationName: "my-org",
 projectName: environment.project,
 environmentName: environment.name,
 payloadUrl: "https://example.com",
 filters: [WebhookFilters.EnvironmentRevisionCreated, WebhookFilters.ImportedEnvironmentChanged],
})

Benefits of Pulumi ESC Webhooks

Pulumi ESC Webhooks offer a range of benefits designed to enhance visibility, streamline workflows, and automate key processes related to your secrets and configuration management:

Effortless Automation and Streamlined Workflows: Automatically trigger actions based on ESC events such as application restarts, infrastructure deployments, or configuration updates. Easily integrate Pulumi ESC Webhooks into your CI/CD pipelines to automate builds, tests, and deployments whenever environment updates occur.
Seamless Integration with Pulumi Deployments: Whether you need to update your infrastructure, preview changes, or create temporary infrastructure with TTL or review stacks, Pulumi ESC Webhooks handles all these scenarios, making deployments faster and easier.
Real-time Awareness and Collaboration: Receive instant notifications about critical changes in your Pulumi ESC environments, fostering better communication and collaboration between developers, operations teams, and security personnel. This real-time awareness enables faster incident response times, minimizing downtime and security risks.

Conclusion

Webhooks for Pulumi ESC equip your team with tools to improve visibility, streamline workflows, and automate key processes related to your secrets and configuration management. By integrating seamlessly with your existing communication and development tools, Pulumi ESC Webhooks empower you to automate and streamline your infrastructure management, giving you greater control and agility.

Dive into our documentation and explore the possibilities of Pulumi ESC Webhooks! As always, share any feedback or open new issues in our GitHub repository.

Introducing Pulumi ESC Projects and Environment Tags

Derek Schaller — Thu, 12 Sep 2024 13:00:00 -0400

We’re thrilled to unveil two new features that will empower you to organize your collection of Pulumi ESC Environments: Projects and Environment Tags. Projects offer a structured way to group related environments and Environment Tags allow you to add contextual information to each environment. Together, they offer a powerful way for you to manage, navigate, and collaborate on your secrets and configurations.

Overview of Pulumi ESC

Pulumi ESC is a developer-first platform designed to simplify the management of secrets and configurations into collections called environments. As a fully managed solution, it offers dynamic cloud provider credential resolution, a rich set of providers to retrieve secrets from external platforms, and the ability to use the secrets and configurations you have defined across any surface, including your applications and infrastructure via Multi-language SDKs, REST APIs, CLI, Pulumi-Service Provider, and Automation API. Like all Pulumi functionality, Pulumi ESC focuses on enhancing both agility and security in modern cloud development.

As developers have embraced Pulumi ESC to manage their collections of secrets and configurations across many teams and projects, the demand for more sophisticated organizational tools has increased. To address this growing need for more organized and efficient management of cloud environments, we are introducing Projects and Environment Tags in Pulumi ESC.

Introducing Projects

Projects offer a structured way to organize environments into logical groupings. Each Project has a distinct name, providing context for the environments within it, and can contain multiple environments with variations, each having a specific purpose. Additionally, Projects help large organizations simplify environment management by mitigating possible environment name conflicts and ensuring changes are made in isolation to the correct environments.

For example, your organization could have a project named “payments-app” containing dev, staging, and prod environments within it. Your organization could also have a project called “dev-credentials” which contains different environments used to provide temporary runtime access to credentials for developers while working.

We have two additional features as part of this launch:

Grouping and Search: You can group environments by either Project name or by Environment Tags, as well as search by them, making it simple to locate and manage your environments.
Environment Clone: Using the built-in cloning functionality, you can securely copy environments with sensitive information, preserving either the entire version history or just the latest environment state, depending on your needs.

To use Projects and Environment Tags, please update your Pulumi CLI and SDK to the latest.

Environments will now need to be referenced by specifying the project as part of the environment identifier. Any existing environments within your organization will be available in the default project. Projects are fully backward compatible - all your existing programs, imports and CLI commands will work without requiring any changes at the moment. Note that only environments within the default project will be backwards compatibly and resolve without a project prefix.

Users will be able to create new environments in the default project until Nov 30, 2024. Starting Dec 1, 2024, users will not be able to create new environments in the default project.

Starting Apr 1, 2025, users will not be able to edit their environments within the ‘default’ Project. We recommend customers migrate their existing environments to user-created projects at the earliest to take advantage of new Pulumi ESC capabilities.

Moving environments out of the default project is as easy as cloning the environment into a new project and updating any references to it. An example clone command that preserves all environment history, tags, and team access looks as follows

 $ pulumi env clone default/dev your-project/dev --preserve-history --preserve-env-tags --preserve-rev-tags --preserve-access

We offer numerous ways for you to get started with Projects via the Pulumi Web Console, SDK, REST API, CLI and Pulumi-Service Provider - choose what best fits your workflow. Here is one example using the Pulumi CLI to create and list environments within a project:

 $ pulumi env init cloud-pe/demo
 Environment created: dschaller/cloud-pe/demo

 $ pulumi env ls -p cloud-pe
 cloud-pe/demo
 pulumi/cloud-pe/demo

Breaking Changes

With the introduction of Projects, all existing environments part of the default project will continue to work without requiring any changes. However, when moving existing environments out of the default project you may notice some differences that we have outlined below.

If your environment was interpolating the context.currentEnvironment.name or context.rootEnvironment.name from Contextual information, this value will now include the project for any environments outside of the default project.
If you were using any of the secrets providers with OIDC, you will need to update both the subject and audience if a trust relationship has been set up. The subject will be either pulumi:environments:org:<organization name>:env:<project name>/<environment name> if no subjectAttributes are specified or if the currentEnvironment.name subject attribute is specified it will now resolve to currentEnvironment.name:<project name>/<environment name>. The audience will be the provider’s platform name (aws, azure, or gcp) followed by the org name of the environment (e.g. aws:pulumi).

Introducing Environment Tags

Using Environment Tags, teams can now assign any number of custom tags to each environment within Pulumi ESC. These tags serve as contextual identifiers that can streamline workflows by enabling you to group and search across environments based on specific criteria such as teams, project stages, deployment environments, compliance requirements, or geographic locations. This multi-dimensional approach provides unparalleled flexibility and control, ensuring your Pulumi ESC environments can scale seamlessly with your organizations evolving needs.

For example, suppose your organization has multiple environments across different geographic regions. You can use Environment Tags like ‘region: us-east’ or ‘region: eu-central-1’ to quickly filter environments by region. Similarly, for security audits, you might tag environments with ‘Compliance: SOC2’ or ‘Compliance: GDPR’ to easily find relevant environments and ensure they are compliant.

You can use the Pulumi Web Console and the CLI to create and manage Environment Tags. Here is an example of using the CLI to add and list Environment Tags.

$ pulumi env tag cloud-pe/demo region us-east-1
Name: region
Value: us-east-1
Last updated at 2024-09-10 11:03:05.708 -0700 PDT by Derek <dschaller>

$ pulumi env tag ls cloud-pe/demo
Name: region
Value: us-east-1
Last updated at 2024-09-10 11:03:05.708 -0700 PDT by Derek <dschaller>

Conclusion

Pulumi ESC Projects and Environment Tags are powerful additions that bring order and clarity to your secrets and configuration to even the most complex infrastructure landscapes. By enabling you to organize, group, and search for your environments with ease, we’re empowering you to scale your infrastructure with high confidence and flexibility.

We’re excited to see how you leverage these new capabilities. Check out the docs to learn more about Pulumi ESC Projects and Environment Tags and start organizing your environments today!

As always, please share your feedback on how we can further improve Pulumi ESC to suit your needs.

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.

Secrets and Configuration for Software Engineers: Pulumi ESC Versioning, SDKs and More

Luke Hoban — Wed, 05 Jun 2024 04:00:00 -0700

Last October we launched Pulumi ESC, a new secrets and configuration management offering from Pulumi that manages and tames secrets and configuration complexity across all of your cloud applications and infrastructure. We’ve seen incredible adoption of ESC over the last 6 months, with thousands of developers now managing their secrets and configuration via ESC.

Today, we are excited to announce the most significant collection of Pulumi ESC enhancements since the initial launch, with three major new features that bring best-in-class software engineering capabilities to bear on your Secrets and Configuration management needs.

Versioning: Pulumi ESC now supports versioning of environments, allowing you to see and audit every change to the secrets and configuration for an environment, pin references to an environment to a specific version or version tag, and safely roll back an environment to a previous version.
SDKs: Pulumi ESC now has SDKs available for Python, TypeScript/JavaScript and Go, enabling ESC to be used directly within applications, tools and services to retrieve and manage secrets and configuration values at runtime.
Environments as Code with IaC: New support for defining and managing Pulumi ESC environments, secrets, and configuration from within Pulumi IaC programs allows source-controlled environment specification and managing secrets and configuration lifecycles via code.

All three of these new features double down on Pulumi ESC’s unique approach to secrets and configuration management, which combines a hierarchical and composable approach to defining environments, integration with a wide variety of existing secrets stores and a wide variety of secrets consumers, and a rich configuration-as-code approach.

Together, these provide the richest experience in the market today for developers to apply software engineering best practices to their secrets and configuration management, enabling the management of secrets and configuration complexity at scale across complex collections of environments and applications.

What is Pulumi ESC?

Pulumi ESC is a new category of configuration-as-code product, motivated by our experience working with hundreds of Pulumi IaC customers to address their needs in managing secrets and configuration at scale within their Pulumi infrastructure and across other cloud applications and infrastructure projects.

Pulumi ESC enables teams to aggregate secrets and configuration from many sources, manage hierarchical collections of configuration and secrets (“environments”), and consume those configuration and secrets from a variety of different application and infrastructure services. Pulumi ESC works hand-in-hand with Pulumi IaC to simplify configuration management, but also works independently from Pulumi IaC, as a solution for managing environments, secrets and configuration for any application or infrastructure project.

ESC Versioning

Safely managing the rollout of secrets and configuration changes to applications and infrastructure is one of the fundamental and critically important jobs that a software engineering team does. And yet, state-of-the-art secrets and configuration versioning still typically involve inflexible and bespoke systems for modifying configuration and/or copy/pasting across different environments. Pulumi ESC offers the ability to compose environments to avoid copy/paste, and also now supports rich versioning features to enable full auditability and safe rollout of configuration changes across environments.

There are two core features to Pulumi ESC versioning:

Visibility into the history of every change made to an environment.
The ability to pin any environment reference to a specific revision, or specific tagged version.

These offer the same sort of rich versioning typically seen in other software engineering ecosystems, like Git, Docker, or NPM - but now applied to your secrets and configuration management as well.

You can see the history of changes to an environment:

And then see the diff between any two versions of an environment:

Revisions can also be tagged to provide semantically meaningful names to specific revisions. These tags can be moved later on to point to new versions when you are ready to roll them out to consumers. The latest tag automatically always points to the latest revision.

Most importantly though, you can also then refer to a specific version of an environment anywhere you reference one.

When you run a command with pulumi env run you can specify providers@v2 to pick the v2 tag instead of the default latest:

$ pulumi env run acmecorp/providers@v2 -- aws sts get-caller-identity
{
 "UserId": "AROAY65FYVYP33NYY5FOU:environments-session",
 "Account": "358361613858",
 "Arn": "arn:aws:sts::358361613858:assumed-role/environments-oidc/environments-session"
}

When you import another environment you can import a pinned version. This enables changes to be made to the target environment without automatically being picked up by the consumer. This allows phased rollout, with careful testing of new major versions before they are pushed out to production environments.

imports:
 - ai-staging-aws@v3
values:
 pulumiConfig:
 clusterPetName: gold-kiwi
 clusterTags:
 cluster: ${pulumiConfig.clusterPetName}
 aws:defaultTags:
 tags: ${pulumiConfig.clusterTags}

Read more about Pulumi ESC versioning in the launch blog post.

ESC SDKs for Python, TypeScript/JavaScript and Go

Pulumi ESC was designed from the beginning to support consuming secrets and configuration from any application or infrastructure project. While we have seen lots of early usage combining ESC with Pulumi IaC, the two are not fundamentally tied together at all, and ESC is designed to serve the needs of any complex configuration and secrets management workload.

One of the most important places where secrets and configuration are consumed is in application and service code at runtime. This can take many forms - a few illustrative examples include:

An application that pulls configuration data at startup time
An operational tool that pulls in temporary credentials to perform operations within a cloud account
A control plane service that pushes configuration and secrets changes into other systems to keep configuration up to date and secrets actively rotated

In all cases, it’s important to be able to embed ESC within your application code. At launch, ESC supported a public REST API, but now this has been extended with convenient and easy to use SDKs in the most popular languages - Python, TypeScript/JavaScript and Go.

To use ESC from within your applications, just import the SDK and add a few lines of code:

import pulumi_esc_sdk as esc
import os

configuration = esc.Configuration(access_token=os.environ['PULUMI_ACCESS_TOKEN'])
client = esc.EscClient(configuration)

env, vals, txt = client.open_and_read_environment("acmecorp", "dev-stacks")

print(vals['aws']['secrets']['stripeApiKey'])

Running this gets the Stripe API Key for this environment:

$ python3 __main__.py
rk_test_3c88Pc8ZfdBredactedrEhDU11b42wI5KZ

Lots more details on the features and capabilities of the new Pulumi ESC SDKs in their launch blog post.

Environments as Code with IaC

Pulumi ESC helps to manage configuration and secrets complexity at scale via composition and reuse. But many users still want to go further and version control the definitions of their environments, secrets and configuration.

To enable this, along with many other powerful code-based environment management scenarios, we’ve added support for defining and managing Pulumi ESC Environments via Pulumi IaC itself. New Environment and EnvironmentVersionTag resources are available now in the Pulumi Cloud Provider in the Pulumi registry.

Managing the desired state of environments via infrastructure-as-code programs brings the most robust tools for managing version-controlled desired state definition possible to the realm of secrets and configuration management. And leveraging Pulumi’s best-in-class IaC capabilities and programming model offers the deepest possible software engineering capabilities for defining and managing configuration and secrets as code across environments.

Environment contents can be specified either inline, or in external files, and changes deployed into your Pulumi Cloud account via a simple pulumi up.

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`,
 ),
});

For more on managing Pulumi ESC Environments using Pulumi IaC, check out the launch blog post.

Conclusion

Pulumi ESC is a secrets and configuration management offering that provides best-in-class software engineering features for managing secrets and configuration complexity at scale. Today, we are extending this even further with:

Rich versioning support for auditability and controlled configuration change rollout.
SDKs to easily embed ESC at runtime within applications, tools and services.
Support for source controlling environment specifications using Environment resources in Pulumi IaC programs.

Pulumi ESC has already been adopted by thousands of engineers to manage secrets and configuration complexity. Check it out and get started with Pulumi ESC today!

You can learn more about Pulumi ESC at:

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 Pulumi ESC SDK: Streamline Your Application Secrets Management

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

Managing secrets and application configurations effectively is crucial for building secure and maintainable software. However, developers often face challenges such as hardcoded credentials, configuration inconsistencies, and security risks. Pulumi Environments Secrets and Configuration (ESC) simplifies the management of sensitive data and configuration across your entire application lifecycle. Today, we’re thrilled to introduce the official Pulumi ESC SDK in TypeScript/JavaScript, Go, and Python, making it even easier to integrate ESC directly into your applications.

Primer on Pulumi ESC

Pulumi ESC (Environments, Secrets, and Configuration) provides a developer-first solution to simplify how you manage sensitive data and configuration across your entire application lifecycle. It’s a fully managed solution allowing teams to generate dynamic cloud provider credentials, aggregate secrets and configuration from multiple sources, and manage them through composable collections called “environments.” These environments can be consumed from anywhere, making Pulumi ESC ideal for any application and development workflow. Additionally, while Pulumi ESC works independently to eliminate duplication and reduce drift and sprawl of secrets and configuration for all your applications, it also integrates smoothly with Pulumi Infrastructure as Code (IaC) to enhance these capabilities within the Pulumi ecosystem.

Introducing the Pulumi ESC SDK

We’re excited to unveil the official Pulumi ESC SDK, making it even easier to harness the power of ESC directly within your applications using your favorite programming languages. The SDK provides a simple programmatic interface to all of Pulumi ESC’s robust features, allowing you to:

Manage the Entire Lifecycle of Your Environments: Create new environments, list existing ones, and easily update or delete them as your needs evolve. You can even add version tags to your environments, making it simple to track changes and roll back to previous states if needed.
Seamlessly Integrate Secrets and Configurations: Securely access and utilize secrets and configurations within your applications, ensuring consistency of configuration across environments. The SDK provides a streamlined way to fetch the information you need, whether it’s dynamic cloud credentials, database connection strings, feature flags, or any other sensitive data.

The Pulumi ESC SDK streamlines secret and configuration management, promoting secure handling best practices. It handles the secure storage and retrieval of your sensitive data at runtime, eliminating the need to store credentials long-term and minimizing the risk of accidental exposure. The SDK is a natural extension of your development workflow, offering familiar objects and methods, smooth integration with your IDE, and the benefits of type safety such as compile-time checks and helpful code suggestions that reduce errors and accelerate development.

How to Get Started

Here are a few examples of how to use the ESC SDK for various languages:

import * as esc from "@pulumi/esc-sdk";

async function main() {
 const PULUMI_ACCESS_TOKEN = process.env.PULUMI_ACCESS_TOKEN!;
 const orgName = process.env.PULUMI_ORG!;
 const config = new esc.Configuration({ accessToken: PULUMI_ACCESS_TOKEN });
 const client = new esc.EscApi(config);

 const envName = "sdk-typescript-example";

 // Create a new environment
 await client.createEnvironment(orgName, envName);

 const envDef: esc.EnvironmentDefinition = {
 values: {
 my_secret: {
 "fn::secret": "shh! don't tell anyone",
 },
 },
 };

 // Update the environment with the new definition
 await client.updateEnvironment(orgName, envName, envDef);

 // Open and read the environment
 const openEnv = await client.openAndReadEnvironment(orgName, envName);

 if (!openEnv) {
 console.error("Failed to open and read the environment");
 return;
 }

 // Acces the value of the secret
 const secretValue = openEnv.values?.my_secret;
 console.log(`Secret value: ${secretValue}\n`);

 // List all the environments in the organization
 const orgEnvs = await client.listEnvironments(orgName);
 if (!orgEnvs || !orgEnvs.environments) {
 console.log("No environments found");
 return;
 }

 for (const env of orgEnvs.environments) {
 console.log(`Environment: ${env.name}`);
 }
}

(async ()=>{
 await main();
})();

import pulumi_esc_sdk as esc
import os

accessToken = os.getenv("PULUMI_ACCESS_TOKEN")

orgName = os.getenv("PULUMI_ORG")

configuration = esc.Configuration(access_token=accessToken)
client = esc.EscClient(configuration)

envName = "sdk-python-example"

# Create environment
client.create_environment(orgName, envName)

# create a new EnvironmentDefinition with "my_secret" as a secret in values additional_properties
envDef = esc.EnvironmentDefinition(
 imports=[],
 values=esc.EnvironmentDefinitionValues(
 additional_properties={
 "my_secret": {
 "fn::secret": "shh! don't tell anyone"
 }
 }
 )
)

# Update environment
client.update_environment(orgName, envName, envDef)

# Open and read the environment

env, values, yaml = client.open_and_read_environment(orgName, envName)

secret = values["my_secret"]
print(f'Secret: {secret}\n')

# List environments

environments = client.list_environments(orgName)

for env in environments.environments:
 print(f'Environment: {env.name}')

package main

import (
 "log"
 "os"

 esc "github.com/pulumi/esc-sdk/sdk/go"
)

func main() {
 accessToken := os.Getenv("PULUMI_ACCESS_TOKEN")
 orgName := os.Getenv("PULUMI_ORG")
 configuration := esc.NewConfiguration()
 escClient := esc.NewClient(configuration)
 authCtx := esc.NewAuthContext(accessToken)

 envName := "sdk-go-example"
 // Create Environment
 err := escClient.CreateEnvironment(authCtx, orgName, envName)
 if err != nil {
 log.Fatalf("Failed to create environment: %v", err)
 }

 // Update Environment with Secrets
 updatePayload := &esc.EnvironmentDefinition{
 Values: &esc.EnvironmentDefinitionValues{
 AdditionalProperties: map[string]interface{}{
 "my_secret": map[string]string{
 "fn::secret": "shh! don't tell anyone",
 },
 },
 },
 }

 _, err = escClient.UpdateEnvironment(authCtx, orgName, envName, updatePayload)
 if err != nil {
 log.Fatalf("Failed to update environment: %v", err)
 }

 // Open and View Secrets
 _, values, err := escClient.OpenAndReadEnvironment(authCtx, orgName, envName)
 if err != nil {
 log.Fatalf("Failed to open environment: %v", err)
 }

 mySecret, ok := values["my_secret"]
 if !ok {
 log.Fatalf("Secret 'my_secret' not found in environment %s", envName)
 }

 log.Printf("my_secret: %v\n", mySecret)

 orgEnvs, err := escClient.ListEnvironments(authCtx, orgName, nil)
 if err != nil {
 log.Fatalf("Failed to list environments: %v", err)
 }

 for _, orgEnv := range orgEnvs.Environments {
 log.Printf("Environment: %v\n", orgEnv.Name)
 }

}

Example Scenarios: Pulumi ESC SDK in Action

Here are some real-world scenarios showcasing how you can leverage the Pulumi ESC SDK:

Database Credentials: Applications can use the ESC SDK to fetch database credentials with a specified TTL, ensuring they always use valid credentials, even as the credentials are rotated in the background. This eliminates service interruptions due to expired credentials.
Secure Serverless Deployments: A Google Cloud Function requiring access to an AWS S3 bucket can leverage the ESC SDK to obtain temporary AWS credentials during runtime. This enables secure cross-cloud interactions without embedding long-lived AWS credentials directly within the function’s code.
Microservices Configuration: With ESC, development teams can manage diverse configurations for their microservices, including API endpoints, retry policies, and logging levels, specific to each environment (development, staging, production). The ESC SDK allows each microservice to retrieve the correct configuration values during runtime, simplifying environment-based customizations.

Get Started Today!

The Pulumi ESC SDK is available now! To learn more and start simplifying your application secrets workflow, check out the Pulumi ESC SDK Documentation. We’re confident that this powerful new tool will streamline your development process, enhance your application security, and empower you to build innovative solutions with confidence. Join us on this journey towards a more secure and manageable future for application secrets and configurations!

Unveiling Pulumi ESC Versioning: Manage Secrets and Deployments with Confidence

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

Since the launch of Pulumi Environments, Secrets and Configuration (ESC), our developer-first configuration and secrets management platform, we’ve seen exponential growth in usage. Customers have used it to simplify their secrets and configuration management by organizing them into composable collections called ’environments’. Today, we are thrilled to introduce a comprehensive suite of versioning features, giving you unprecedented control and confidence in managing your environments.

Uncover the Key Features of Pulumi ESC Versioning

Pulumi ESC Versioning introduces a range of powerful features:

Immutable Revision History: Every time you save an environment, a new, immutable revision is created, preserving a complete and tamper-proof history of your changes.
Compare Revisions Side-by-Side: Gain a clear understanding of changes between revisions with our detailed side-by-side comparison view. This helps identify differences, troubleshoot issues, and ensure smooth transitions between versions.
Tag Revisions: Assign meaningful names to specific revisions, enabling you to easily manage and deploy different versions of your environments. You can use tags like production, v1.2.1, stable, pre-release, and in-development to clearly communicate the purpose or stage of each version. Each environment has a built-in latest tag that always points to the environment’s most recent revision.
Import Specific Versions: Precisely control which version of an environment is imported, either by specifying a tag (e.g., environmentA@prod) or using a specific revision number (e.g., environmentB@2). This method also applies when importing environments via Pulumi Stack Config or via other environments, to effectively ‘pin’ the desired version.
Rollback to a Specific Version: Quickly revert your environment to a previous state by rolling back to a specific version or revision. This provides a safety net for deployments and makes it easy to undo unwanted changes.
Retract a Revision: Quickly remove a revision from your history – crucial for situations like accidentally exposing a secret in plaintext.

Level Up Your Workflow

Pulumi ESC Versioning delivers significant benefits that can transform your development process:

Disaster Prevention: By pinning a version during import, you can test new configurations in isolation before applying them to critical production systems. This minimizes downtime, reduces risk, and ensures business continuity, boosting confidence in deployments and supporting agile practices.
Improved Auditing and Collaboration: Easily track the complete history of your environments, including who made changes and when. This granular audit trail enhances security, ensures compliance, and promotes seamless collaboration within your team.
Streamlined Development Workflows: Similar to Docker tags, Pulumi ESC version tags provide a familiar and intuitive way to categorize and utilize specific revisions to manage different stages of your environments.

Tags and specific version imports are available on the Enterprise and Business Critical editions of Pulumi Cloud. The Team Edition offers access to the latest 5 revisions.

How to Get Started

Ready to start using versioning in Pulumi ESC? Here’s how you can get started using the CLI or the Console:

Using the CLI

Make sure you have the latest Pulumi CLI installed before you perform these steps. In your terminal,

Run pulumi env edit <environment-name> to edit an environment
Run pulumi env version history <environment-name> to view all revision history
Run pulumi env diff <environment-name>[@<version>] [[<environment-name>]@<version>] to compare changes between versions
Run pulumi env version tag <environment-name>@<tag> to assign a tag to the latest revision
Create a new environment using pulumi env init <new-environment-name> and import the previously edited environment using this syntax:
```
imports:
- <environment-name>@<tag>
```
Run pulumi env open <new-environment-name> to open and confirm that you have imported the right environment version

Check out the Pulumi CLI documentation for more details on available options and commands.

Using the Console

In your Pulumi Cloud Console,

Open an environment, make a change, and click Save
Go to the Versions Tab and select Revision History view to see the history of changes made to the environment
Click on a revision to see its details or view the differences between revisions using compare revisions
Add a tag to a revision by clicking on the Actions menu
Go to the Tags view and copy the reference to the tag
Create a new environment and import the tag

Real-world Scenarios

Here are a few examples of how you might use these features:

Global Infrastructure Update: You need to deploy a new configuration to a global service spanning multiple regions. Tag the updated configuration as next and deploy it to one region for testing. After verifying stability, you can confidently roll it out to other regions. If issues arise, quickly revert to the previous stable version, ensuring resilient and minimally disruptive deployments.
Platform Team Releases: If you’re a Platform team responsible for generating configurations, by tagging releases with labels like v1.0-stable and v1.2-development, you can clearly communicate which configurations are production-ready, keeping other teams informed about the ongoing development, and fostering seamless collaboration.
Code Review and Debugging: You’re working in a development environment where the latest revision includes multiple recent changes, and you notice that the application is experiencing performance issues. By using the Compare Revisions Side-by-Side feature or pulumi env diff, you can quickly identify the specific changes that might be causing the problem, enabling faster troubleshooting and resolution.

These examples are just a glimpse of how Pulumi ESC’s versioning capabilities can streamline your development and deployment process. The possibilities are vast, and you can tailor your tagging strategy to fit your specific needs and operational workflows.

Conclusion

The versioning capabilities in Pulumi ESC mark a significant step towards a more developer-friendly and efficient platform for configuration and secrets management. These features provide a robust foundation for secure, reliable, and auditable deployments, whether you’re rolling out infrastructure updates or ensuring compliance with industry regulations.

We’re excited to see how you leverage these powerful capabilities. Your feedback is crucial in helping us shape the product to better serve your needs. We encourage you to open new issues on our GitHub repository, upvote existing ones, or join the conversation on our community Slack channel.

Check out the Pulumi CLI and Versioning docs.

Announcing 1Password Support for Pulumi ESC in Public Preview

Tejitha Raju — Wed, 27 Mar 2024 12:00:00 -0600

Today, we are thrilled to add integration support for 1Password in preview within Pulumi Environments, Secrets, and Configuration (ESC). Since its launch, numerous organizations have leveraged Pulumi ESC to manage secrets and simplify configurations using composable environments. Leveraging Pulumi ESC’s comprehensive set of providers, users have obtained dynamic cloud provider credentials and retrieved secrets from other secrets management platforms, including HashiCorp Vault.

The addition of 1Password, known for its developer-centric approach to secrets management, to our roster of integrations has been a top request among our community. As users of 1Password ourselves, this collaboration represents more than just a feature release; it embodies our commitment to enriching the developer experience and fostering secure, efficient development workflows.

Pulumi ESC’s addition of the 1Password provider empowers development teams to seamlessly incorporate secrets and configurations stored within 1Password into their workflows. By using the retrieved values as environment variables or within Pulumi Config at runtime, teams can bypass the manual and error-prone process of copying and pasting secrets, significantly enhancing security and efficiency.

Join our upcoming workshop, “Managing team secrets with 1Password & Pulumi ESC”, to explore Pulumi ESC and the 1Password integration in detail.

How does it work?

Create a 1Password service account with access to necessary vaults
Enter the service token into the 1Password provider configuration within your Pulumi ESC Environment (See syntax below)
Define a path-name, and enter the vault name, item name and field name that you want to import into the path name you defined

1Password provider syntax:

values:
 1password:
 secrets:
 fn::open::1password-secrets:
 login:
 serviceAccountToken:
 fn::secret: <input your service token here>
 get:
 <path-name>:
 ref: op://<vault-name>/<item-name>/[section-name/]field-name

Demo

Now that we know how to use the Pulumi ESC 1Password provider, let’s use it to pull AWS CLI credentials stored in 1Password and use them within Pulumi ESC.

Create AWS CLI credentials through AWS IAM and store it in 1Password Vault. In the demo, we’ve stored the AWS credentials in Engineering vault with aws-cli-creds item name with two fields access-key and secret-access-key
Create a new Pulumi ESC Environment with the following definition. Ensure to replace the serviceAccountToken with your 1Password token

values:
 1password:
 secrets:
 fn::open::1password-secrets:
 login:
 serviceAccountToken:
 fn::secret: ops_eyJzaWduSW5B..[Redacted]
 get:
 aws-access-key:
 ref: op://Engineering/aws-cli-creds/access-key
 aws-secret-access-key:
 ref: op://Engineering/aws-cli-creds/secret-access-key
 environmentVariables:
 AWS_ACCESS_KEY_ID: ${1password.secrets.aws-access-key}
 AWS_SECRET_ACCESS_KEY: ${1password.secrets.aws-secret-access-key}

Open the environment to ensure we are able to successfully pull the credentials from 1Password
Use the Pulumi ESC run command to run any AWS CLI commands

pulumi env run passes the configuration stored under the environmentVariables section into a temporary environment’s env variables. The secure credentials are never stored locally on your machine.

Unlocking New Possibilities

With 1Password integration available within Pulumi ESC, we unlock a range of opportunities for developers to enhance workflow efficiency and security:

Broad Cloud Provider Support: What we demonstrated with AWS applies equally to other cloud providers.
Database Secrets Management: Securely manage and inject database credentials for PostgreSQL, MySQL, etc., into your infrastructure as code (IaC) projects.
CI/CD Integration: Utilize Pulumi ESC and 1Password within CI/CD pipelines, such as GitHub Actions, to ensure secure and efficient workflows.

These examples merely scratch the surface of what’s possible. The combination of 1Password and Pulumi ESC opens up a wealth of scenarios to streamline operations and secure your infrastructure.

Conclusion

Pulumi ESC’s 1Password integration reiterates our commitment to providing choice and flexibility for developers. The 1Password provider brings the power of 1Password within ESC in a highly secure manner. We are excited to continue to work with our partners at 1Password and evolve our integration.

Your journey towards streamlined, secure cloud infrastructure management begins here. We can’t wait to see what you build with Pulumi ESC.

Visit the 1Password CI/CD Integrations page for links to the Pulumi ESC 1Password provider docs
Visit our Pulumi ESC docs to learn more about Pulumi ESC and its supported integrations

As always, we deeply value your insights. Your feedback is instrumental in helping us refine and enhance our solutions to better align with your needs.

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.

Introducing the Latest ESC Editor Enhancements for Improved Authoring

Pat Gavlin — Thu, 22 Feb 2024 00:00:00 -0700

With Pulumi ESC, our goal is to not only create a tool that simplifies the development process but also one that developers love. In pursuit of this goal, we’re excited to announce enhancements to the Pulumi ESC environment editor. These enhancements are focused on addressing common challenges encountered when authoring environments: syntax errors, type errors, frequent context switches to and from documentation, and more. Our aim is to make the process of authoring environments as straightforward as possible by removing common hurdles.

Highlights

Auto-complete: This feature provides suggestions for code snippets and resource properties, easing the need to reference documentation. It is engineered to accelerate and refine the coding process, enabling developers to concentrate on innovation and problem-solving.
Enhanced Diagnostics: These diagnostics go beyond basic syntax checks by providing in-depth, as-you-type insights into errors.
Hover Documentation: Hover over any piece of code to see a detailed tooltip with relevant documentation and examples. This instant access to information reduces the need to context switch, streamlining the development process and minimizing disruptions.

Tap ‘Ctrl+Space’ in the editor reveal the list of functions and properties.

Contextual Information to your environments

We have also added support for accessing contextual information from within an ESC environment such as the current user, organization, and environment name. You can use this information to enrich audit logs, refine OIDC claims for more granular access, and more! This information is available by accessing the context property, and contains the following information:

context.rootEnvironment.name: the name of the root environment being evaluated
context.currentEnvironment.name: the name of the current environment being evaluated
context.pulumi.user.login: the login of the user evaluating the environment
context.pulumi.organization.login: the name of the user’s organization

values:
 rootEnv: ${context.rootEnvironment.name}
 currentUser: ${context.pulumi.user.login}

For the current, complete list of context properties, see Built-in properties.

A Seamless Authoring Experience Awaits

The updated editor experience is designed to minimize friction, boost productivity, and transform cloud development into a more enjoyable and effective journey. We are eager for you to explore these new features and see firsthand how they enhance your development process.

Discover more about the capabilities of Pulumi ESC and how it can support your projects by checking out our documentation.

The Pulumi 'Push to start' GitOps Experience

Kat Morgan — Tue, 23 Jan 2024 19:41:13 +0000

As a skeptic of “quick starts” myself, I approach most marketing promises with a measure of cautious excitement. If the great and powerful algorithm, friends, or a peer brought your attention here, then I invite you to take this one seriously.

Pulumi, with its full support of many general-purpose programming languages, can appear like a chore to get started with. The feeling can haunt seasoned developers as much as practitioners new to infrastructure code.

However, I’ll show you that finding the proverbial easy street is easier than you might believe. The pulumi new developer story just gets sweeter when combined with a few other nice-to-have conveniences.

This is a “bring your own GitHub login” event, so refresh that login. You will want to grab a Pulumi Cloud login as well. With credentials in hand, you are set with everything that you need to start. Let’s go!

Hint: all of the steps in this demo are ready to run yourself from the Pulumi Devcontainer using just your web browser and a Github account. Even better, they are real activities that Pulumians use every day to orchestrate the cloud too!

New technology learning advice

When it comes to ice cream, sometimes just selecting your flavor can be too much. Similarly, when choosing where to start with cloud tooling the onset of “choice paralysis” can be chronic. Pulumi’s powerful toolset is both a worthy endeavor to learn and a rewarding challenge to master. There is no better time to learn than the present!

“If you are short on time and have a bike, do you stop to hop on the bike, or choose to walk because there is no time to stop and get on?”

Freezing, while great for ice cream, is not quite as satisfying when building the next cloud solution and putting it off for next week or next year can be about as useful as walking fast and pushing a perfectly good bike because there is no time to stop and get on.

How can we overcome the learning curve? Picking up and mastering a new tool can be easy if we choose to start small.

Tech learning hacks:

🏆 Do: Start
🔨 Use: Helpful Tools
🥅 Make: Achievable Goals
🎉 Win: Celebrate Successes

Recognizing achievable goals can be tricky when you are learning something new. Always over-estimate the complexity of each step. If you overestimate how complicated a task might be, the biggest risk is accomplishing the goal faster than you think! Either way, the learning journey should be enjoyable and rewarding by following this rule.

Helpful tools are more abundant than ever. I recommend Pulumi as one of the most helpful tools but that is my bias showing through. Consider how intuitive, durable, and well-integrated any tool selection you make will be. Today we’re using multiple features and services of both the Pulumi and Pulumi Cloud offering, as well as demonstrating the benefits of a tightly integrated Git, Github, Devcontainers, and VSCode workflow to make light work of a traditionally considerably complicated achievement.

The resulting developer stack left me feeling like I would be successful automating anything. Be sure to share your experience with us in the Pulumi Community Slack or find us on Twitter/X @PulumiCorp too!

A DevOps journey

The best solutions are often buried in the details. The only way to reach them is to dig.

In true DevOps fashion, development for this blog post featured a roller coaster of chronic scope creep, pushing deadlines, discovering details that scrapped the original plan, and during the final finish line approach too! The worry and doubt was palpable.

Have we taken on too much? Did project ambitions exceed the achievable? The solution emerged while hacking on a side quest with a friend. A single vision came into focus, tying everything together into a simple “Push to Start” Pulumi developer workflow.

In this story, it took two tries to achieve the goal. Often it can take several tries. With that backstory let’s begin this next learning adventure together.

DevOps day 0

Let’s track our DevOps journey in typical “DevOps Day” style. Because we’re counting like computers, of course, we start with zero. In other words, we need a goal, and we will be starting from scratch.

Day zero is going to be your design, planning, and prep phase. Sometimes this includes various stages of research and other times it is a matter of just getting started with hands-on investigation.

Every journey includes a beginning and an end. To demonstrate the Pulumi Push to Start developer workflow, we need a project to develop! For this adventure let’s use the Pulumi Kubernetes Provider from the Pulumi Providers registry to deploy an app on Kubernetes. This provider is one of our most popular providers, as you might guess.

In this case, we can practice with a new project from the Community Engineering team. The GitHub pulumi/devcontainer repository is a GitHub template repository containing all the fundamentals of a new Pulumi infrastructure as code GitOps project. Let’s begin with a quick tour of the GitOps repo boilerplate.

“What belongs in a GitOps git repository?”

I have seen this question raised several times during the past year. Most recently it was brought up during a great customer conversation at AWS re:Invent.

Filtering through the conflicting opinions and advice about proper GitOps repo hygiene, a few fundamentals remain consistent.

Ops Environment
- Configuration
- Dependencies
- Artifacts
Documentation
- Who it is for
- What it does
- How to Operate
- Why it is important
Actions
- Testing: Continuous Integration
- Deployment: Continuous Deployment
- Safety: Version Controls

You may have assembled projects piece by piece before. In the pulumi/devcontainer repository, we provide a turnkey “known good” starter kit which will even improve over time. As a community resource, we welcome bugs and contributions!

And now for the feature presentation, let’s get to dev’ing!

What’s in a DevOps day 0?

Day 0 usually includes aspects of planning and preparing. For this exercise, we have just a few requirements to get started. Let’s knock these out and get to the fun stuff!

Prerequisites

Now, even the fanciest push-to-start car still requires a fob, so let’s cover those bases super quick.

Web browser
GitHub account
10 minutes (approx.)

Next, let’s review the tools we will depend on for developing and deploying our project.

Commandline Utilities:

*Dependencies supplied in the Pulumi devcontainer ghcr.io/pulumi/devcontainer

Tool	Description
A Programming Language	The code part of IaC
Pulumi CLI	Infrastructure as Code Tools
Pulumi ESC	Secrets and Configuration Store
Kubectl	Kubernetes CLI
Direnv	Automated Environment Variables
KinD	Local Kubernetes Infrastructure
Github CLI	Github & Git Repository Binaries
curl, jq, act, awk, etc	Other useful tools

Cloud-native … cloud developer environment?

Besides our command line tools and the programming language of your choice, we need an editor to write our code with. Many practitioners are fluent with Vim or Emacs; others turn to editors like VSCode, IntelliJ, and others. We are going to choose the GitHub Codespaces VSCode IDE for its deep integration with GitHub, and its convenience of requiring nothing from the user other than a web browser to use.

If you are already familiar with GitHub Codespaces, then you might know what to expect next. If not, you are in for a treat, and yes that is right, we are developing for the cloud, in the cloud, with the cloud.

Alright, let’s jump in and get started by launching a new GitHub Codespaces.

👇 Click this button to begin.👇

If you prefer a more informed approach you can launch the same codespaces by navigating to the Pulumi Devcontainer Repository or you can learn more about Codespaces at this Github Codespaces Link.

Clicking the ‘Open in GitHub Codespaces’ button should take you directly into a new Codespaces session.

Note: This demonstration is deeply integrated into the Web based Codespaces environment offered by Github. Alternatively, VSCode also supports running Devcontainers with Docker locally allowing you the benefit of Pulumi Devcontainer on your own hardware.

With a new codespaces session launched you should see the VSCode IDE in your browser. If you are not already familiar with VSCode, you can learn more about it in the VSCode Docs.

Congratulations! Your developer environment is ready for some Pulumi action.

For our final Day 0 step, we still need to decide what app to deploy with our Infrastructure-as-Code (IaC) program.

Focusing on something fun, let’s deploy Minecraft as the app for our Kubernetes exercise. It’s a fun way to get started with Pulumi, a great way to show off your cloud skills to friends, and maybe even share with your favorite young future technologists! After all, Open Source DevOps is for everyone!

DevOps day 1

We have an environment! We have a plan! Now we need to code … or do we?

Don’t just take my word for it. The big brains of Pulumi’s AI Engineering team have delivered a brilliant Pulumi AI. Your Pulumi IaC developer sidekick makes learning and developing Pulumi just that much easier.

Q: What can Pulumi AI do? A: Today’s AI is all experimental. As an industry, we are only just beginning to discover the possibilities, but you are invited to try it yourself with the Pulumi Neo WebUI or with the pulumi new cli as demonstrated below.

`~$ pulumi new --ai`

Pulumi Neo is available via WebUI much like the ChatGPT console. Besides the familiar browser-based interface, Pulumi AI is also built into the pulumi new CLI too! Now you can prompt Pulumi AI interactively from the convenience of the command line tools you will already be using, conveniently configured in your new Codespaces IDE.

Let’s try it! (Reminder: Perform all these steps from within the Codespaces IDE.)

# First Login to Pulumi Cloud for a few features we will use in upcoming GitOps content.
pulumi login

Step 2. Create a new program

# Let's create a new pulumi with the Pulumi CLI
pulumi new

Step 3. YOLO for fun and profit!

Let’s go all in on this one and try Pulumi AI. We can always enhance the prompt with additional dialog back and forth during the pulumi new chat if it doesn’t meet our expectations right away.

It is good to keep in mind that even as advanced as AI is today, the practice is still very much in its infancy. We will save more deep dives into the differences Traditional Ops (Imperative Ops), GitOps (Automated Declarative Ops), and AI Ops (Probability Augmented GitOps) in another post, for now let’s see how close the Pulumi AI can take us.

Woohoo! We selected the AI option on CLI, let’s follow the user prompts and feed the AI a simple prompt of what we want our Pulumi project to create.

Let’s try something like this:

Write a pulumi infrastructure as code program which creates the namespce 'minecraft' and using the pulumi_kubernetes.helm.v3.Release to deploy the https://itzg.github.io/minecraft-server-charts 'minecraft-server' helm chart, sets EULA to true, deploys onto Kubernetes in the minecraft namespace."

How did we do? Let’s see what the AI came up with.

It’s looking pretty good for a simple deployment. In DevOps, nothing works till the CI testing turns green. Since fortune favors the bold let’s proceed. For my developer workflow I ran kind create cluster in the Codespaces terminal. You can do the same or add your own kubeconfig to deploy on your choice of cluster.

Of course, proceed through the remaining prompts from the pulumi new interactive CLI.

I chose Python for this project, but you can choose any of the supported languages. We can see that pulumi new creates a new Python virtual environment for us programmatically. In addition to the boilerplate supporting our new project, Pulumi AI wrote the first iteration of our Python Minecraft Deployment IaC! The next steps should be printed on the screen. Assuming your Kubernetes cluster kubeconfig is ready to roll we just have one step left.

Hint, this is where we get the name for our annual “Pulumi Up conference.

Follow the link for the full playlist of 2023 Pulumi Up sessions

pulumi up -y

DevOps day 2

Finally, it is day two. This is the beginning of a choose-your-own-adventure wonderland and the opportunities go almost as far as your imagination. This is where we commit our code and plan our next change requests and enhancements.

We can commit this code to git. Build a Github Actions Workflow to automate the CI testing of our IaC with every git pr or commit. Once you have a production-ready IaC, you can add another to deploy to production clusters. If you run make act you will see how comfortable testing new GitHub actions workflows can be in the convenience of your new enhanced IDE workflow. You can see the dev container workflow running yourself right away by executing make act as a starting point.

To conclude, Pulumi is not a single tool. Pulumi is a complete cloud developer ecosystem. Tools, SDKs, and cloud services come together forming the most accelerated way to create your own cloud success legends.

Conclusion

Did it deploy?

Let’s check on the status of our deployment.

# Check for your new Minecraft pod
kubectl get po

With any luck, our Pulumi Neo gave you a working program right out of the gate. For references on Kubernetes Pulumi package resources to expand your infrastructure from here head to the Pulumi Registry Kubernetes Provider page for more.

Sharing Pulumi with people is a genuine passion found among Pulumians all around the globe but we all know evidence reigns king among engineers who, like any good practitioner, expect proof. Evolving your developer workflow with Pulumi gets even better than just easy, it’s remarkably powerful and ready for you to adopt in your daily workflows right away too.

Follow PulumiTV for upcoming examples built on this solution and to see how Pulumi ESC brings safety to your secrets and more.

What’s in the recipe?

Because no hero’s journey is complete without a gruesome account of what came before, I have included many of the manual steps required to reach this state one command at a time for the ~~morbidly~~ curious as well.

click ‘details’ to expand

Git Code Repository

Now create a git code repository to version control this project infrastructure code in Github.

# Authenticate with Github before proceeding.
gh auth login --web --git-protocol https --scopes "repo,gist,read:packages,admin:org,delete_repo,codespace"

# Create new Git Repository
gh repo create workshop --public \
 --gitignore Python --license apache-2.0 \
 --description "pulumi iac developer workflow workshop"

# Initialize the git repository
git clone --recurse-submodules https://github.com/${GITHUB_USER}/workshop .

# Configure `git` cli to use the `gh` cli for authentication with Github
gh auth setup-git

# Configure the username and email associated with your Github account.
git config --global user.email ${GIT_COMMITTER_EMAIL}
git config --global user.name ${GITHUB_USER}

# List files being tracked by git and their current status.
git status

Direnv: Automatic Environment Variables

Various non-secret environment variables may be worth maintaining in code locally as well. There are many ways to do this, but here we are going to use Direnv to automatically load environment variables from a .envrc file.

# Add environment variables useful during development to .envrc
cat <<EOF >> .envrc
export NO_COLOR=true
export PULUMI_HOME=\${HOME}/.pulumi
export PULUMI_SKIP_UPDATE_CHECK=true
export PULUMI_SKIP_CONFIRMATIONS=true
export KUBECONFIG=\${PWD}/.kube/config
source venv/bin/activate 2>/dev/null || true
EOF

Now you can enable direnv on this directory.

# Enable direnv in this directory.
direnv allow

Note:

Env variables shown are for educational purposes only and should be used with care. Read more about available Pulumi Environment variables here: https://www.pulumi.com/docs/cli/environment-variables

Pulumi Devcontainer

Now, to make sure we have all of our CLI dependencies, let’s grab the Pulumi Devcontainer.

# Add the Pulumi Devcontainer git submodule
git submodule add https://github.com/pulumi/devcontainer .devcontainer
git submodule update --init --recursive .devcontainer

# Copy the devcontainer config of your choice into the top level of your project
# so it will auto select by default when you open Codespaces in the future.
cp -f .devcontainer/devcontainer.json .devcontainer.json

# Rebuild the codespaces using the newly added Pulumi Devcontainer
gh codespace rebuild --codespace ${CODESPACE_NAME}

Pulumi Cloud

Let’s login to Pulumi Cloud and initialize a new ESC environment to store our environment variables, secrets, and configuration which should be preserved and distributed securely from your Pulumi Cloud account.

# Login to Pulumi Cloud
pulumi login

# Create a new ESC Environment (optionally use another already existing environment)
pulumi env init workshop

KinD: Kubernetes-in-docker

We are going to use Kubernetes to demonstrate our Pulumi IaC. Let’s go ahead and create a new cluster now.

# Create the directory for your new kind kubeconfig
mkdir .kube

# Create a Kind Cluster
kind create cluster

# Let's make sure our kubeconfig works and pods are starting up
kubectl get pods -A

# Load Kubeconfig into Pulumi ESC as an encrypted secret for safe keeping.
# This is an example use case for storing kubeconfig which would not usually be practical
# for disposable kind kubernetes clusters like this however the approach is practical in many
# other scenarios which you may come across.
pulumi env set workshop secrets.kubeconfig.kind --secret "$(jq . -R -s < $KUBECONFIG)"
pulumi env set workshop files.KUBECONFIG --plaintext \${secrets.kubeconfig.kind}

In our environment, we maintain our secrets including API personal access tokens, kubeconfigs, and such all with Pulumi’s Environments, Secrets, and Configuration cloud service.

# Load the newly updated Pulumi ESC Environment in the local shell
eval $(pulumi env open workshop --format shell)

Now let’s create the deployment code!

If fortune favors the bold, let’s be bold on this next step and let AI write our sample code on the fly!

As this is a “hello world” style demonstration intended to showcase the developer workflow more than any specific cloud technologies, let’s deploy something fun like a Minecraft server! Be sure to watch the video demonstration of this exercise on Pulumi’s PulumiTV YouTube channel for an extra easter egg bonus step!

# Write a new Pulumi Python IaC program to deploy Minecraft on Kubernetes
pulumi new \
 --ai "Write a program using pulumi kubernetes helm v3 Release to deploy the itzg/minecraft-server helm chart on Kubernetes, and include a pulumi output to show the helm release status." \
 --description "A pulumi infrastructure as code (iac) program for deploying and serving minecraft on kubernetes" \
 --name "minecraft-on-kubernetes" \
 --language python \
 --stack "workshop" \
 --force \
 --dir .

Now let’s see if our new Infrastructure as Code Pulumi Python Codebase will deploy!

# Deploy your new Pulumi IaC on Kubernetes
pulumi stack select workshop
pulumi up

Cleanup

pulumi destroy -y --skip-preview
pulumi stack rm workshop
kind delete cluster --name kind
gh repo delete ${GITHUB_USER}/workshop

Dynamic Credentials for Every AWS CLI Command: A Step-by-Step Guide to 'pulumi env run'

Torian Crane — Fri, 27 Oct 2023 00:00:00 +0000

In a world where cloud computing is the backbone of modern applications, managing environments and secrets is of the utmost importance. Earlier this month we released a new service called Pulumi ESC (Environments, Secrets, and Configuration), the focus of which is to help alleviate the burden of managing cloud configuration and secrets by providing a centralized way to handle these critical aspects of cloud development. It’s like having a Swiss Army knife in your toolkit, ready to tackle the challenges of cloud infrastructure. This post will highlight the specific challenge of credentials management, and we’ll specifically dive into how using the pulumi env run functionality of Pulumi ESC will make that easier.

Credentials Management in the Cloud

Dealing with cloud credentials can be a major headache, especially when you’re trying to manage them at scale. If you’ve ever agonized over things like how to:

securely share credentials with teammates in a consistent way,
minimize the risks associated with locally configured, long-lived and highly privileged credentials,
ensure teams can easily and safely run commands like aws s3 ls without needing to be a security wizard,

then this post has got you covered. The pulumi env run command was made to solve exactly these kinds of problems.

If we take a look at the Pulumi documentation for the pulumi env run command, it states the following:

This command opens the environment with the given name and runs the given command. If the opened environment contains a top-level ’environmentVariables’ object, each key-value pair in the object is made available to the command as an environment variable.

But what does this actually mean? Using AWS as an example, it means that we can run the aws s3 ls command without having to manually configure AWS credentials in local environments because Pulumi ESC will dynamically generate and project those credentials on our behalf. In this post, we’ll show you how to use Pulumi ESC with the AWS CLI so that every command you run incorporates security best practices like short-term, scoped credentials issued via OpenID Connect (OIDC).

Getting Started with pulumi env run

Now that we’ve covered the basics of what pulumi env run does, let’s dive into how you can start using it! We’ll walk you through everything you need to be able to run the aws s3 ls command without manually configuring local AWS credentials.

Step 1: Install and log in to the Pulumi CLI

To begin, you’ll need to install the Pulumi CLI. Once the installation is complete, run the pulumi login command and follow the steps to log in to the CLI.

$ pulumi login
Manage your Pulumi stacks by logging in.
Run `pulumi login --help` for alternative login options.
Enter your access token from https://app.pulumi.com/account/tokens
or hit <ENTER> to log in using your browser :
Logged in to pulumi.com as …

Step 2: Create the OIDC configuration

Pulumi ESC offers you the ability to manually set your credentials as secrets in your Pulumi ESC environment files. When it comes to something like OIDC configuration, a more secure and efficient alternative is to leverage yet another great feature of Pulumi ESC: dynamic credentials.

This service can dynamically generate credentials on your behalf each time you need to interact with your AWS environments. To do so, you’ll need to configure OIDC between Pulumi and AWS. On the AWS side, there are two resources you’ll need to create:

An IAM OIDC provider
An IAM Role

Let’s start by creating the OIDC provider resource. There are a number of ways you can do this in AWS, but we will demonstrate how to create it via the AWS console.

Please note that while we’re providing steps and screenshots that are accurate as of the date of this post, AWS documentation is subject to change. For the most current and precise information, always refer to the official AWS documentation.

a. Add identity provider

In the navigation pane of the IAM console, choose Identity providers, and then choose Add provider.

In the Provider type section, click the radio button next to OpenID Connect. For the Provider URL, provide the following URL:

https://api.pulumi.com/oidc

For the Audience field, provide the name of your Pulumi organization. Then scroll down to the bottom of the page and click Add provider.

b. Assign IAM role

You’ll see a notification at the top of your screen prompting you to assign an IAM role to your newly created provider. Click the Assign role button.

This will prompt you to either create a new role or use an existing role. For the purposes of this blog, we will select the Create a new role option and demonstrate how to configure it for use with Pulumi ESC.

This will then direct you to the IAM Create role page. The Web identity radio button should already be selected for you but if not, make sure that it is selected. Then scroll down and make sure that the following is selected in the Web identity section:

the api.pulumi.com/oidc provider is selected under Identity provider
the name of your Pulumi organization is selected under Audience

Click Next which will direct you to the Add permissions page. This is where you will select what permissions you will allow your Pulumi ESC environment to have in your AWS account. Since we want to interact with S3, let’s go ahead and select the AmazonS3FullAccess policy from the list. Then scroll down and click Next.

You will be directed to the last page of the wizard, where you can provide the name and an optional description for the role and review all of the role’s configuration details before creating it.

c. Review trust policy

One area that we want to draw your attention to is the Select trusted entities section which is where the trust policy of the role is defined.

This definition currently allows any Pulumi service to assume this role, but only if the request comes from your organization. You can edit this policy to further limit access to this role to just the Pulumi ESC service, and you can make it even more granular by limiting access to a specific environment. This more detailed configuration is outside the scope of this blog post, but you can learn more about it by checking out the relevant Pulumi documentation.

After creating your role, make sure to make a note of your role’s ARN value as you will need it in the next step.

Step 3: Create a new environment

Now that we’ve created all the necessary AWS resources, let’s move over to the Pulumi side of things. You’ll first want to create a new environment in the Pulumi Cloud. Make sure that you have the correct organization selected in the left-hand navigation menu. Then click the Environments link, and click the Create environment button. In the following pop-up, provide a name for your environment before clicking the Create environment button.

Step 4: Add the AWS provider integration

Once you’ve created your new environment, you will be presented with a split-pane document view. You’ll want to clear out the default placeholder content in the editor on the left-hand side and replace it with the following code, making sure to replace <your-oidc-iam-role-arn> with the value of your IAM role ARN from the previous step:

values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 duration: 1h
 roleArn: <your-oidc-iam-role-arn>
 sessionName: pulumi-environments-session
 environmentVariables:
 AWS_ACCESS_KEY_ID: ${aws.login.accessKeyId}
 AWS_SECRET_ACCESS_KEY: ${aws.login.secretAccessKey}
 AWS_SESSION_TOKEN: ${aws.login.sessionToken}

The variables defined under the environmentVariables parameter above are the same environment variables that the AWS CLI uses if you were authenticating with something like the aws configure command. What the above configuration is doing is dynamically generating the credentials and projecting those credential values into your local environment. From there, the AWS CLI picks up those environment variables and runs the designated command. You can find out more about this provider definition and how it works in the Pulumi ESC documentation for the AWS provider as well as the documentation for projecting environment variables.

Click Save.

Step 5: Run your command

Now to the fun part! With your environment set up, try it out by listing all of the S3 buckets in your AWS account. Start by running the aws s3 ls command as normal, making sure to run it in an environment that does not have any AWS credentials configured. You should see the following response:

$ aws s3 ls
Unable to locate credentials. You can configure credentials by running "aws configure".

Now run the command using pulumi env run as shown below, making sure to replace <your-pulumi-org-name> and <your-environment-name> with the names of your own Pulumi organization and environment respectively:

pulumi env run <your-pulumi-org-name>/<your-environment-name> -i aws s3 ls

Voila! You’ve just run an AWS command without any local AWS credential configuration.

The Power of pulumi env run

This is just the tip of the iceberg of how the pulumi env run command can be a game-changer in how you and your team manage and interact with cloud resources. It’s a significant stride towards making your cloud interactions more efficient and less error-prone, and here’s a deeper dive into why:

Seamless Command Execution - The pulumi env run command lets you execute AWS commands effortlessly, freeing you from the intricacies of managing AWS credentials on your local machine. As a developer, you could get temporary credentials for a particular environment to check if your application is working as expected. Simply put, it significantly reduces the overhead of credential setup and maintenance.
Enhanced Security - One of the standout features of pulumi env run is its commitment to security. By removing the local storage of credentials, it drastically reduces the risk of accidental exposure. Your credentials and secrets are securely managed within the Pulumi environment.
Streamlined Collaboration - Because credentials will be centralized, pulumi env run facilitates smoother team collaboration by providing a consistent environment for all team members to run commands with. Everyone can access the same secure environment which reduces the complexities of coordinating credentials and configurations across teams.

Real-World Use Cases

To further illustrate the power of Pulumi ESC, let’s consider a real-world use case: automated data backup. Imagine you have a web application that generates daily logs stored in an S3 bucket. You want to schedule a daily backup job to copy these logs to a separate bucket without exposing your AWS credentials in your scripts or having to manually configure them each time.

With Pulumi ESC, you can create an environment, dynamically generate your AWS credentials, and schedule a daily backup job using a simple script that runs the aws s3 cp command. This ensures your backups are automated, secure, and easily maintainable, all thanks to Pulumi ESC.

This is one example from several dozen use cases possible via Pulumi ESC. Other examples include but are not limited to:

Disaster Recovery:
- Aside from data backups, Pulumi ESC can also be used in disaster recovery scenarios. The pulumi env run command can be utilized to automate the recovery processes, ensuring quicker restoration of services with the correct configurations.
Environment Segregation and Management:
- In organizations with multiple development, staging, and production environments, Pulumi ESC facilitates easy segregation and management of these environments. The pulumi env run command allows developers to execute commands in designated environments without the hassle of manual configuration changes.
Continuous Integration/Deployment (CI/CD) Pipelines:
- Pulumi ESC can be integrated into CI/CD pipelines to automate deployment processes. The pulumi env run command can be used to execute deployment scripts in a controlled and secure manner, making the deployment process more efficient and error-free.
Application Testing and Debugging:
- The pulumi env run command facilitates smooth testing and debugging processes by allowing developers to run test scripts and debugging commands in designated environments with the necessary configurations set automatically.

Conclusion

Pulumi ESC, and the pulumi env run command in particular, is designed to make your cloud journey smoother, more secure, and less daunting. So, the next time you find yourself drowning in a sea of cloud configurations, remember, with Pulumi ESC and a dash of code, you can say goodbye to manual configuration hassles and hello to efficient, secure, and scalable cloud development with Pulumi ESC.

Want to learn more about Pulumi? Our Get Started with Pulumi hub is a great place to start.

If you’re looking for an automated (and faster) way to configure OIDC with Pulumi, we’ve got you covered! Check out our Examples repo where we offer a wide variety of automations using Pulumi Infrastructure as Code (IaC). For OIDC configuration in particular, we have example automation for:

Feel free to join our community on Slack and let us know what you think!

Introducing Pulumi ESC: Easy and Secure Environments, Secrets and Configuration

Luke Hoban — Tue, 10 Oct 2023 04:00:00 -0700

Today, we’re excited to introduce Pulumi ESC, a new product from Pulumi that manages and tames secrets and configuration complexity across all of your cloud infrastructure and application environments. Pulumi ESC introduces a new category of configuration-as-code product, motivated by our experience working with hundreds of Pulumi IaC customers to address their needs in managing secrets and configuration at scale within their Pulumi infrastructure and across other cloud applications and infrastructure projects.

Pulumi ESC enables teams to aggregate secrets and configuration from many sources, manage hierarchical collections of configuration and secrets (“environments”), and consume those configuration and secrets from a variety of different infrastructure and application services. Pulumi ESC works hand-in-hand with Pulumi IaC to simplify configuration management, but also works independently from Pulumi IaC, as a solution for managing environments, secrets and configuration for any application or infrastructure project.

For example, the Pulumi CLI makes it possible to give your developers immediate, just-in-time authenticated and short-lived access to cloud credentials across any cloud provider with just a single command: pulumi env run aws-staging -- aws s3 ls.

Here are just a few of the exciting use cases we’ve seen for Pulumi ESC:

Do you have configuration for dozens of environments that is copy/pasted around and prone to drift? Pulumi ESC lets you manage this as code using a simple set of environments that naturally and flexibly compose to derive all of your different configurations.
Is it hard for developers in your organization to get access to short-lived credentials to work in the environments they need to develop and deploy into? Pulumi ESC lets you configure OIDC to pull short-lived credentials and other secrets dynamically from all of your cloud and secrets providers and present them in a logical way to other tools with a single command like pulumi env run aws-staging -- aws s3 ls.
Have your Pulumi IaC configuration files grown to hundreds of lines of configuration spread across many different stack files? Pulumi ESC introduces a simple way to consume Pulumi IaC configuration directly from Pulumi ESC environments, enabling a much richer secrets and configuration management for Pulumi IaC.

Pulumi ESC is available today in preview via the Pulumi CLI’s pulumi env commands, as part of Pulumi Cloud, via the Pulumi Cloud REST API, and has direct integration with Pulumi IaC stack configuration. It also supports dynamically pulling secrets and configuration from other sources of truth, including AWS OIDC, AWS Secrets Manager, Azure OIDC, Azure KeyVault, Google Cloud OIDC, Google Secrets Manager, HashiCorp Vault, and Pulumi IaC Stack References - with many more sources like 1Password coming soon.

Pulumi ESC: How It Works & Key Features

Pulumi ESC allows you to define environments, each of which specifies a collection of secrets and configuration values. Environments are specified as code, and each environment can import one or more other environments (for composition and inheritance), and can specify its own configuration values directly, or be pulled from another secrets provider.

The following example shows a Pulumi ESC environment which dynamically pulls values from AWS OIDC, HashiCorp Vault and AWS Secrets Manager, as well as setting environment-specific configuration and overriding inherited configuration.

# imports allow you to compose other pre-existing environments
imports:
 # AWS creds via OIDC
 - aws-production
 # stripe API keys imported from vault
 - stripe-production
 # keys for signing docker images via AWS Secrets Manager
 - docker-signing-production
values:
 # environment-specific configuration
 desiredInstanceCount: 8
 # overriding imports
 aws:region: us-west-2

Why Use Pulumi ESC for Cloud Secrets & Configuration?

Working with Pulumi customers, we’ve seen the incredible benefits they get from managing IaC complexity in their code using Pulumi, and yet they frequently end up with a lot of complexity remaining at the boundary to their IaC code - at the configuration and secrets they need to get into Pulumi IaC. Users frequently show us configuration files that are hundreds of lines long, with tons of copy/paste both between Pulumi configuration and between other sources of truth and Pulumi configuration, and with more long lived static secrets being copied around than they would like - creating maintenance burden, security concerns, frequent drift, and operational risk.

As we looked at solving these problems for Pulumi we quickly realized that none of these problems are actually specific to Pulumi - they are all things that customers talked about seeing consistently throughout their infrastructure and application projects. With other IaC tools, with Kubernetes configuration, with 12-factor app environment configuration, and everywhere in between. Everyone we talked to had plenty of scar tissue built up from struggling with a common set of challenges in managing configuration and secrets across a complex set of interrelated environments:

Secrets and Configuration Sprawl: Data in many systems. Challenging to audit. Lots of application-specific logic to acquire and compose configuration from multiple sources. Divergent solutions for Infrastructure and Application configuration.
Duplication and Copy/Paste: Secrets are duplicated in many places. Frequently coupled to application/system-specific configuration stores.
Too Many Long-lived Static Secrets: Long lived static credentials are over-used, exposing companies to significant security risk. Rotation is operationally challenging. Not all systems support direct integration with OIDC and other dynamic secrets provisioning systems.

While customers frequently had good solutions for pure secrets management (AWS Secrets Manager, HashiCorp Vault, etc.), none of these solutions extended into managing the complexities of actually getting these secrets as well as non-secret configuration into the collection of logical environments that define how they will be consumed in infrastructure and applications. Customers struggled with too many walled gardens for secrets management and configuration, and lack of any consistent set of tools and workflows to help manage the complexity of how secrets and configuration flow between these systems.

Pulumi ESC was born to address these problems and needs head on. It does so through a few core design principles:

Hierarchical and Composable: Environments contain collections of secrets and configuration, but can also import one or more other environments. Values can be overridden, interpolated from other values, and arbitrarily nested. This allows for flexible composition and reuse, and avoids copy paste.
Any Secrets Provider: Support for dynamic configuration providers allow Pulumi ESC to integrate with secrets stored in any other provider. Organizations often use AWS Secrets Manager, Vault, Azure OIDC and/or 1Password plus many more sources of truth for their secrets and configuration. Pulumi ESC supports them all, providing a single interface to your configuration and secrets, no matter where their source of truth is. Pulumi ESC works with these tools to provide improved management of secrets and configuration.
Consume from Anywhere: The pulumi CLI and the Pulumi ESC Rest API enables environments to be accessed from any application, infrastructure provider, or automation system. At launch, first-class integrations are available with Pulumi IaC, local environment and .env files, GitHub Actions, and more.
Auditable: Environments must be “opened” to compute and see the set of value they provide, and this action is recorded in audit logs, including a full record of how each value was sourced from within the hierarchy of environments that contributed to it.
Authentication and RBAC: Pulumi ESC brokers access to secrets and configuration that live in other systems, and so authentication and granular RBAC are critical to ensure robust access controls across your organization. Pulumi ESC leverages the same Pulumi Cloud identity, RBAC, Teams, SAML/SCIM and scoped access tokens that are used for Pulumi IaC today, extending these all to managing access to Environments as well as Stacks.
Configuration as Code: Environments are defined as YAML documents which can describe how to project and compose secrets and configuration, integrate dynamic configuration providers, and compute new configuration from other values (construing a URL from a DNS name, or concatenating multiple configuration values into a derived value). The incredible flexibility of a code-based approach over traditional point-and-click interfaces allows Pulumi ESC to offer rich expressiveness for managing complex configuration.
Fully Managed: Pulumi ESC is offered both as a fully managed and a self-hosted service in Pulumi Cloud.

Pulumi ESC enables a new kind of solution for configuration management of modern cloud infrastructure.

Pulumi ESC Overview

We can start by creating a few simple environments using Pulumi ESC. This can be done in the Pulumi Cloud console or using the pulumi env sub-commands in the Pulumi CLI. Let’s take a look at these in action.

You might also like:

Creating and Managing Environments, Secrets and Configuration

First, in the Pulumi Cloud console, we can go to the Environments tab and create a new environment called aws-staging.

We can then define some configuration for our environment. For example, defining our AWS region:

# aws-staging
values:
 aws:
 region: us-west-2

This defines a configuration object with a top level aws key, and a nested region key whose value is us-west-2. When we save this, the preview on the right shows the definition of a configuration object that produces the following JSON:

{
 "aws": {
 "region": "us-west-2"
 }
}

We can make this more interesting by also integrating with AWS OIDC to define the AWS credentials we want to access. To do this, we change our environment to add a creds key to the aws object:

# aws-staging
values:
 aws:
 region: us-west-2
 creds:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/pulumi-environments-oidc
 sessionName: pulumi-environments-session
 duration: 1h

This indicates that we want to pull a set of AWS credentials from the aws-login dynamic provider, which expects a few inputs - including a roleArn we would like to assume and a duration for the short lived AWS credentials that will be returned. If we have configured OIDC in AWS to allow this Pulumi Cloud organization and environment to request short-lived credentials, then this will allow our environment to dynamically pull in those credentials for an authenticated user, and present back a config object that includes them.

To see the values computed by an environment, we need to “open” it. That can be done via the CLI, the REST API or the integrations into other systems (like Pulumi IaC). Let’s open it with the pulumi CLI first. Install the Pulumi CLI, and then run the following commands:

$ pulumi env ls
demo/aws-staging

$ pulumi env open demo/aws-staging
{
 "aws": {
 "creds": {
 "accessKeyId": "ASIAVNHUKX5VGSMMR2DJ",
 "secretAccessKey": "REDACTED",
 "sessionToken": "REDACTED"
 },
 "region": "us-west-2"
 }
}

The aws-login provider returns three values, one non-secret and two secret, which provide the short-lived credentials necessary to authenticate with AWS.

We can also use this configuration as both environment variables and Pulumi IaC config. To do so, we extend our environment to the following:

# aws-staging
values:
 aws:
 region: us-west-2
 creds:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/pulumi-environments-oidc
 sessionName: pulumi-environments-session
 duration: 1h
 environmentVariables:
 AWS_ACCESS_KEY_ID: ${aws.creds.accessKeyId}
 AWS_SECRET_ACCESS_KEY: ${aws.creds.secretAccessKey}
 AWS_SESSION_TOKEN: ${aws.creds.sessionToken}
 pulumiConfig:
 aws:region: ${aws.region}

The top-level environmentVariables key is used by convention to project out a set of environment variables for this environment. The top level pulumiConfig key is used by convention to project out a set of Pulumi IaC configuration for this environment. Note that they can pull their values from other configuration in this environment (or, as we’ll see soon, any environment they import). That includes using the values from dynamic providers like aws-login.

Now that we’ve got a complete environment configured for setting up access to our AWS account, we can use this with pulumi env run to run a command (aws s3 ls) using the environment variables:

$ pulumi env run demo/aws-staging -- aws s3 ls
2023-09-07 16:35:11 accesslogs-1284c27
2023-04-13 15:04:41 accesslogs-6652a3d
2023-01-20 16:52:04 accesslogs-7ea7130
2023-08-23 17:50:24 accesslogs-8ad28c2
...

Note that when we run this command, pulumi env run uses our local authentication credentials (including RBAC permissions) for Pulumi ESC to authenticate our access to this environment, and then uses the environment’s identity to get a short-lived AWS credential via AWS OIDC. It then brings back this unique credential just for the lifetime of the aws s3 ls subcommand. This provides very granular authentication and auditability of the operations run, while also not requiring the user to have a long lived AWS credential on their machine to run operational commands against the account.

Using Pulumi ESC with Pulumi IaC

Next, we can define a second environment for our shopping-service application. This will be deployed with Pulumi IaC, so we’ll provide some default configuration for this service in the pulumiConfig section.

We run pulumi env init shopping-service to create our new environment. And then pulumi env edit shopping-service to open an editor to populate our new environment. We can then add the following to our environment, where it will be encrypted and stored for us.

# shopping-service
values:
 pulumiConfig:
 numInstances: 4
 domainName: shopping.acmecorp.com
 dbPassword:
 fn::secret: hunter2

To use this from our Pulumi IaC program, we want to consume the information in both the shopping-service and aws-staging environments. We can define another environment which just imports these two! Let’s call this third environment shopping-service-staging and define it:

imports:
 - aws-staging
 - shopping-service
values:
 pulumiConfig:
 numInstances: 2

This uses the imports top level key which allows us to compose together configuration from multiple other environments. We don’t have to copy/paste configuration and secrets between stacks, or from other sources of truth – we just import them! This keeps our configuration as DRY as possible.

Note that we also specified a new value for numInstances which overrides what was imported. This allows us to customize the values if this particular environment needs to provide a different value than what it imports.

Now, we can use this directly within our Pulumi IaC project by modifying its stack file. Inside our Pulumi.staging.yaml file for the shopping-service project, we can remove the config section, and just replace it with:

# Pulumi.staging.yaml
environment:
 - shopping-service-staging

If I run pulumi preview now on my Pulumi IaC project (in this case, a project which just outputs the configuration values), we will see that configuration values for aws:region, numInstances, and dbPassword are all available. I didn’t have to copy them into this stack, they were automatically pulled out of the environment in Pulumi ESC. And note that the secretness of the dbPassword configuration value flowed through into Pulumi IaC’s config system to ensure this value is encrypted in any place it is used within our infrastructure as code.

Previewing update (pulumi/staging)
View in Browser (Ctrl+O): https://app.pulumi.com/pulumi/shopping-service/staging/previews/f0f9a124-88e1-4d4a-8025-178aac9127c3
Type Name Plan Info
+ pulumi:pulumi:Stack shopping-service-staging create 3 warnings
Outputs:
dbPassword : [secret]
numInstances: 2
region : "us-west-2"
Resources:
+ 1 to create

Finally, we can give other users in our organization access to this environment by configuring our Engineering team within Pulumi Cloud to be allowed to “Open” the environment.

Pulumi ESC enables us to define environments containing secrets and configuration using a flexible, code-based approach, leveraging composition in order to keep our configuration DRY, as well as dynamic providers to pull secrets and credentials from other providers like AWS OIDC. While this example used AWS, everything discussed works with any cloud, and with an even wider variety of secrets providers.

The Future of Pulumi ESC

We’re excited to launch the public preview of Pulumi ESC today, and see it solving many pressing problems with the feature set available today. We see even more opportunity to enhance this foundation, and have designed Pulumi ESC with a few new capabilities in mind. These features will ship in the coming months.

Application-level SDKs

Pulumi ESC can already be accessed from application code via the REST API, but we will be extending this to native SDKs for TypeScript, Python, Go and .NET. These SDKs will enable configuration from ESC to be directly pulled into applications at runtime, instead of, or as well as, provisioning via environment variables or other mechanisms at deployment time. See pulumi/esc#60.

Syncing Configuration to External Systems

While the pulumi CLI and REST APIs can be used today to pull configuration down into many existing places where environments will be consumed, there are also many systems that store their configuration in more “walled gardens” which would need to be pushed into for optimal usability. For example, pushing configuration values into a CI/CD system’s configuration system to avoid needing to copy/paste configuration and secrets manually into their UI. We are working on additional integrations for Pulumi ESC that can “push”/“sync” configuration into systems directly, so that you can still benefit from the usability of their native configuration systems, without having to take on the problems of configuration sprawl, long-lived static secrets and duplication and copy/paste of secrets. See pulumi/esc#58.

Dynamic Configuration Provider Ecosystem

We are already working with many additional partners to support pulling configuration and secrets from additional sources of truth into Pulumi ESC - including 1Password, Cloudflare and more. Our goal is to support rich composition of configuration and secrets no matter where they live, and in the most secure way possible, and working with these providers will enable ESC to integrate natively with their systems. As part of this, we will also be working to bring the provider plugin model into the open source pulumi/esc repository along with the existing dynamic configuration providers. See pulumi/esc#64 and pulumi/esc#65.

Versioning Environments

At launch, environments are managed directly in Pulumi Cloud. But we’ve already heard early preview users express a desire to also be able to manage these via source-controlled code. We’re exploring adding environments to the Pulumi Cloud Pulumi Provider to enable using desired state IaC to manage the definition of environments. We’ve also worked with customers looking to be able to pin their projects that consume environments to specific versions of the environment, to avoid risk of breaking when environments are updated, and are working on extensions to enable this as well. See pulumi/esc#59 and pulumi/esc#63.

Easy-to-Use Key/Value Interface in Pulumi Cloud

For the preview, we focused on document-based editing experience for environments, which provides direct access to the full richness of Pulumi ESC. For many common use cases, it’s helpful to have a simple key/value-based interface for adding and configuring secrets. We will add the ability to switch between both of these UI experiences in the Pulumi Cloud console soon. See pulumi/esc#62. Below is an early sketch of this additional table-based user interface.

Conclusion

Pulumi ESC is a new kind of configuration management offering that addresses pervasive issues faced by teams performing application and infrastructure development. We’re incredibly excited to launch the public preview, and to work with our community to continue our journey together. While in preview, Pulumi ESC is available at no additional cost to all Pulumi Cloud users.

You can learn more about Pulumi ESC at:

Pulumi Secrets Management

Sanjay Bhagia — Wed, 16 Mar 2022 09:15:57 -0800

Pulumi community member Sanjay Bhagia explores using Pulumi to manage secrets.

We will build on the Configuration Management blog post that I wrote earlier so please have a look if you haven’t done so already.

Having sensitive information such as Passwords, API Keys, Tokens, ConnectionStrings etc. is quite common for any application. However keeping them in your source code in plaintext is never a good idea, let alone checking it in your source control.

Pulumi’s configuration system lets us add secrets to our configuration in a similar way we manage any other configuration. Pulumi offers multiple approaches to manage sensitive information and exposes a number of APIs and tools we can use to work with them seamlessly, so without further a do, let’s explore how it all works.

Handling Secrets

First off, let’s see how can we set secrets in our configuration.

We use pulumi config set with --secret flag to set a secret

$ pulumi config set --secret mySecretKey mySecretValue

Check the config pulumi config

To retrieve the secrets programmatically, the use of RequireSecrets variant is recommended.

Pulumi.Log.Info($"mySecretKey: {config.RequireSecret("mySecretKey")}");

see the value is masked

If we look at the Pulumi.dev.yaml file in VSCode, this is what we see:

config:
 azure:location: australiaeast
 hello-pulumi:data:
 active: true
 nums:
 - 1
 - 2
 - 3
 hello-pulumi:location: australiasoutheast
 hello-pulumi:mySecretKey:
 secure: AAABAFybCK/w34qectPQHPWSoivUhG7uI5//y7Xqc/6Cczh3k3Yi35zvrk+U
 hello-pulumi:resourcesName: pulumi

Looking at this, what we see is that the configuration we set as a secret is not stored in plaintext, it is in fact encrypted. By default, Pulumi uses per-stack encryption key managed by the Pulumi Service to encrypt values.

However, this might not be desirable in situations where you want to manage the state by yourself by using any external storage like S3 bucket, Azure Blob storage. Or you simply don’t want Pulumi to manage the keys and would prefer keeping that control and management with you. For such scenarios, Pulumi supports multiple providers for secrets management.

As of this writing, these are the supported providers:

default
passphrase
awskms
azurekeyvault
gcpkms
hashivault

We used default provider in our examples above. passphrase allows you to keep the encryption keys to yourself but still use Pulumi’s backend service for state management OR you are self-managing the state storage (e.g., Azure Storage). The last option is where you are completely managing your own keys (bring your own key a.k.a BYOK)

Using Passphrase

Let’s create a new stack in our codebase that we used in the previous blogpost (grab the core here)

$ pulumi stack init passphrasestack --secrets-provider passphrase

or create a new project:

$ pulumi new azure-csharp --secrets-provider passphrase

It’ll ask for the passphrase. This is the passphrase that Pulumi is going to use to encrypt the configuration system.

Looking at the project in VSCode, we can see a new file has been created.

Let’s add two keys (one normal and one secret):

$ pulumi config set normalKey normalValue` `pulumi config set --secret secretKey secretValue

This is how our stack file looks like:

If you pay attention, the secure value in Pulumi.passphrasestack.yaml is different to what we had in Pulumi.dev.yaml

Notice, we need to enter the passphrase every time we are performing any operations. This can be avoided by setting PULUMI_CONFIG_PASSPHRASE in your environment variables (can be done on the local machine or in the CI system).

Using Azure Key Vault for encryption

This would be a similar approach for any other cloud-based provider but we are looking at Azure Key Vault here. In order to use the Azure Key Vault for managing the encryption keys, the approach is same i.e., we set --secret-provider to Azure Key Vault via the CLI

$ pulumi stack init <name> --secrets-provider="<provider>://<provider-settings>"

e.g.,

$ pulumi stack init <name> --secrets-provider="azurekeyvault://<keyvaultname>.vault.azure.net/keys/<key name>"

Before we could do this, we need to create the Key Vault and a Key in the vault that we need.

Create Azure Key Vault

$ az keyvault create --name pulumiazvault --resource-group rg-pulumi-dev --location australiasoutheast

Create the Key in Vault

$ az keyvault key create --name pulumiencryptionkey --vault-name pulumiazvault

Assign Access

When you create the vault and key from the CLI, a policy is created by default but it doesn’t set ’encrypt’ and ‘decrypt’ policy for us, so use this command to include that.

Extract Object Id of your account (you can pull this from Azure AD or run the command below to extract it. Use your account here.):

$ az ad user show --id <your account name>

Look up for ObjectId of your account:

$ az keyvault set-policy --name pulumiazvault --object-id <Object Id from above> --key-permissions encrypt decrypt get create delete list update import backup restore recover

I prefer using Azure AD Application instead of any individual user account for such scenarios. In that case you will need the ObjectId of the application instead.

Now we have the key vault with a key that we will use for encryption along with the right access policy set.

Set Environment Variables

You can set this if you want to use the credentials from the CLI (that you already have set up). AZURE_KEYVAULT_AUTH_VIA_CLI=true

Checkout Azure Environment Authentication if you wish to use other authentication mechanism such as Client Credentials, Username/Password etc.

I prefer using Client Credentials since I’m using Azure AD Application approach.

Create a new stack

I’m creating a new project for this scenario rather than using the previous one but you could very well create a new stack in the same project that uses Azure key Vault provider.

pulumi new azure-csharp --secrets-provider="azurekeyvault://pulumiazvault.vault.azure.net/keys/pulumiencryptionkey"

Pulumi.dev.yaml files looks like this after creating the new project. As you notice, we have the information about secrets provider and encryption key. From this point onward, Pulumi uses this information to encrypt the configuration system for us.

secretsprovider: azurekeyvault://pulumiazvault.vault.azure.net/keys/pulumiencryptionkey
encryptedkey: N1JsSnFjWGpKUl9jY3U1SlRQd2J2WXd3TEw0XzQxeWExY2hTOEhtLTRKWkd3cTViblg3OWF4VHFTcDY4amo4RDc4RUxyT3poNC0tUEVSM0ppbUxfcUdiN1dOWm9Cb0VrNU5TODF6dUlMVEg3c2VVc1ItTVZfRjFBQWpmdGNiX29xYU1BdTN2d0NlMmtWUWFUWUc0NjNJMnh4eUNybzdJMzlXZHdXMVRpODh4TnZfdDM1R2pfdS1rS3VlQlh5cDI4OXZmMkxXaFFuNzNBckJaRU9vcnl5WmJPeUVXMHpJSzlIOEZXOG5WTnl6akFXYmxWYkkyYVB6c3BsUWpDOGw5OFRJNXFyV0JBSjAybHVkTE9UMGF6MllqSW4xbm9GVW1pODRsbVJZbEh6OThPLUdBemlhcWp4V1dKaE5vN0NDeEFZdFM2cXk3emozSDI0UHlGQllESTdR
config:
 azure:location: australiasoutheast

Rest of the things works the same as default or passphrase provider for encryption.

Switching Encryption providers

You change the secrets provider of any of your stack anytime via this command.

pulumi stack change-secrets-provider "<secrets-provider>"

It’s pretty straightforward, once the provider is changed, Pulumi will use the new secrets provider to encrypt configuration and state files.

Summary

Pulumi provides a robust mechanism for configuration management of your infrastructure. It provides support for handling secrets as well. You have the possibility to use external service providers for secrets management such as Azure Key Vault by using a familiar approach. The default option is secure and configurations and secrets are encrypted by the keys that Pulumi manages for us however we have the flexibility to take ownership of this and go to that extra mile for enhanced security or compliance reasons.

You can find the source code for this blog post here.

This article was originally posted at https://www.sanjaybhagia.com/2021/01/26/pulumi-secrets-management. Reposted here with permission.

Keeping Your Secrets Secret

Sophia Parafina — Tue, 23 Mar 2021 00:00:00 +0000

Companies that have suffered data breaches are, unfortunately, frequently in the news. A data breach is when information that should be private, such as credit card numbers or even trade secrets, is stolen. These thefts can be because of an actual cyber-attack, but they can also be due to simple carelessness, such as disposing of computer equipment without taking proper precautions.

As an example, Bitcoin miners have perpetrated many data breaches. Suppose you accidentally push a dotfile with an aws_access_key_ID to GitHub. Bitcoin miners have a host of tools that automatically scrape GitHub for exactly that sort of information. Once they have your AWS credentials, they lock you out, spin up machines and start mining. This isn’t as common as it once was since cloud providers are better at detecting these sorts of incursions, but you can see how catastrophic (and costly) such a data breach can be.

Of course, you can protect yourself and your company. In this blog post, we’re going to give a quick rundown of some actions you can take to make sure your secrets stay secret.

What Is a Secret?

We’re going to define secrets as small, critical pieces of information. They’re no larger than a few KBs, and they’re necessary to run your infrastructure. If they’re leaked, your infrastructure is compromised and bad things can happen. Some examples of secrets are passwords, API keys, and SSH keys.

Remove All Plaintext Secrets

Step one is to search through your existing codebase and remove any secrets that are in plaintext. A simple approach is to manually grep or search through your files, looking for words such as username and password. However, there are also tools available that will comb through your Git history and commits, looking for sensitive information. Many of these tools are open source.

Build detection into your CI/CD pipeline

Making secrets detection a part of your CI/CD pipeline is a great way to ensure you’re not pushing confidential information to a public repo. There are tools that integrate into your automated workflow. You can configure those tools to stop the pipeline if they detect secrets such as keys or passwords.

Don’t Forget about Git Commits

It’s easy to forget that Git commits can contain sensitive information. For example, someone might talk about a security issue and how they fixed it. Instead, give a link to your ticketing system and document the problem there.

Encrypt and Manage Your Secrets

After you’ve stripped out your plaintext secrets from your codebase, you still need to to store and manage them securely. Encrypting secrets rather than storing them as plaintext is a good start.

Manual encryption

There are command-line tools for encrypting secrets, such as GPG (also called GnuPG) and PGP, which stands for Pretty Good Privacy. These are free, but many people find them difficult to use, and standard security practices such as rotating your keys can be challenging to implement.

Secret servers

There are many servers that store secrets securely available on the market. Secret servers encrypt your secrets and usually have many other features that encourage best security practices, such as access control lists and the ability to audit who’s accessing your keys.

Cloud-provided services

Given that many companies have their infrastructure in the cloud, it makes sense to consider using the secrets services that your cloud provider offers. To mention a few, Google Cloud has Secret Manager, AWS has the AWS Secrets Manager, which relies on the AWS Key Management Service (KMS), and Microsoft Azure has Key Vault. These services have many built-in capabilities that enable you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.

Have a Plan

Mistakes happen and, even if you’re careful, leaks can occur. It’s important to have a plan already in place if you’ve detected a data breach. Here are some of the things you should do.

Reset passwords and create new keys.
Monitor your systems to find anomalies and unusual usage.
Destroy as many machines as you can and spin up new instances with new credentials.
Keep track of what you’ve done so that you can have a meaningful post-mortem once you’ve put out the fires.

If you haven’t done so already, consider installing intrusion-detection systems. There are many on the market, including open-source tools. There’s no single answer for what to do when leaks happen, but it’s important that all the stakeholders get together and put a process in place.

Practice makes perfect

Once you have a plan, consider staging a data breach and follow that plan to see how well it works. For example, you might simulate a spoofing attack or have someone “steal” a laptop and see how much damage they can do.

Move Security to the Left

Security should be as much a part of your workflow as any other phase of the development process. Just as you start testing your code early to find bugs, you should test early to find security problems. Security shouldn’t come at the end of the development cycle when you think you’re production-ready. Just as with any other problem, security issues are much easier to fix early in development.

Learn More

Pulumi takes security risks seriously. That’s why our platform is secure by default. It protects all secret data using Pulumi’s built-in secret storage, a secret store that “just works.” We also support all the major cloud-provided secret services. Want to learn more? Visit pulumi.com or get started for free today.

Keep your secrets secure, by default

Alex Mullans — Fri, 19 Feb 2021 00:00:00 +0000

An unauthorized user gaining access to your infrastructure can be catastrophic: data can be stolen or leaked, security holes can be exploited, and more. That risk makes it critical to keep the infrastructure secrets—the passwords, access tokens, keys, and so on—well-protected. This is particularly true in automated systems, like continuous integration and delivery and infrastructure-as-code systems.

Pulumi’s built-in secret storage

Pulumi takes these risks seriously. That’s why we built the Pulumi platform to be secure by default. It protects all secret data using Pulumi’s built-in secret storage. This secret store “just works”, regardless of whether you use our hosted Pulumi Service, the Self-Hosted Pulumi Service, or the self-managed backend. The Pulumi Service protects secrets automatically when you create a stack with pulumi new or pulumi stack init. If you use a self-managed backend like AWS S3 or Google Cloud Storage, secrets are protected by a passphrase that you choose when you start a new stack with pulumi new. In all cases, every Pulumi stack gets a unique encryption key.

What secrets are protected

Pulumi protects all of the state metadata that it knows about your infrastructure with encryption: encryption in transit when it’s sent to your backend and encryption at rest (if you’re using the hosted or self-hosted Pulumi Service). This base layer of protection applies to all state, including both non-secret and secret metadata. Secret storage is the next level of protection. It ensures that secret values are never exposed in plaintext in any file that Pulumi writes to your disk. Secrets are identified in a few ways:

All Pulumi providers—both native providers like azure-native and Terraform-based providers like Datadog—know which of their outputs should be secret and mark them as such. This ensures that you’re secure by default when you start using a new provider. There’s no need to pick which outputs are secret or worry that you’ve missed one.
You can mark other Pulumi outputs as secret.
In addition to Pulumi inputs and outputs, you can also mark Pulumi configuration values as secret.

Any secret identified by you or by Pulumi is fully protected in the secret storage and not stored in plaintext on disk. This prevents leaks of secrets when files are committed to a source code repository or uploaded to a continuous integration and delivery system.

Integration with other secret stores

For smaller organizations, the secret storage built into Pulumi is usually sufficient. In larger organizations however, it’s likely that a centralized secret management system is already in use, like AWS Key Management System, Azure Key Vault, Google Cloud Key Management, or Hashicorp Vault. Pulumi integrates with each of these systems to make it easy to protect secrets in the way required by the organization.

Next steps

It’s easy to get started with secrets management in Pulumi, because there’s nothing extra you need to do. Begin with any one of our get started tutorials and Pulumi will automatically protect your secrets along the way.

Learn more about Pulumi’s secret storage in our docs

Managing AWS Credentials on CI/CD: Part 3

Chris Smith — Thu, 14 May 2020 00:00:00 +0000

This article is the third part of a series on best practices for securely managing AWS credentials on CI/CD. In this article, we cover the last leg of the continuous delivery process to update your AWS resources and how to store sensitive data using Pulumi securely.

Recap

In part 1, we created a dedicated IAM User with limited privileges. Then in part 2, we set up a simple, serverless Pulumi program that periodically rotated the User’s access keys and updated the CI/CD system.

In this final post, we will use those AWS credentials to update cloud resources as part of a CI/CD workflow using Pulumi.

We will cover AWS’s IAM Roles and how they can be used to safely manage the access Pulumi has to your AWS account. We will also cover how sensitive data in your stack is stored within the Pulumi Service.

Assuming IAM Roles for Performing Updates

In the previous post, we automatically create and rotate the AWS access keys for an IAM User. So it seems natural to think that we should just use that same AWS access key to gain access to AWS resources. However, using the access keys for an IAM User has a few major drawbacks.

First, those access keys are long-lived. If we didn’t create that Pulumi program to rotate them automatically, the key would last forever. (Meaning that a bad actor, perhaps elsewhere, or far in the future, could take advantage of a compromised key.) Second, that access key could be used to do anything that the IAM User could. So you cannot differentiate the set of capabilities based on the task at hand. (For example, if updating the Pulumi stack website/staging, we might need a different set of permissions than if we were updating the stack website/production.)

The preferred alternative to using IAM User access keys is to “assume” an IAM Role. An IAM Role is similar to an IAM User in that it grants a set of policies and permissions. However, unlike an IAM User, an IAM Role does not have a password, nor can it be added to a Group and inherit any policies. Also, the credentials for using an IAM Role are always short-lived. (Lasting no more than 12 hours, and likely much, much less.)

Instead, an IAM Role defines a set of capabilities that can be performed by any principal capable of assuming it. So in other words, you can exchange your limited access IAM User’s credentials for a specialized IAM Role. The IAM Role then can be specifically tailored to a specific— wait for it— role to perform.

Don’t worry if that doesn’t all make sense at first; let’s look at a concrete example.

Desired End State

In our situation, we want to create an IAM Role WebsiteStackUpdaterRole that grants permissions necessary for Pulumi to update the website/production stack. We will custom tailor this role to only grant access to the set of resources and operations we know the stack needs.

We also want to restrict who can assume the WebsiteStackUpdaterRole, so that only specific users/accounts can access it. e.g., the IAM User cicd-bot but not IAM User dwight-over-in-sales.

And just to show a more real-world example, we’ll do this using multiple AWS accounts, where the website/production stack’s resources are housed in a “production” AWS account, and the cicd-bot IAM User is defined in a bastion AWS account.

Creating the IAM Role

The following snippet creates an IAM Role resource using Pulumi. The most important input property of which is the assumeRolePolicy document, which defines who can assume this role.

This is a situation where Pulumi’s ability to declare the policy document in code is super-useful, as it makes it much easier to reference other resources (e.g., another AWS account’s ID) as well as supporting inline comments.

// IAM Role used by cicd-bot to update the website stack.
export const websiteStackUpdaterRole = new aws.iam.Role("WebsiteStackUpdaterRole", {
 name: "WebsiteStackUpdaterRole",
 description: "Broad access for updating Pulumi stacks in the 'production' AWS account.",
 maxSessionDuration: 30 * 60, // 30 minutes
 assumeRolePolicy: {
 Version: "2012-10-17",
 Statement: [
 {
 Effect: "Allow",
 Principal: {
 // We grant the "bastion account", which defines IAM Users the ability to assume this role.
 // The IAM Policies in that other AWS account will then determine which users, groups, etc.
 // will be able to use the `sts:AssumeRole` action on this IAM Role.
 "AWS": `arn:aws:iam::${awsAccountIds.bastionAccount}:root`,
 },
 // But as an additional precaution against misconfiguration in the bastion account, we add
 // some additional checks to determine who can access this policy.
 Condition: {
 "ForAllValues:StringEquals": {
 "aws:PrincipalTag/access-to-production": "true",
 "sts:ExternalId": [
 "contoso/website/production",
 "contoso/website/staging",
 ],
 },
 },
 Action: "sts:AssumeRole",
 },
 ],
 },
});

There’s a lot packed into that IAM Role’s configuration.

First, the “principal” (who can assume the role) references a specific AWS account. This is an example of how you can associate one AWS account with another. (And is best practice for isolating data between different departments, etc.) We’ll cover how to configure the AWS bastion account side to use this role later.

The next thing to call out is the use of the Condition element of the policy document. To assume the role, we require two checks to be performed.

That the principal assuming the role (e.g., IAM User) has the tag "access-to-production" with value "true." This way, we will reject any IAM User in the bastion account who isn’t tagged with "access-to-production" from assuming this role.
We also verify that the “external ID” (an optional parameter passed when assuming an IAM Role) matches a well-known Pulumi stack name. This way, we can double-check that the entity using the IAM Role is doing so to use a specific stack. (This is less of a security measure and more of a general hygiene type requirement.)

IAM Policy Document

Now we have an IAM Role; we need to attach a policy document that defines what permissions are granted.

This is the most important step since it defines precisely what the CI/CD bot can able to do.

If we define the policy too broadly, then it is a general risk. For example, what if a compromised NPM package in your Pulumi program did something nefarious. If the policy is defined too narrowly, then your pulumi up might fail because the necessary permissions weren’t available. When in doubt, err on the side of having a more restrictive policy.

It can be advantageous to have an identical “staging” and “production” instance of the same Pulumi stack, so you can detect any permission issues before you update the user-facing production stack.

It can take some time to winnow down the specific set of permissions necessary since that is ultimately specific to the Pulumi program. For example, if the stack governs the networking configuration, then you can simply not deny to the s3:* actions.

Unfortunately, Pulumi doesn’t currently support generating a reasonable IAM Policy document for your stack. For a good introduction to some of the “worst-case scenarios” that could arise from a misconfigured IAM Policy, see this blog post from BishopFox.

The following is a hypothetical IAM policy that restricts the operations performed to just those for the AWS CloudFront and S3 products. (Which might be sufficient for updating a CDN-based website hosted on AWS, but likely not much else.)

// Policy document defining the permissions granted to the WebsiteStackUpdaterRole.
export const websiteUpdaterPolicyDocument: aws.iam.PolicyDocument = {
 Version: "2012-10-17",
 Statement: [
 // Grant access to all AWS S3 actions, but scoped to just the specific S3 buckets
 // used for the given Pulumi stack.
 {
 Sid: "GrantS3Access",
 Effect: "Allow",
 Action: "s3:*",
 Resource: [
 // Content bucket.
 "arn:aws:s3:::website-bucket",
 "arn:aws:s3:::website-bucket/*",
 // S3 bucket which stores the access logs.
 "arn:aws:s3:::website-logs-bucket",
 "arn:aws:s3:::website-logs-bucket/*",
 ],
 },
 // Grant access to update a CloudFront distribution. For more information, see:
 // https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/access-control-managing-permissions.html
 {
 Sid: "GrantCloudFrontAccess",
 Effect: "Allow",
 Action: [
 "cloudfront:CreateDistribution",
 "cloudfront:DeleteDistribution",
 "cloudfront:GetDistribution",
 "cloudfront:GetDistributionConfig",
 "cloudfront:ListDistributions",
 "cloudfront:UpdateDistribution",
 "cloudfront:ListCloudFrontOriginAccessIdentities",
 ],
 // The specific CloudFront distribution used in the stack.
 Resource: "arn:aws:cloudfront::0123456789:distribution/A123B1CABWZZ",
 },
 ],
};

const websiteUpdaterPolicy = new aws.iam.Policy("WebsiteUpdaterRolePolicy", {
 name: "WebsiteUpdaterRolePolicy",
 description: "Policy granting the permissions needed for updating the website/production Pulumi stack",
 policy: websiteUpdaterPolicyDocument,
}, resourceOptions);

To actually associate the IAM Policy document with the new IAM Role, we need to create a PolicyAttachment associating the two.

const rolePolicyAttachment = new aws.iam.RolePolicyAttachment("WebsiteStackUpdaterRolePolicyAttachment", {
 role: websiteStackUpdaterRole,
 policyArn: websiteUpdaterPolicy.arn,
});

Reminder, we defined the IAM Role in our production AWS account, which allows any principal in the AWS bastion account (with the right tag, external ID) to assume that role. We then need to update the bastion account to grant the sts:AssumeRole action on that IAM Role so it can be used! That isn’t covered in this post.

Assuming the IAM Role

Finally! With everyone in place, we can now use the IAM Role.

The following is a set of commands you can run on your CI/CD worker to exchange the low-privilege IAM User credentials for the specific IAM Role we just created in the production AWS account. But there are many alternatives for programmatically assuming an IAM Role, such as using the AWS_PROFILE environment variable) or the assume-role tool.

# Use the AWS credentials passed to the CI system and available as environment variables.
# These are the low-privilege credentials that automatically get rotated.
aws configure set aws_access_key_id ${AWS_ACCESS_KEY_ID}
aws configure set aws_secret_access_key ${AWS_SECRET_ACCESS_KEY}
aws configure set region "${AWS_REGION:-us-west-2}"

# Assume the desired IAM Role. Note how we pass the stack name in the --external-id parameter,
# as required to assume the role.
readonly CREDS_JSON=$(aws sts assume-role \
 --role-arn "${ARN_OF_IAM_ROLE_TO_ASSUME}" \
 --role-session-name "<useful description of the context, such as CI/CD job ID>" \
 --external-id "${TARGET_STACK}")

# The `aws sts assume-role` command just returns a JSON blob. So we now tease out the actual
# access key and set the corresponding environment variables.
export AWS_ACCESS_KEY_ID=$(echo "${CREDS_JSON}" | jq ".Credentials.AccessKeyId" --raw-output)
export AWS_SECRET_ACCESS_KEY=$(echo "${CREDS_JSON}" | jq ".Credentials.SecretAccessKey" --raw-output)
export AWS_SESSION_TOKEN=$(echo "${CREDS_JSON}" | jq ".Credentials.SessionToken" --raw-output)

# If everything worked correctly, then running the get-caller-identity command will refer to
# the IAM Role and not our IAM User.
echo "Assumed AWS identity:"
aws sts get-caller-identity

Storing Sensitive Data using Pulumi

As a developer, the most critical security threat is access to your cloud account since that’s ultimately where your or your customer’s data is stored. But beyond that, there are places where Pulumi stores sensitive data.

Pulumi goes to great lengths to safeguard your data. Here we review where Pulumi interacts with your sensitive data and what you can do to safeguard it better.

Secrets in Configuration

A Pulumi stack can have configuration data associated with it, which allows you to parameterize cloud resources. For example, a machine-size configuration key might determine which class of virtual machine to use. A dev stack might only need a "t2.small" but your production instance might need something more powerful.

Configuration data is stored in a file like Pulumi.website-production.yaml should be checked in along with the source code for a stack, so that builds and stack updates are reproducible.

However, what if those configuration settings contain secrets? Like you need to store an API key to use a 3rd party API.

Pulumi supports encrypting sensitive configuration data. You just need to add the --secret flag.

# Securely add an API key to the stack's configuration.
pulumi config set api-key "hunter2" --secret

For stacks hosted on the Pulumi Service, the default is that your configuration data is encrypted using a key specific to your stack. (So the ciphertext stored in the Pulumi.yaml file is safe to check into your source tree, since it cannot be copied/decrypted for another stack.)

Secrets in Checkpoint Files

Pulumi keeps track of your cloud resources in a something called a checkpoint file, and that too might contain sensitive information. For example, a Pulumi resource might have a "password" output property.

Pulumi has support to mark that resource output as “secret” and make sure that it is encrypted within the checkpoint file. (So if you were to look at the checkpoint file contents via pulumi stack export, you would not be able to recover the data.

Just like for secret configuration values, the default for stacks hosted on the Pulumi Service is to encrypt this data using a key that Pulumi manages and is specific to your stack.

Custom Secrets Providers

We at Pulumi take great care in safeguarding your data, especially configuration or checkpoint data that is marked as sensitive. However, you might feel more comfortable if your stack’s data were encrypted using a key that you controlled. (So even if the data stored in the Pulumi Service were available, it would be useless without your specific key.)

If that’s the case, then you can use a configurable secrets provider, and swap out the default “Pulumi Service managed” encryption scheme for your own. (And we won’t take it personally, promise.)

When you create a new stack using pulumi stack init, you can optionally specify a --secrets-provider flag. That will determine where and how secrets get managed on your stack.

For example, to use your own KMS key for encrypting data, you can pass the secrets provider "awskms://alias/ExampleAlias?region=us-east-1". The Pulumi command-line will work and behave the same. Except that whenever it needs to encrypt or decrypt some data, it will refer to the custom provider.

As you would expect, if you do use a custom secrets provider and lose access to your encryption key, then there is no way to recover the encrypted data stored on your stack.

For more information on custom secret providers, see Peace of Mind with Cloud Secret Providers or Managing Secrets with Pulumi.

Wrapping Up

Securely managing any sensitive data is challenging to get right, especially if there are many moving parts, such as when coordinating access between your AWS account, CI/CD provider, and your Pulumi stack.

In this blog series, we walked through the best practices in creating, securing, and managing access to an AWS account using IAM Users and Roles. We then reviewed the specifics of where and how Pulumi stores sensitive data, in case you want to take more control over your data.

If you have any other questions, corrections, or other ideas you’d like to discuss about Pulumi, Continuous Delivery, or security, please join the conversation over on the Pulumi Community Slack.

Managing AWS Credentials on CI/CD: Part 2

Chris Smith — Thu, 26 Mar 2020 00:00:00 +0000

This article is the second part of a series on best practices for securely managing AWS credentials on CI/CD. In this article, we go in-depth on providing AWS credentials securely to a 3rd party and introduce a Pulumi program to automate rotating access keys.

NOTE: These recommendations do not apply if you are running a CI/CD system within your AWS account, e.g., running a Jenkins server on EC2 or using AWS CodeDeploy. In those cases, please refer to AWS’s documentation for how to assume IAM Roles when running on an EC2 instance instead.

Provide IAM credentials to your CI/CD system

In the first post in our series, we created a dedicated IAM User to perform updates to AWS resources within your CI/CD system. The next step is to pass the AWS access keys for that user to your CI/CD system.

We need to take great caution. AWS’s documentation states, “Do not provide your access keys to a third party”.

Providing AWS access keys to any system is dangerous because of the risk that a bad actor could obtain those keys and do something nefarious. Even if your CI/CD service takes great care to protect your secrets, those AWS credentials could be inadvertently exposed in debugging output, system logs, or in some other way.

This is one of the main advantages of performing continuous deployment from within your AWS account. For example, running Jenkins on an EC2 instance you manage, or using the AWS CodeDeploy service. Because when performing a deployment from within an AWS compute environment, you can use built-in mechanisms to obtain credentials securely.

However, there are many reasons to use a hosted service for performing your CI/CD, such as developer productivity, ease of use, performance, or simply because you don’t want to recreate your existing deployment workflows.

Ultimately, it is essential to understand the risks involved and how to mitigate them.

Properly Storing Credentials

If you choose to provide your CI/CD with credentials, the most important thing is to mark them as secret. Your CI/CD provider typically has built-in support for handling “secure variables” or other sensitive information. As opposed to general, configuration data or environment variables.

User-supplied configuration values are typically write-only and only accessible by the CI/CD worker jobs at runtime. For example, Travis CI has encrypted environment variables or secure environment variables in CircleCI.

Please consult your CI/CD provider’s documentation for how to pass and store sensitive information appropriately.

Why not use a “secrets manager” service?

A common question when discussing is how to pass access keys to a CI/CD system securely:

Rather than giving your CI/CD provider AWS credentials, why not have your CI/CD system obtain credentials from a specialized “secrets manager” service?

In other words, if you choose not to trust your CI/CD system with this data, can you instead trust some other system dedicated for securely storing and retrieving sensitive information?

It sounds like a good idea on the surface but doesn’t seem to make your data any more secure.

Abstractly, the difference here is that the credentials are provided on-demand, rather than being available to the CI/CD job when it starts (and stored via the CI/CD provider). Instead, your CI/CD job would obtain credentials from the “secrets manager” only when needed.

There are some advantages to this approach, such as providing a clear audit trail for access and more control over the distribution of sensitive information.

However, the secrets provider system needs to be presented with some form of credentials. And those credentials need to be available to your CI/CD environment. So using a secrets manager leaves you in the same place you started, i.e., needing to provide sensitive data to your CI/CD provider.

Also, by adding a dependency on a secrets manager, you introduce additional risks. Not only do you need to be even more security-conscious about that secrets manager, but it also needs to be highly available. Any outage for that service would mean that you would be unable to perform deployments!

So it does not seem that using a secrets manager to dole out AWS credentials to your CI/CD system is a good practice to follow. Or, at the very least, makes some tradeoffs without fundamentally making your approach to CI/CD any more or less secure.

Instead, it is better to focus on other ways to reduce the risk if those AWS credentials do get exposed.

Automate Rotating and Revoking AWS Credentials

When providing credentials to a 3rd party, rather than hoping it will be 100% secure forever (which is impossible), we can make those credentials volatile. If we regularly invalidate and rotate the credentials supplied to the CI/CD system, we can dramatically reduce the impact of any accidental disclosure. Even if the IAM User’s credentials were leaked, by the time they were discovered and used, they would no longer be valid.

The AWS security blog describes how to rotate access keys for IAM Users, by using the following steps:

Create a second access key in addition to the one in use.
Update all your applications to use the new access key.
Change the state of the previous access key to inactive.
Verify everything is still working as expected.
Delete the inactive access key.

That all sounds simple enough, but it’s certainly tedious. And if you need to repeat the process across dozens, if not hundreds of different CI/CD pipelines, you need a better solution. Fortunately, Pulumi provides an excellent and extensible way for writing a serverless program to automate rotating credentials.

The next few sections describe a simple infrastructure application for automating AWS IAM credential rotation. You can see the full application on GitHub at chrsmith/pulumi-aws-travis-cicd-demo.

AWS Credential Rotator 9000

The affectionally titled AWS Credential Rotator 9000 is a simple, serverless Pulumi application for rotating AWS access keys.

It creates an AWS lambda function that’s triggered on a regular schedule, e.g., every 30 minutes, and performs the next step in the sequence for rotating access keys as outlined above.

First, it creates a new access key and pushes the new value out. On the next iteration, it marks the older access key as “inactive.” On the following iteration, the inactive key is deleted. The process repeats, generating a new key and removing the inactive key.

Periodically Invoking an AWS Lambda

The heart of the application is triggering it to execute on a fixed interval. Thankfully this is super-easy to do using Pulumi since it allows you to seamlessly blend your “cloud infrastructure” with “code” in a natural way. The user guide for Pulumi Crosswalk for AWS has more information on serverless eventing if you would like to learn more.

The following snippet is the core part of the credential rotator app. We define a function to handle the logic of key rotation in rotateIAMUserKeys. Then we create an AWS Lambda resource named lambda. Finally, the triggerSchedule resource invokes our lambda on a fixed schedule, thereby ensuring that the key rotation process goes on indefinitely. You can see the full code here.

async function rotateIAMUserKeys(iamUser: aws.iam.User, onNewCredentials: (key: string, secret: string) => Promise<void>) {
 ...
}

const lambda = new aws.lambda.CallbackFunction<aws.cloudwatch.EventRuleEvent, void>(
 "keyRotatorLambda",
 {
 callback: async (e) => {
 await rotateIAMUserKeys(userToRotate, async (newKey: string, newSecret: string) => {
 console.log("onNewCredentials callback called!");
 console.log(`A new AWS access key "${newKey}" has been created.`);
 });
 },

 role: lambdaRole,
 runtime: "nodejs10.x",
 });

const triggerSchedule = aws.cloudwatch.onSchedule(
 "keyRotatorScheduler", "rate(1 hour)", lambdaCallbackFn);

When writing reusable infrastructure components in Pulumi however, it is helpful to organize things into a custom resource.

For example, we can bundle together the AWS Lambda, CloudWatcn schedule, and the associated IAM policies into a single conceptual resource AccessKeyRotator. Bundling resources allows for the code reuse.

const rotator = new AccessKeyRotator("rotator", {
 interval: config.require("rate"),
 user: user,
 credentialPusher: demoTravisCIPusher,
})

Pushing Credentials

With the mechanics of updating an AWS access key out of the way, the next step is to notify dependent systems what the new access key should be. The key rotator app has a CredentialPusher abstraction to provide a pluggable way for you to send credentials to where they need to be. The example on GitHub only supports updating a Travis CI project (See credential-pusher-travis.ts.), but it could be easily extended to support other CI/CD systems.

The following snippet shows how the CredentialPusher is configured in the key rotator app. We load a Travis CI access token from the Pulumi stack’s configuration, and hard-code the specific set of projects and encrypted environment variables to store the new access key.

// A "credential pusher" is the component that pushes new AWS IAM credentials out to 3rd parties
// as the older ones get rotated. For demonstration purposes, this updates the Travis CI settings
// for the chrsmith/pulumi-aws-travis-cicd-demo repo. But you can imagine another implementation
// that pushes the new IAM credentials to GitLab CI, or updating multiple CI/CD pipelines.

const demoTravisCIPusher = new CredentialPusher(
 new TravisCIPusher(),
 {
 accessKey: config.require("travis-ci-token"),
 projects: [
 {
 project: "chrsmith/pulumi-aws-travis-cicd-demo",
 // In the Travis CI configuration for that GitHub repo, there are two
 // environment variables for storing the AWS credentials. So whenever the
 // AWS credentials get rotated, the job's configuration settings will be
 // updated to reflect the new values.
 accessKeyIDLocation: "AWS_ACCESS_KEY_ID",
 secretAccessKeyLocation: "AWS_SECRET_ACCESS_KEY",
 }
 ],
 });

Demo

To demonstrate the access keys rotation, we can examine the log files generated from AWS Lambda. These can be accessed from the command-line using the pulumi logs command.

Here’s a summary of the output for clarity:

 START RequestId: 9406913e-a9d0-46a4-b861-2efdee508b2b Version: $LATEST
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO IAM User has 2 keys:
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO - AKIASHIVKXX3QEQNZNX5 [Active] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO - AKIASHIVKXX3SA2K3ME7 [Inactive] Tue Mar 24 2020 09:37:03 GMT+0000 (Coordinated Universal Time)
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO Deleting older, inactive access key AKIASHIVKXX3SA2K3ME7 [Inactive]
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO Key rotation step complete.
 END RequestId: 9406913e-a9d0-46a4-b861-2efdee508b2b

 START RequestId: 05644e4a-81a4-4197-8ad7-fc3517998270 Version: $LATEST
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO IAM User has 1 keys:
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO - AKIASHIVKXX3QEQNZNX5 [Active] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Created new key key AKIASHIVKXX3YX4IXRVH
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Pushing out the new key to 3rd party services...
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Pushing new credentials to Travis CI project 'chrsmith/pulumi-aws-travis-cicd-demo'
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updating env var 'AWS_ACCESS_KEY_ID' (b246ab3b-c4cb-e76f-a6fc-50f4cbf451c0)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updated AWS access key ID. Got response code (200)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updating env var 'AWS_SECRET_ACCESS_KEY' (ba9ac4be-fbb3-4da9-c5b8-35a1afe9e02b)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updated AWS secret access key. Got response code (200)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Key rotation step complete.
 END RequestId: 05644e4a-81a4-4197-8ad7-fc3517998270

 START RequestId: ca204959-32a7-44a8-ba20-738d139542ba Version: $LATEST
 ca204959-32a7-44a8-ba20-738d139542ba INFO IAM User has 2 keys:
 ca204959-32a7-44a8-ba20-738d139542ba INFO - AKIASHIVKXX3YX4IXRVH [Active] Tue Mar 24 2020 15:37:03 GMT+0000 (Coordinated Universal Time)
 ca204959-32a7-44a8-ba20-738d139542ba INFO - AKIASHIVKXX3QEQNZNX5 [Active] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 ca204959-32a7-44a8-ba20-738d139542ba INFO Invalidating older access key AKIASHIVKXX3QEQNZNX5
 ca204959-32a7-44a8-ba20-738d139542ba INFO Key rotation step complete.
 END RequestId: ca204959-32a7-44a8-ba20-738d139542ba

 START RequestId: de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 Version: $LATEST
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO IAM User has 2 keys:
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO - AKIASHIVKXX3YX4IXRVH [Active] Tue Mar 24 2020 15:37:03 GMT+0000 (Coordinated Universal Time)
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO - AKIASHIVKXX3QEQNZNX5 [Inactive] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO Deleting older, inactive access key AKIASHIVKXX3QEQNZNX5 [Inactive]
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO Key rotation step complete.
 END RequestId: de753fb4-0720-4f4f-a7aa-ad6b9d4c8832

As you can see, the AWS credentials for the IAM User are automatically updated every few hours. And whenever a new access key is created, the value is pushed out to the impacted Travis CI projects automatically.

Wrapping Up

In this post, we covered some of the things to consider when providing AWS credentials to your CI/CD system. (In short, be cautious and follow best practices.)

We then showed how relatively easy it is to stand up a Pulumi infrastructure application for automatically rotating AWS access keys and updating your CI/CD system. By rotating credentials, you can limit the impact if the value is inadvertently disclosed.

At this point, we’ve now given access keys to a CI/CD system for a low-privilege AWS IAM User account. But we still can’t do anything with it. The IAM User whose credentials we have given to the CI/CD system doesn’t have access to your production AWS account.

In the next post, we’ll go into the details about IAM Roles, and they can be used to securely and temporarily gain access to additional resources. This is how our low-privilege IAM User can access needed to update production data for your CI/CD pipelines.

Pulumi Blog: Secrets

Introducing ESC Secret Rotation Webhooks

Introducing secret rotation webhooks

How to configure

Pulumi Cloud Console

Pulumi Service Provider

Pulumi CLI

Get started

Introducing ESC Connect: Integrate Any Secret Source with Pulumi ESC

Building an adapter

Automated rotation

Try it out

Deletion Protection for Pulumi ESC Environments

How it works

Managing deletion protection

When to use deletion protection

Permissions

Getting 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

Bring Your Own Keys With Pulumi ESC

Why Customer-Managed Keys?

How It Works

Available Today

Share Your Feedback

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 Automated Database Credential Rotation for PostgreSQL and MySQL in Pulumi ESC

The Persistent Challenge of Static Database Secrets

Introducing ESC Rotated Secrets for Databases

How to Set Up and Use Rotation for AWS RDS PostgreSQL running in VPC

What’s Next?

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

Why Every Cloud Engineer Needs Pulumi ESC for Secrets Management

In this article:

The Challenge of Secrets Management in Modern Cloud Environments

What is Pulumi ESC?

Key Features of Pulumi ESC

1. Seamless Integration with External Platforms

2. Dynamic Secrets Synchronization with ESO

3. Safely Roll Back to a Previous Version

4. Secure by Design

5. Automated Rotation and Expiry

6. Configuration-as-Code, Automation, and Integration Everywhere

7. Dev Tools Integrations

8. Infrastructure Tools Integrations

Why Cloud Engineers Need Pulumi ESC

Enhanced Security and Compliance

Streamlined Multi-Cloud Management

Simplified Kubernetes Secrets

Zero Downtime Through Automation

Developer-Friendly Workflows

Kubernetes Secrets Management

Using Pulumi ESC with External Secrets Operator

Using Pulumi ESC with Secrets Store CSI Driver

The Future of Secrets Management with Pulumi ESC

Next Steps to Secure Your Secrets

Faster Secrets in Pulumi IaC

Secrets Management in Pulumi

Performance Challenges with Secrets

Our Performance Improvements

Measurable Performance Gains

Getting Started

Conclusion

Beyond Stack Secrets: Pulumi ESC

Get Started Today

Announcing the Pulumi ESC GitHub Action