Policy Packs Can Now Access Pulumi ESC Environments

Source: Pulumi Blog

The problem

Pulumi policy packs let you enforce rules across your infrastructure, but some policies need more than just the resource inputs they evaluate. Examples include:

• A policy that validates resources against an external compliance API needs an API token.
• A cost‑enforcement policy might require different spending thresholds for development and production environments.
• An access‑control policy may need to reference an internal service registry.

Until now, these values had to be hard‑coded in your policy group configuration or managed through a separate process, leading to:

• Security risk: credentials stored in plain text.
• Operational burden: updating a credential required touching every policy group that used it.
• No environment separation: the same values applied everywhere, with no way to vary configuration across environments.

What’s new

Policy packs can now reference Pulumi ESC environments, just like stacks already do. When you attach an ESC environment to a policy pack in a policy group, the values from that environment are available to your policies at runtime—whether you’re running preventative or audit policies.

This enables policy packs to use ESC for:

• Secrets: API tokens, service credentials, and other sensitive values managed through ESC’s secrets management, including dynamic credentials from providers like AWS, Azure, and GCP.
• Configuration: Environment‑specific thresholds, allowed regions, service allowlists, and other policy parameters that vary across environments.

How it works

You configure ESC environment references on a policy pack within a policy group. At runtime, the values from those environments are resolved and made available to your policies through the policy pack’s configuration.

Example ESC environment

values:
  compliance:
    apiToken:
      fn::secret: xxxxxxxxxxxxxxxx
    costThreshold: 5000

policyConfig:
  cost-compliance:
    maxMonthlyCost: ${compliance.costThreshold}
    apiEndpoint: https://compliance.example.com
    apiToken: ${compliance.apiToken}

The policyConfig property works like pulumiConfig for stacks. Values nested under each policy name are provided as configuration to that policy at runtime. Secrets remain encrypted and are only decrypted when the environment is resolved.

You can also use the environmentVariables property to inject values as environment variables into the policy runtime, following the same pattern as stack environment variables.

Example: compliance API validation

Consider a policy that validates every new resource against an external compliance API before it can be provisioned. The API requires an authentication token and returns whether the resource configuration meets your organization’s compliance standards.

Before:

• The API token lived in the policy group configuration in plain text.
• Rotating the token meant updating every policy group.
• No audit trail for credential access.
• No way to use different API endpoints for staging and production.

After:

• The API token lives in an ESC environment.
• Centralized rotation: update the token once; all referencing policy groups pick up the change.
• Access controls: ESC’s role‑based access controls govern who can view or modify the credential.
• Audit trail: every access to the environment is logged.
• Environment separation: use different ESC environments for staging and production, allowing distinct compliance endpoints.

Get started

1. Create an ESC environment containing your policy configuration and secrets.
2. Attach the environment to a policy pack in your policy group via the Pulumi Cloud console.
3. Update your policies to read from the configuration values provided by the environment.

To learn more

• policyConfig reference
• Pulumi ESC documentation
• Policy packs documentation
• Get started with Pulumi ESC