Pulumi Blog: Rotation

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.

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!

Pulumi Blog: Rotation

Introducing ESC Secret Rotation Webhooks

Introducing secret rotation webhooks

How to configure

Pulumi Cloud Console

Pulumi Service Provider

Pulumi CLI

Get started

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