Doppler login and secrets providers blog post

content/blog/esc-doppler-providers-launch/index.md

@@ -0,0 +1,117 @@
+---
+title: "Announcing Doppler Providers for Pulumi ESC: Dynamic Login and Dynamic Secrets" 
+date: 2025-06-26
+allow_long_title: true
+meta_desc: "Pulumi ESC adds Doppler providers for dynamic OIDC login and centralized secret fetching, enhancing security and simplifying management."
+meta_image: meta.png 
+authors:
+  - robert-harris
+tags:
+  - esc
+  - secrets
+  - doppler 
+  - features
+  - configuration-management
+  - dynamic-secrets
+  - oidc
+---
+
+We are excited to announce support for [Doppler](https://doppler.com/) within [Pulumi ESC](/product/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.
+
+<!--more-->
+
+This release introduces two distinct dynamic providers for Doppler, each designed to improve security and streamline your workflows: 
+
+*   **[`doppler-login`](/docs/esc/integrations/dynamic-login-credentials/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`](/docs/esc/integrations/dynamic-secrets/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](/docs/esc/integrations/dynamic-secrets/aws-secrets/), [Azure](/docs/esc/integrations/dynamic-secrets/azure-secrets/), [GCP](/docs/esc/integrations/dynamic-secrets/gcp-secrets/)), and other secret managers ([Infisical](/docs/esc/integrations/dynamic-secrets/infisical-secrets/), [Vault](/docs/esc/integrations/dynamic-secrets/vault-secrets/), [1Password](/docs/esc/integrations/dynamic-secrets/1password-secrets/)). 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](/docs/esc/development/languages-sdks/), [ESC CLI](/docs/esc/cli/), [Kubernetes External Secrets Operator](/docs/esc/integrations/kubernetes/external-secrets-operator/), [CSI Driver](/docs/esc/integrations/kubernetes/secret-store-csi-driver/), or sync them to various platforms where they are needed such as [GitHub Secrets](https://github.com/pulumi/esc-examples/tree/main/sync/github-secrets), [AWS Secrets Manager](https://github.com/pulumi/esc-examples/tree/main/sync/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](/docs/esc/environments/configuring-oidc/doppler/). 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**.
+
+### How to Use the doppler-login Provider (Dynamic Authentication)
+
+1. Create a Pulumi ESC environment (e.g., `pulumi-org/doppler-auth/oidc-login`) with the following environment definition and update the `identityId`.
+
+```yaml
+# 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}
+```
+
+2. Save the environment.
+3. Validate the environment by clicking on Open in the Pulumi Cloud console, or running `esc open pulumi-org/doppler-auth/oidc-login` in your CLI. The output will include the `doppler.login.accessToken`.
+4. Usage Example: Run Doppler CLI commands dynamically:
+```bash
+esc 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!
+
+1.  Create an ESC environment where you need the secrets (e.g., `pulumi-org/my-app/dev`).
+2.  **Import** the dynamic login environment (if using OIDC for authentication, which is recommended). This makes the temporary Doppler token available.
+3.  Configure the `doppler-secrets` provider, referencing the imported login details. See example below. 
+4.  Specify the secrets to fetch using the `get` block. Replace placeholders.
+
+```yaml
+# 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}
+```
+5.  Save the environment.
+6.  Validate the environment by clicking on Open in the Pulumi Cloud console, or running `esc 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`.
+7.  **Usage Example:** Run an application that needs these secrets:
+    ```bash
+    esc 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](/docs/esc/integrations/dynamic-login-credentials/doppler-login/), [doppler-secrets](/docs/esc/integrations/dynamic-secrets/doppler-secrets/) for detailed configuration options, check out the broader [Pulumi ESC Documentation](/docs/esc/), and share your feedback or ask questions in the [Pulumi Community Slack](https://slack.pulumi.com/).

content/blog/esc-env-run-aws/index.md

@@ -141,7 +141,7 @@ values:
 
 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](https://www.pulumi.com/docs/pulumi-cloud/esc/providers/aws-login/#example) as well as the documentation for [projecting environment variables](https://www.pulumi.com/docs/pulumi-cloud/esc/environments/#projecting-environment-variables).
 
-Scroll to the bottom of the page and click **Save**.
+Click **Save**.
 
 {{< video title="Adding configuration to Pulumi ESC environment" src="https://www.pulumi.com/uploads/add-environment-config.mp4" autoplay="true" loop="true" >}}
 

content/docs/esc/environments/configuring-oidc/_index.md

@@ -37,6 +37,7 @@ To configure OIDC for your cloud provider, refer to one of our guides:
 
 * [Configuring OIDC for AWS](/docs/esc/environments/configuring-oidc/aws/)
 * [Configuring OIDC for Azure](/docs/esc/environments/configuring-oidc/azure/)
+* [Configuring OIDC for Doppler](/docs/esc/environments/configuring-oidc/doppler/)
 * [Configuring OIDC for Google Cloud](/docs/esc/environments/configuring-oidc/gcp/)
 * [Configuring OIDC for Infisical](/docs/esc/environments/configuring-oidc/infisical/)
 * [Configuring OIDC for Vault](/docs/esc/environments/configuring-oidc/vault/)

content/docs/esc/environments/configuring-oidc/aws.md

@@ -98,7 +98,7 @@ To configure OIDC for Pulumi ESC, create a new environment in the [Pulumi Consol
     ```
 
 6. Replace `<your-oidc-iam-role-arn>` with the value from the previous steps.
-7. Scroll to the bottom of the page and click **Save**.
+7. Click **Save**.
 
 You can validate that your configuration is working by running either of the following:
 

content/docs/esc/environments/configuring-oidc/azure.md

@@ -8,7 +8,7 @@ menu:
   esc:
     name: Azure
     parent: esc-configuring-oidc
-    weight: 1
+    weight: 2
 ---
 
 This document outlines the steps required to configure Pulumi to use OpenID Connect to authenticate with Azure. OIDC in Azure uses [workload identity federation](https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation) to access Azure resources via a Microsoft Entra App. Access to the temporary credentials is authorized using federated credentials that validate the contents of the OIDC token issued by the Pulumi Cloud.
@@ -98,7 +98,7 @@ To configure OIDC for Pulumi ESC, create a new environment in the [Pulumi Consol
     ```
 
 6. Replace `<your-client-id>`, `<your-tenant-id>`, and `<your-subscription-id>` with the values from the previous steps.
-7. Scroll to the bottom of the page and click **Save**.
+7. Click **Save**.
 
 You can validate that your configuration is working by running either of the following:
 

content/docs/esc/environments/configuring-oidc/doppler.md

@@ -0,0 +1,178 @@
+---
+title_tag: Configure OpenID Connect for Doppler | Pulumi ESC
+meta_desc: This page describes how to configure OIDC token exchange in Doppler for use with Pulumi
+title: Doppler
+h1: Configuring OpenID Connect for Doppler
+meta_image: /images/docs/meta-images/docs-meta.png
+menu:
+  esc:
+    name: Doppler
+    parent: esc-configuring-oidc
+    weight: 4
+---
+
+This document outlines the steps required to configure Pulumi to use OpenID Connect to authenticate with Doppler. OIDC
+in Doppler uses [service account identities](https://docs.doppler.com/docs/service-account-identities) to access
+Doppler resources. Access to the temporary credentials is authorized using identities that validate the contents of
+the OIDC token issued by the Pulumi Cloud.
+
+## Prerequisites
+
+* Your Doppler workplace must be on the Team or Enterprise plan in order to use service account identities.
+* You must be an admin of your Doppler workplace to create and configure service account identities.
+
+{{< notes type="warning" >}}
+Please note that this guide provides step-by-step instructions based on the official provider documentation which is
+subject to change. For the most current and precise information, always refer to
+the [official Doppler documentation](https://docs.doppler.com/docs/service-account-identities).
+{{< /notes >}}
+
+## Creating a Service Account
+
+To create a new service account, in the navigation pane of the [Doppler dashboard](https://dashboard.doppler.com):
+
+1. Select **Team**, **Service Accounts** and then click **New Service Account**.
+2. Provide a name for your service account (ex: `pulumi-esc-oidc-app`).
+3. Click **Create**.
+4. Select a **Role** for the service account or manually grant project access.
+
+## Add an Identity (OIDC Authentication)
+
+To add an identity to a service account:
+
+1. Navigate to the service account from **Team**, **Service Accounts**
+2. Click **New Identity**.
+3. Fill in the form fields as follows:
+    * **Discovery URL:** `https://api.pulumi.com/oidc`.
+    * **Audience:** This is different between Pulumi deployments and ESC. For Deployments this is only the name of your Pulumi organization. For ESC this is the name of your Pulumi organization prefixed with `doppler:` (e.g. `doppler:{org}`).
+    * **Subject:** `pulumi:environments:org:<your-pulumi-org>:env:<your-project>/<your-environment>` (see more examples at the end of this section).
+4. Click **Create Identity**.
+{{< notes type="info" >}}
+For environments in the `default` project the audience will use just the Pulumi organization name. This is to
+prevent regressions for legacy environments.
+{{< /notes >}}
+
+After the Identity has been created, take note of the Identity ID. This value will be necessary when enabling OIDC for your service.
+
+## Configure ESC for OIDC
+
+To configure OIDC for Pulumi ESC, create a new environment in the [Pulumi Console](https://app.pulumi.com/). Make sure
+that you have the correct organization selected in the left-hand navigation menu. Then:
+
+1. Click the **Environments** link.
+2. Click the **Create environment** button.
+3. Provide a project to create your new environment in and a name for your environment.
+    * This should be the same as the identifier provided in the subject claim of your federated credentials.
+4. Click the  **Create environment** button.
+5. You will be presented with a split-pane view. Delete the default placeholder content in the editor and replace it
+   with the following code:
+
+    ```yaml
+    values:
+      doppler:
+        login:
+          fn::open::doppler-login:
+            oidc:
+              identityId: <your-identity-id>
+      environmentVariables:
+        DOPPLER_TOKEN: ${doppler.login.accessToken}
+    ```
+
+6. Replace `<your-identity-id>` with the value from the previous steps.
+7. Click **Save**.
+
+You can validate that your configuration is working by running either of the following:
+
+* `esc open <your-org>/<your-project>/<your-environment>` command of the [ESC CLI](/docs/esc-cli/)
+* `pulumi env open <your-org>/<your-project>/<your-environment>` command of the [Pulumi CLI](/docs/install/)
+
+Make sure to replace `<your-org>`, `<your-project>`, and `<your-environment>` with the values of your Pulumi
+organization, project, and environment file respectively. You should see output similar to the following:
+
+```json
+{
+  "doppler": {
+    "login": {
+      "accessToken": "dp.said.XXX..."
+    }
+  },
+  "environmentVariables": {
+    "DOPPLER_TOKEN": "dp.said.XXX..."
+  }
+}
+```
+
+To learn more about how to set up and use the various providers in Pulumi ESC, please refer to
+the [relevant Pulumi documentation](/docs/esc/integrations/)
+
+## Subject claim customization
+
+You can [customize](/docs/esc/environments/customizing-oidc-claims/) the subject claim in the OIDC token to control
+which Pulumi environments or users are allowed to assume a given identity. This allows for more granular access control
+than the default organization-level permissions.
+
+This is done by configuring the `subjectAttributes` setting. It expects an array of keys to include in it:
+
+* `rootEnvironment.name`: the name of the environment that is opened first. This root environment in turn opens other
+  imported environments
+* `currentEnvironment.name`: the full name (including the project) of the environment where the ESC login provider and
+  `subjectAttributes` are defined
+* `pulumi.user.login`: the login identifier of the user opening the environment
+* `pulumi.organization.login`: the login identifier of the organization
+
+The subject always contains the following prefix `pulumi:environments:pulumi.organization.login:{ORGANIZATION_NAME}` and
+every key configured will be appended to this prefix. For example, consider the following environment:
+
+```yaml
+values:
+  doppler:
+    login:
+      fn::open::doppler-login:
+        oidc:
+          identityId: <your-identity-id>
+          subjectAttributes:
+            - currentEnvironment.name
+            - pulumi.user.login
+```
+
+The subject will be
+`pulumi:environments:pulumi.organization.login:contoso:currentEnvironment.name:project/development:pulumi.user.login:userLogin`.
+Note how the keys and values are appended along with the prefix.
+
+{{< notes type="warning" >}}
+
+If not customized, the subject claim has the following format by default:
+
+`pulumi:environments:org:<organization name>:env:<project name>/<environment name>`
+
+{{< /notes >}}
+
+{{< notes type="warning" >}}
+
+For environments within the legacy `default` project, the project will **not** be present in the subject to preserve
+backwards compatibility. The format of the subject claim when `subjectAttributes` are not set is
+`pulumi:environments:org:<organization name>:env:<environment name>`. If `currentEnvironment.name` is used as a custom
+subject attribute it will resolve to only the environment name (e.g.
+`pulumi:environments:pulumi.organization.login:contoso:currentEnvironment.name:development:pulumi.user.login:personA`).
+Due to this it is recommended to move your environments out of the `default` project for best security practices.
+
+{{< /notes >}}
+
+## Subject claim example
+
+Here is an example of a valid, not customized subject claim for the `project/development` environment of the `contoso`
+organization:
+
+* `pulumi:environments:org:contoso:env:project/development`
+
+{{< notes type="warning" >}}
+
+If you are integrating Pulumi ESC with Pulumi IaC, the default subject identifier of the ESC environment will not work
+at this time. There is a [known issue](https://github.com/pulumi/pulumi/issues/14509) with the subject identifier's
+value sent to Doppler from Pulumi.
+
+Use 'subjectAttributes' to customize the subject identifier to work with Pulumi IaC. Alternatively, you can use this
+syntax: `pulumi:environments:org:contoso:env:<yaml>` when configuring the subject claim in your cloud provider account.
+Make sure to replace `contoso` with the name of your Pulumi organization and use the literal value of `<yaml>` as shown.
+
+{{< /notes >}}