Pulumi Blog: Policy as code

Enforce ISO 27001 Across Your AWS Infrastructure

Dan Biwer — Tue, 30 Jun 2026 00:00:00 +0000

ISO/IEC 27001 is the international standard for information security management. Proving you meet it usually means months of mapping abstract security controls to concrete cloud configuration, then authoring custom checks one resource at a time. We’re changing that.

Today we’re shipping a pre-built ISO/IEC 27001:2022 policy pack for AWS, live now in Pulumi Cloud as iso-27001-aws. It encodes the standard’s security expectations as 238 ready-to-run policies, so you can align your AWS estate to ISO 27001 in minutes, not months.

Why ISO 27001 matters

For many companies, ISO 27001 is what stands between them and a customer or a market. The sooner you can reach a certifiable state and prove you stay there, the less compliance slows the business down. The pack collapses months of policy work into something you run continuously, so security keeps pace with growth instead of blocking it.

How the pack maps to ISO 27001

The hard part of ISO 27001 has always been translation: its controls are written in the language of governance and risk management, not in the language of AWS resources. Every team has had to interpret each control and decide what it means for an S3 bucket or an RDS instance.

The pack does that interpretation for you. Its 238 policies are aligned to the relevant ISO 27001 controls, so each result connects back to the standard instead of leaving you to map it yourself. You can browse the full pack in the pack reference.

Audit and prevent

The same pack works two ways, so you can both reach compliance and stay there:

Audit. Scan your existing AWS estate against the pack, including resources that Pulumi doesn’t manage. You get an honest baseline of where you stand against ISO 27001 today, with every finding tied back to the control it affects.
Prevent. Run the same pack as a preventative policy during pulumi up to block non-compliant resources before they’re ever created. New infrastructure is born aligned to the standard.

Audit gets you clean. Preventative policies keep you clean.

A growing library of pre-built packs

ISO 27001 joins a growing library of pre-built packs for AWS, each authored and maintained by Pulumi and kept current with its source standard:

ISO/IEC 27001:2022
CIS Controls v8.1
NIST SP 800-53 Rev. 5
PCI DSS v4.0
HITRUST CSF v11.5
Pulumi Best Practices

Adopting any pack means you skip the authoring work entirely, inherit framework mappings maintained by Pulumi, and apply a consistent baseline across every stack and account.

Get started today

The ISO 27001 pack is available now to every Pulumi Cloud user:

Browse the pack reference to see all 238 policies and how they map to the standard’s controls.
Explore the full pre-built packs index.
Follow the get-started guide to run your first audit.

Try Pulumi policies

Ready to align your AWS infrastructure to ISO 27001? Sign up for Pulumi Cloud and run the pack against your estate, or read the policy get-started guide to dig in.

Need a compliance pack for a framework that isn’t listed here? Open a request in pulumi/pulumi-cloud-requests or come tell us in the community Slack. We’re listening.

Policy Packs Can Now Access Pulumi ESC Environments

Dan Biwer — Thu, 23 Apr 2026 00:00:00 +0000

Policy authors who need external credentials or environment-specific configuration have had to hardcode values or manage them outside of Pulumi. Policy packs can now reference Pulumi ESC environments, bringing centralized secrets and configuration management to your policies.

The problem

Pulumi policy packs let you enforce rules across your infrastructure, but some policies need more than just the resource inputs they evaluate. A policy that validates resources against an external compliance API needs an API token. A cost-enforcement policy might need different spending thresholds for development and production environments. An access-control policy might need to reference an internal service registry.

Until now, these values had to be hardcoded in your policy group configuration or managed through a separate process entirely. This created several problems:

Security risk: Credentials stored in plain text in policy group config
Operational burden: Updating a credential meant 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 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 means your policy packs can 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.

Here’s an example ESC environment that provides configuration to a compliance policy pack:

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 just like pulumiConfig does for stacks. Values nested under each policy name are made available 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. There was no audit trail for who accessed the credential, and no way to use different API endpoints for staging and production compliance checks.

After, the API token lives in an ESC environment. You get:

Centralized rotation: Update the token in one place and every policy group that references the environment picks 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 different policy groups, so staging policies validate against a staging compliance endpoint while production policies use the production endpoint

Get started

To start using ESC environments with your policy packs:

Create an ESC environment with your policy configuration and secrets
Attach the environment to a policy pack in your policy group through the Pulumi Cloud console
Update your policies to read from the configuration values provided by the environment

To learn more:

Introducing the pulumi policy analyze Command for Existing Stacks

Fraser Waters — Fri, 03 Apr 2026 00:00:00 +0000

You can now run policy packs against your existing stack state without running your Pulumi program or making provider calls. The new pulumi policy analyze command evaluates your current infrastructure against local policy packs directly, turning policy validation into a fast, repeatable check.

Why this command matters

Policy authoring and policy updates usually involve an iteration loop:

Make a policy change.
Run a policy check.
Inspect violations or remediations.
Repeat until the policy behavior matches intent.

Before this command, that loop often depended on pulumi preview or pulumi up, which can be heavier than you need when your goal is validating policy logic against known state.

With pulumi policy analyze, you can evaluate your current stack state directly and quickly.

Basic usage

At minimum, provide a policy pack path and optionally a stack:

pulumi policy analyze \
 --policy-pack ./policy-pack \
 --stack dev

You can also pass a config file for each policy pack:

pulumi policy analyze \
 --policy-pack ./policy-pack \
 --policy-pack-config ./policy-config.dev.json \
 --stack dev

If any mandatory policy violations are found, the command exits non-zero.

If remediation policies fire, those changes are reported in output, but stack state is not modified.

Testing new policy packs as a developer

For policy pack development, this command is useful as a tight local feedback loop:

Pick a representative stack (dev, staging, or a fixture stack).
Run pulumi policy analyze against that stack after each policy change.
Use the output to verify mandatory, advisory, and remediation behavior.
Repeat before publishing the policy pack or attaching it to broader policy groups.

Two output modes are especially useful:

--diff for a concise, human-readable view while iterating locally.
--json for structured output that can be consumed in scripts and CI.

Using it in AI and agent workflows

This command is also a good primitive for AI-assisted policy workflows.

Because pulumi policy analyze can emit JSON and a clear process exit code, agents can use it for deterministic policy evaluation steps:

Propose or edit policy rules.
Run pulumi policy analyze --json against target stacks.
Parse violations and remediation signals.
Suggest policy fixes, config adjustments, or targeted infrastructure changes.
Re-run analysis until mandatory violations are resolved.

For example, an agent tasked with fixing a policy violation can run pulumi policy analyze --json to get a structured list of violations, identify which resources are non-compliant, generate targeted infrastructure changes, then re-run analysis to confirm the violations are resolved, all without triggering a full preview on each iteration. The same loop works for policy authoring: an agent can propose a new policy rule, test it against several representative stacks, and surface unintended violations before the rule is published.

This works well for automation because the command doesn’t execute your Pulumi program or make provider calls, so there are no side effects or runtime variance between runs. The JSON output and non-zero exit code on failure give agents a clear pass/fail contract to build on.

Try it out

pulumi policy analyze is available in Pulumi v3.229.0.

If you are authoring or tuning policy packs, start by running this command against a known stack in your environment. It is a quick way to validate policy behavior before rollout.

For implementation details, see the merged PR: pulumi/pulumi#22250.

Get started with policy as code

From Kubernetes Gatekeeper to Full-Stack Governance with OPA

Levi Blackstone — Thu, 19 Mar 2026 00:00:00 +0000

Pulumi’s OPA (Open Policy Agent) support is now stable. The v1.1.0 release of pulumi-policy-opa makes OPA/Rego a first-class policy language for Pulumi with full feature parity alongside the native TypeScript and Python policy SDKs. Write Rego policies that validate any resource Pulumi manages, across AWS, Azure, GCP, Kubernetes, and the rest of the provider ecosystem. If you already have Kubernetes Gatekeeper constraint templates, a new compatibility mode lets you drop those .rego files directly into a Pulumi policy pack and enforce them against your Kubernetes resources without modification.

What’s in the stable release

OPA/Rego is now fully supported as a policy language for Pulumi Insights, with the same capabilities as the TypeScript and Python SDKs:

Resource and stack-level policies: Validate individual resources with deny and warn rules, or evaluate your entire stack at once with stack_deny and stack_warn for cross-resource checks like relationship validation and resource count limits.
Enforcement levels: Control how violations are handled. mandatory blocks deployments, advisory surfaces warnings, and disabled turns rules off without removing them. Enforcement levels can be overridden per policy without modifying Rego source.
Policy configuration: Pass custom parameters to policies via configuration files, with optional JSON schema validation. Configuration values are accessible in Rego as data.config.<policy_name>.<key>.
OPA metadata annotations: Use standard OPA # METADATA comments to provide titles, descriptions, and messages for your policies. These populate the policy metadata displayed in Pulumi Cloud.
Preventative and audit evaluation: OPA policies work with both preventative enforcement during pulumi up and audit policy scans for continuous compliance monitoring.

You can choose whichever language best fits your team. Organizations already using OPA across their toolchain can standardize on Rego for Pulumi policies, while teams preferring TypeScript or Python can continue to use those. All three languages work side by side in the same policy groups.

Kubernetes Gatekeeper compatibility

The headline feature of this release is native support for Kubernetes Gatekeeper constraint template rules. If you’re running Gatekeeper as an admission controller in your clusters, you likely have a library of .rego policies that enforce security and operational standards at admission time. With v1.1.0, those same rules can now run as Pulumi policies, catching violations during pulumi preview before resources ever reach the cluster.

To enable Gatekeeper compatibility, set inputFormat: kubernetes-admission in your PulumiPolicy.yaml:

description: Kubernetes Gatekeeper Policy Pack
runtime: opa
inputFormat: kubernetes-admission

With this setting, Pulumi automatically wraps Kubernetes resources in the Gatekeeper AdmissionReview structure (input.review.object, input.review.kind, etc.), so your existing rules work without modification. Non-Kubernetes resources are silently skipped.

Here’s an example that reuses standard Gatekeeper-style rules, requiring an app label and prohibiting the latest image tag:

package gatekeeper

import rego.v1

# METADATA
# title: Require App Label
# description: All Kubernetes resources must have an "app" label.
violation contains {"msg": msg} if {
 not input.review.object.metadata.labels["app"]
 msg := sprintf("%s '%s' is missing required label: app",
 [input.review.kind.kind, input.review.name])
}

# METADATA
# title: Disallow Latest Tag
# description: Container images must not use the "latest" tag.
deny contains msg if {
 container := input.review.object.spec.template.spec.containers[_]
 endswith(container.image, ":latest")
 msg := sprintf("container '%s' uses the 'latest' tag -- pin to a specific version",
 [container.name])
}

These rules are identical to what you’d write for Gatekeeper. Both rule head formats are supported and can coexist: the violation[{"msg": msg}] map format and the deny[msg] string format. Per-policy configuration via input.parameters also works as expected. You can take a .rego file from your Gatekeeper constraint templates, drop it into a Pulumi policy pack, and publish it to Pulumi Cloud to enforce automatically across your stacks.

This shifts policy enforcement left. Instead of waiting for the Kubernetes API server to reject a resource at admission time, you catch the violation during pulumi preview, before anything is deployed.

Walkthrough: Reusing policies from the gatekeeper-library

The OPA Gatekeeper Library is a community-maintained collection of constraint templates covering common Kubernetes guardrails like pod security, image provenance, and resource limits. You can use these policies directly with Pulumi. Here’s an end-to-end example using the allowedrepos policy to restrict which container image registries your deployments can use.

Create a new Kubernetes OPA policy pack:
```
pulumi policy new kubernetes-opa
```

Copy the Rego source from gatekeeper-library into your policy pack as allowedrepos.rego. No modifications are needed:

package k8sallowedrepos

violation[{"msg": msg}] {
 container := input.review.object.spec.containers[_]
 not strings.any_prefix_match(container.image, input.parameters.repos)
 msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v",
 [container.name, container.image, input.parameters.repos])
}

violation[{"msg": msg}] {
 container := input.review.object.spec.initContainers[_]
 not strings.any_prefix_match(container.image, input.parameters.repos)
 msg := sprintf("initContainer <%v> has an invalid image repo <%v>, allowed repos are %v",
 [container.name, container.image, input.parameters.repos])
}

violation[{"msg": msg}] {
 container := input.review.object.spec.ephemeralContainers[_]
 not strings.any_prefix_match(container.image, input.parameters.repos)
 msg := sprintf("ephemeralContainer <%v> has an invalid image repo <%v>, allowed repos are %v",
 [container.name, container.image, input.parameters.repos])
}

Verify that your PulumiPolicy.yaml has Gatekeeper compatibility enabled:

description: Kubernetes Gatekeeper Policy Pack
runtime: opa
inputFormat: kubernetes-admission

Configure the allowed registries. Create a policy-config.json file to pass the repos parameter:

{
 "k8sallowedrepos": {
 "repos": ["gcr.io/my-company/", "docker.io/library/"]
 }
}

Test the policy locally against a stack:
```
pulumi preview --policy-pack . --policy-pack-config policy-config.json
```
Any Kubernetes deployment using an image outside the allowed registries will produce a violation at preview time, before it reaches the cluster.
Publish the pack and add it to a policy group to enforce it across your organization:
```
pulumi policy publish
```

The same approach works for any policy in the gatekeeper-library: containerlimits, requiredlabels, disallowedtags, and others. Copy the Rego, configure parameters, and publish.

Part of the Pulumi Insights governance story

OPA policy support is part of the broader Pulumi Insights governance platform. Insights gives you visibility and compliance across your entire cloud footprint, and OPA policies plug directly into that:

Audit policy scans continuously evaluate OPA policies against your Pulumi stacks and discovered cloud resources, providing a compliance baseline without redeploying anything.
Self-hosted execution lets you run policy evaluations on your own infrastructure using customer-managed workflow runners, keeping credentials and data within your network.
Pre-built compliance packs for CIS, NIST, PCI DSS, and other frameworks are available alongside your custom OPA policies in the same policy groups.

Whether you’re enforcing policy at deployment time, scanning existing infrastructure for drift, or running continuous compliance checks, OPA policies are a native participant.

Frequently asked questions

Do I need to modify my existing Gatekeeper `.rego` files?

No. Set inputFormat: kubernetes-admission in your PulumiPolicy.yaml and your existing Gatekeeper constraint template rules work as-is. Pulumi handles the AdmissionReview wrapping automatically.

What happens with non-Kubernetes resources?

When using inputFormat: kubernetes-admission, non-Kubernetes resources are silently skipped during evaluation. Your Gatekeeper rules only run against Kubernetes resources.

Do I need OPA installed locally?

No. The pulumi-policy-opa analyzer plugin embeds the OPA evaluation engine and is installed automatically by the Pulumi CLI (v3.227.0+). The standalone OPA CLI is only needed if you want to run opa test against your policies independently.

When should I use OPA vs. TypeScript or Python for policies?

If your team already writes Rego for other tools like Gatekeeper, writing Pulumi policies in Rego keeps your policy language consistent. If your team is more comfortable with general-purpose languages or needs auto-remediation, use the TypeScript or Python SDKs.

Gatekeeper constraint templates can be reused directly via the kubernetes-admission input format, but other OPA integrations use different input structures, so those policies would need to be adapted to Pulumi’s resource model. All three languages work together in the same policy groups.

Get started

Templates are available for kubernetes-opa, aws-opa, azure-opa, and gcp-opa via pulumi policy new. For more details, see the policy authoring guide and the Policy as Code overview.

Get started with OPA policies

github.com/pulumi/pulumi-policy-opa

Run Pulumi Insights on Your Own Infrastructure

Levi Blackstone — Mon, 02 Mar 2026 00:06:00 -0700

Pulumi Insights gives you visibility and governance across your entire cloud footprint: discovery scans catalog every resource in your cloud accounts, and policy evaluations continuously enforce compliance against those resources. Until now, Insights workflows ran exclusively on Pulumi-hosted infrastructure. That works well for many teams, but enterprises with strict data residency requirements, private network constraints, or regulatory obligations need to run this work in their own environments. Today, Pulumi Insights supports customer-managed workflow runners for both SaaS Pulumi Cloud and self-hosted Pulumi Cloud installations.

Insights at a glance

Insights provides two complementary capabilities that together form a governance lifecycle for your cloud infrastructure.

Discovery scans cloud accounts across AWS, Azure, GCP, and more to catalog every resource regardless of how it was provisioned: Pulumi, Terraform, CloudFormation, or manual creation. Once cataloged, you can search, filter, group, and export your resource data. You can also import unmanaged resources into Pulumi to bring them under IaC management.

Policy enforces compliance with policy-as-code written in TypeScript or Python. Pulumi ships pre-built compliance packs for CIS, NIST, PCI DSS, HITRUST, and other frameworks so you can start evaluating without writing any code. Audit policy groups continuously evaluate all discovered resources and IaC stacks, while preventative policies block non-compliant deployments before they reach production.

This enables you to map out your cloud estate, evaluate compliance, and then remediate any issues uncovered by policy.

Why self-hosted?

Running Insights on your own infrastructure with customer-managed workflow runners gives you:

Data residency: Scan execution and policy evaluation run entirely within your private network.
Private infrastructure access: Scan resources in VPCs and environments that are not accessible from the public internet.
Compliance: Cloud provider credentials can stay internal to your network, meeting regulatory requirements for credential handling.
Flexible hosting: Run workflow runners on any environment that meets your needs, including Linux, macOS, Docker, and Kubernetes.

How it works

Customer-managed workflow runners are lightweight agents that poll Pulumi Cloud for pending work, execute it locally, and report results back. You can configure runners to handle specific workflow types: discovery scans, policy evaluations, deployments, or all three.

This works identically whether you use SaaS Pulumi Cloud or a self-hosted installation. The runner communicates with the Pulumi Cloud API over HTTPS, so no inbound connectivity is required, making it well suited to run in restricted network environments.

Under the hood, this is powered by a distributed work scheduling system that routes activities to the right runner pool, handles lease-based execution, and recovers automatically from failures. For a deep dive on the architecture, see How We Built a Distributed Work Scheduling System for Pulumi Cloud.

If your team already uses customer-managed workflow runners for Pulumi Deployments, your existing runner pools can handle Insights workflows with no additional infrastructure.

Get started

Self-hosted Insights is available on the Business Critical edition of Pulumi Cloud. To learn more or get set up:

Self-hosted Insights documentation — configuration and setup for discovery scans and audit policy evaluations on your own infrastructure
Customer-managed workflow runners — runner installation, configuration reference, and pool management
Insights & Governance overview — full documentation for discovery and policy capabilities
Contact sales to enable self-hosted Insights for your organization

Manage Cloud Visibility and Governance with Infrastructure as Code

Pulumi Insights Team — Mon, 26 Jan 2026 09:00:00 -0800

Do you know what cloud resources are running in your environment right now? Many organizations struggle to maintain visibility across their cloud estate, especially for resources created outside of infrastructure as code. Without complete visibility, you can’t enforce compliance, optimize costs, or identify security risks.

Today, we’re excited to announce new resources in the Pulumi Service Provider that solve this problem by enabling you to discover all cloud resources and enforce governance policies programmatically using infrastructure as code.

With these new resources, you can:

Discover all cloud resources across AWS, Azure, GCP, Kubernetes, or OCI environments, including resources not managed by Pulumi
Import discovered resources into Pulumi management using Visual Import to bring unmanaged infrastructure under IaC control
Enforce compliance at scale by organizing resources into Policy Groups and applying policy packs
Automate governance workflows by managing everything through code, enabling GitOps and CI/CD integration

What’s New

The Pulumi Service Provider now includes three new resources for managing cloud visibility and governance:

Resource	Description
`InsightsAccount`	Configures cloud provider scanning for resource discovery
`PolicyGroup`	Organizes stacks or cloud accounts for policy enforcement
`getPolicyPacks` / `getPolicyPack`	Data sources for querying available policy packs

Let’s explore each of these in detail.

Insights Accounts: Discover Your Cloud Resources

An InsightsAccount connects Pulumi Cloud to your cloud provider, enabling automated scanning and discovery of all resources in your environment. This gives you complete visibility into your cloud estate, including resources that aren’t managed by Pulumi.

Key Features

Multi-cloud support: Scan AWS, Azure, GCP, Kubernetes, and OCI environments
Scheduled scanning: Configure daily automated scans or trigger them on-demand
Resource tagging: Organize your accounts with custom tags

Example: Creating an AWS Insights Account

name: insights-example
runtime: yaml
resources:
 # ESC environment with AWS credentials
 aws-credentials:
 type: pulumiservice:Environment
 properties:
 organization: my-org
 project: insights
 name: aws-credentials
 yaml:
 fn::stringAsset: |
 values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2

 # Insights account for AWS scanning
 aws-insights:
 type: pulumiservice:InsightsAccount
 properties:
 organizationName: my-org
 accountName: production-aws
 provider: aws
 environment: insights/aws-credentials
 scanSchedule: daily
 providerConfig:
 regions:
 - us-west-2
 - us-east-1
 tags:
 environment: production
 team: platform

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

// ESC environment with AWS credentials
const awsCredentials = new pulumiservice.Environment("aws-credentials", {
 organization: "my-org",
 project: "insights",
 name: "aws-credentials",
 yaml: new pulumi.asset.StringAsset(`
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2
`),
});

// Insights account for AWS scanning
const awsInsights = new pulumiservice.InsightsAccount("aws-insights", {
 organizationName: "my-org",
 accountName: "production-aws",
 provider: "aws",
 environment: pulumi.interpolate`${awsCredentials.project}/${awsCredentials.name}`,
 scanSchedule: "daily",
 providerConfig: {
 regions: ["us-west-2", "us-east-1"],
 },
 tags: {
 environment: "production",
 team: "platform",
 },
});

import pulumi
import pulumi_pulumiservice as pulumiservice

# ESC environment with AWS credentials
aws_credentials = pulumiservice.Environment("aws-credentials",
 organization="my-org",
 project="insights",
 name="aws-credentials",
 yaml=pulumi.StringAsset("""
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2
"""))

# Insights account for AWS scanning
aws_insights = pulumiservice.InsightsAccount("aws-insights",
 organization_name="my-org",
 account_name="production-aws",
 provider="aws",
 environment=pulumi.Output.concat(aws_credentials.project, "/", aws_credentials.name),
 scan_schedule="daily",
 provider_config={
 "regions": ["us-west-2", "us-east-1"],
 },
 tags={
 "environment": "production",
 "team": "platform",
 })

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 {
 // ESC environment with AWS credentials
 awsCredentials, err := pulumiservice.NewEnvironment(ctx, "aws-credentials", &pulumiservice.EnvironmentArgs{
 Organization: pulumi.String("my-org"),
 Project: pulumi.String("insights"),
 Name: pulumi.String("aws-credentials"),
 Yaml: pulumi.NewStringAsset(`
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/PulumiInsightsRole
 sessionName: pulumi-insights
 environmentVariables:
 AWS_REGION: us-west-2
`),
 })
 if err != nil {
 return err
 }

 // Insights account for AWS scanning
 _, err = pulumiservice.NewInsightsAccount(ctx, "aws-insights", &pulumiservice.InsightsAccountArgs{
 OrganizationName: pulumi.String("my-org"),
 AccountName: pulumi.String("production-aws"),
 Provider: pulumi.String("aws"),
 Environment: pulumi.Sprintf("%s/%s", awsCredentials.Project, awsCredentials.Name),
 ScanSchedule: pulumi.String("daily"),
 ProviderConfig: pulumi.Map{
 "regions": pulumi.ToStringArray([]string{"us-west-2", "us-east-1"}),
 },
 Tags: pulumi.StringMap{
 "environment": pulumi.String("production"),
 "team": pulumi.String("platform"),
 },
 })
 if err != nil {
 return err
 }

 return nil
 })
}

Policy Groups: Enforce Compliance at Scale

A PolicyGroup lets you organize resources and apply policy packs for compliance enforcement. Policy Groups support two entity types: Stacks and Accounts.

You can configure policy groups in two modes:

Audit mode: Reports policy violations without blocking operations. This supports both Stacks and Accounts.
Preventative mode: Blocks operations that violate policies. This mode is only available for Stacks.

Example: Stack-Based Policy Group

Apply compliance policies to your Pulumi stacks:

name: policy-group-example
runtime: yaml
resources:
 production-policies:
 type: pulumiservice:PolicyGroup
 properties:
 name: production-compliance
 organizationName: my-org
 entityType: stacks
 mode: preventative
 stacks:
 - name: production
 routingProject: my-app
 - name: staging
 routingProject: my-app
 policyPacks:
 - name: cis-aws
 displayName: CIS AWS Foundations Benchmark
 version: 1
 versionTag: "1.5.0"

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

const productionPolicies = new pulumiservice.PolicyGroup("production-policies", {
 name: "production-compliance",
 organizationName: "my-org",
 entityType: "stacks",
 mode: "preventative",
 stacks: [
 { name: "production", routingProject: "my-app" },
 { name: "staging", routingProject: "my-app" },
 ],
 policyPacks: [
 {
 name: "cis-aws",
 displayName: "CIS AWS Foundations Benchmark",
 version: 1,
 versionTag: "1.5.0",
 },
 ],
});

Example: Account-Based Policy Group

Apply compliance policies to your cloud accounts for resource governance:

name: insights-policy-group
runtime: yaml
resources:
 # Insights account
 aws-insights:
 type: pulumiservice:InsightsAccount
 properties:
 organizationName: my-org
 accountName: production-aws
 provider: aws
 environment: insights/aws-credentials

 # Policy group targeting the Insights account
 cloud-compliance:
 type: pulumiservice:PolicyGroup
 properties:
 name: cloud-resource-compliance
 organizationName: my-org
 entityType: accounts
 mode: audit
 accounts:
 - ${aws-insights.accountName}
 policyPacks:
 - name: aws-security-best-practices
 displayName: AWS Security Best Practices
 version: 2

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

// Insights account
const awsInsights = new pulumiservice.InsightsAccount("aws-insights", {
 organizationName: "my-org",
 accountName: "production-aws",
 provider: "aws",
 environment: "insights/aws-credentials",
});

// Policy group targeting the Insights account
const cloudCompliance = new pulumiservice.PolicyGroup("cloud-compliance", {
 name: "cloud-resource-compliance",
 organizationName: "my-org",
 entityType: "accounts",
 mode: "audit",
 accounts: [awsInsights.accountName],
 policyPacks: [
 {
 name: "aws-security-best-practices",
 displayName: "AWS Security Best Practices",
 version: 2,
 },
 ],
});

Querying Policy Packs

Use the getPolicyPacks and getPolicyPack data sources to discover available policy packs in your organization:

name: policy-packs-query
runtime: yaml
variables:
 # List all available policy packs
 availablePacks:
 fn::invoke:
 function: pulumiservice:getPolicyPacks
 arguments:
 organizationName: my-org
 return: policyPacks

outputs:
 policyPacks: ${availablePacks}

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

// List all available policy packs
const availablePacks = pulumiservice.getPolicyPacksOutput({
 organizationName: "my-org",
});

export const policyPacks = availablePacks.policyPacks;

Getting Started

To start using these new resources:

Update the Pulumi Service Provider to the latest version:

npm install @pulumi/pulumiservice@latest

pip install --upgrade pulumi-pulumiservice

go get github.com/pulumi/pulumi-pulumiservice/sdk/go/pulumiservice@latest

dotnet add package Pulumi.PulumiService

No package installation needed for YAML - just use the resources directly.

Learn More

We’re excited to see how you use these new capabilities to improve visibility and governance across your cloud infrastructure. As always, we welcome your feedback in our Community Slack or on GitHub.

Enforce AWS Organizations Tag Policies with Pulumi

Alejandro Cotroneo — Thu, 20 Nov 2025 10:00:00 -0800

Tags are the foundation of cloud governance, enabling cost allocation, ownership tracking, compliance reporting, and automation across your AWS infrastructure. Yet missing or inconsistent tags remain one of the most common governance challenges. Manual tag enforcement is error-prone, and discovering missing tags after deployment means your cost reports and compliance audits are already operating with incomplete data.

Today, we’re excited to announce a new pre-built policy pack created in partnership with AWS: AWS Organizations Tag Policies. This pack validates your infrastructure as code against tag policies configured in AWS Organizations, blocking deployments when required tags are missing and shifting tag governance left into your development workflow. Define your tag requirements once in AWS Organizations and enforce them consistently across all your Pulumi deployments.

How it works

The new policy pack integrates directly with your AWS Organizations Tag Policies as the single source of truth. No separate policy configuration or custom code required. When you run pulumi up, the pack retrieves your tag requirements from your AWS organization and validates that every resource has the required tags.

Start by enabling the pack in advisory mode to surface tagging violations in Pulumi Cloud’s Policy Findings hub without blocking deployments. This collaborative workspace allows your team to triage, prioritize, and systematically remediate missing tags. Once your infrastructure is compliant, switch to mandatory mode to prevent future non-compliant deployments.

Getting started

The pack works with both AWS Classic and AWS Native Pulumi providers, covering the full range of taggable AWS resources. To get started:

Configure tag policies in AWS Organizations following the AWS documentation.
Grant required permissions by adding the resourcegroupstaggingapi:ListRequiredTags permission to the IAM role or user that runs your Pulumi deployments.
Enable the pack in Pulumi Cloud:
1. From within your organization, navigate to the Policies tab
2. Under Policy Packs, select the Available tab
3. Select AWS Organizations Tag Policies and select Add to organization
4. From the Organizations tab, apply the policy to a Policy Group
Configure enforcement level: Set to advisory for warnings or mandatory to block non-compliant deployments.

Within minutes, every Pulumi deployment in your organization will validate tag compliance, ensuring that no resources are created without required tags.

Try it today

The AWS Organizations Tag Policies policy pack is now available to all Pulumi Team and Enterprise customers.

Get started with the integration
Learn about enforcing tag policies with AWS Organizations Tag Policies
Sign up for Pulumi Cloud if you’re new to Pulumi
Join the Community Slack to share feedback

We’re excited to partner with AWS on this capability and help organizations proactively enforce tag governance. Give it a try and let us know what you think!

Announcing the Next Generation of Pulumi Policies: AI-Accelerated Governance for the Cloud

Craig Symonds — Wed, 05 Nov 2025 00:05:00 +0000

The era of AI-accelerated development has created a paradox: the faster developers move, the bigger the governance challenge becomes. For years, security and platform teams have worked to “shift left,” but the tools available have been incomplete. Most focus on detection, which is necessary but not sufficient. They identify thousands of policy violations across an organization’s infrastructure but leave teams with an overwhelming backlog and no scalable way to remediate it. This creates a persistent gap between finding a problem and fixing it. The result is an impossible choice between development velocity and organizational control, forcing leadership to slow down innovation to manage risk.

Today, we end that compromise.

We are thrilled to announce the next generation of Pulumi Policies, a comprehensive governance solution that moves beyond detection to deliver AI-powered remediation at scale. We’re introducing a new lifecycle to secure your cloud: first, Get Clean by using AI to fix your existing policy violations. Second, Stay Clean by using policy as a universal guardrail that makes AI-driven development not just fast, but fundamentally safe. These are not strictly sequential steps; you can begin enforcing “Stay Clean” policies for all new infrastructure while you simultaneously work on the “Get Clean” process for your existing footprint.

Watch our Launch Video:

Part 1: Get Clean - From Thousands of Issues to a Compliant State

The first step to a secure cloud is tackling the mountain of existing misconfigurations spread across your environments.

First, Gain Complete Visibility with the New Policy Findings Hub

To fix your issues, you first need to see them clearly. We have introduced a powerful Policy Findings Hub designed to give every stakeholder the exact view they need.

The Overview Tab: A high-level dashboard with compliance scores for leadership to track trends and measure your organization’s posture.
The Compliance Tab: A control-centric view for auditors and infosec teams, grouping findings by policy (e.g., CIS, NIST) to simplify evidence gathering and prove compliance.
The Issues Tab: A collaborative workspace for platform and development teams to triage, assign, prioritize, and track the remediation of every policy issue.

This hub is powered by our flexible audit capabilities. With Audit Scans for IaC Stacks, you can get an instant compliance baseline on all your existing Pulumi-managed infrastructure without blocking developers or re-deploying thousands of stacks. This is combined with discovery scans of your cloud accounts to give you a single, unified view of every resource, whether managed by Pulumi or not.

The Solution to Remediation at Scale: AI-Powered Fixes with Pulumi Neo

Visibility creates a new problem: an overwhelming backlog. Manually fixing thousands of issues is an impossible task.

This is where Pulumi Neo provides a powerful solution.

Pulumi Neo, our AI platform engineer, is now integrated directly into the Policy Findings hub to automate the most difficult part of the process: the fix itself. From the Issues tab, your teams can now select a group of policy issues, assign them to Neo, and trigger a remediation flow.

Neo is smart. It will:

Analyze the non-compliant resources and the policies they are violating.
Understand the required configuration to make them compliant.
Generate a pull request with the exact code changes needed to fix the issues.

Most powerfully, for an unmanaged resource discovered via a cloud scan, Neo will generate the code to import the resource into a Pulumi stack and apply the fix. This “Import and Fix” workflow transforms unmanaged infrastructure into governed, compliant code, turning a task that could take a developer hours into a simple review-and-merge process. Your teams can finally burn down their issue backlog and achieve a state of continuous compliance.

Part 2: Stay Clean - The Universal Guardrail for Humans and AI

Once you begin cleaning your environment, the next challenge is to stay clean. As AI accelerates infrastructure creation, you need robust guardrails to ensure it doesn’t also accelerate the creation of security risks.

The answer is Policy as Real Code. Pulumi Policies uses general-purpose languages like TypeScript and Python to create sophisticated guardrails that govern every change. To help you establish these controls immediately, we are launching a new suite of pre-built compliance packs authored and maintained by Pulumi experts.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

These policies act as a universal guardrail for your entire organization by blocking non-compliant changes during pulumi up, before they are ever created. Learn more about our compliance packs.

And now, you can even use Neo to author new policies. You can ask Neo in plain English to “create a policy that prevents overly permissive IAM roles,” and it will generate the code for you. This creates a powerful, dynamic governance system where AI can help you build the very rules that then govern its own actions. If you then ask Neo to create an admin role, the deployment will be blocked by the policy it just helped write. This is how we make AI safe to go fast.

A New Era of Collaboration

This “Get Clean, Stay Clean” lifecycle transforms how teams work together:

Platform Teams lead prevention by building real-code guardrails, proving their value with measurable compliance scores.
Security Teams drive the “Get Clean” process with continuous, non-blocking audit scans and use the Findings hub to manage compliance without slowing development.

Governance That Accelerates You

The age of AI-driven development demands AI-powered governance. With this new generation of Pulumi Policies, we are providing the essential infrastructure for platform engineering teams to not just survive, but thrive. You can finally build preventative guardrails that developers love, secure your cloud at scale, and transform governance from a blocker into a business accelerator. Learn more about Pulumi Insights & Governance capabilities.

This powerful new experience is available today. Navigate to the Policies and Policy Findings tab in Pulumi Cloud to explore your new governance capabilities and meet the future of platform engineering.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to set up and apply a policy group to stacks and clouds.
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

New Audit Policy Scans for Pulumi Stacks

Levi Blackstone — Wed, 05 Nov 2025 00:04:00 +0000

Audit Policy Scans for Pulumi Stacks is part of the next generation of Pulumi Policies. This capability uses policies to run compliance checks against the last successful deployment state of your stacks, providing continuous compliance monitoring without impacting your existing CI/CD workflows.

Until now, Pulumi’s preventative policies have served as a critical “shift-left” gate, blocking non-compliant changes during pulumi up. While essential, this created challenges for organizations wanting to roll out new governance across thousands of existing stacks. This new evaluation mode solves that problem, giving you a complete and continuous view of your IaC compliance posture without the friction.

A Complete Audit Story: Cloud Accounts and IaC Stacks

Pulumi’s audit philosophy is to provide complete visibility across your entire cloud footprint. We achieve this through two complementary audit modes:

Audit Scans for Cloud Accounts (Existing): This capability scans your live cloud environments (like an AWS account or Azure subscription). Its primary purpose is to give you a holistic view of your security posture by discovering all resources, including those not managed by Pulumi, and detecting configuration drift. This is how you find unmanaged, legacy, or manually-created resources that violate your policies.
Audit Scans for Pulumi Stacks (New): The feature extends this audit power to the source of truth for your managed infrastructure: your Pulumi stacks. It evaluates the last successfully deployed state of your IaC. This allows you to get an instant compliance baseline of all your managed infrastructure without having to redeploy anything, making it perfect for frictionless policy rollouts at scale.

Together, these two audit modes give you a comprehensive picture of your entire cloud estate, all feeding into one unified Policy Findings hub.

Key Scenarios for Audit Scans for Stacks

This new evaluation mode for IaC stacks is designed to unlock policy adoption at scale and accelerate developer velocity. Key use cases include:

Gain an instant compliance overview across all existing stacks: Apply policies centrally and get immediate visibility into your compliance posture without requiring redeployment of every stack.
Accelerate policy rollouts: By decoupling policy evaluation from the critical deployment path, deployments become faster and developers are unblocked. Teams still get immediate feedback on the compliance of the deployed infrastructure.
Ensure continuous compliance: Evaluation is automatically triggered whenever policy configurations change. This ensures the latest policies are always evaluated against the latest deployed infrastructure.

How It Works

This new mechanism runs against the last known successfully deployed state of your IaC Stacks as recorded by Pulumi Cloud.

Evaluation is triggered automatically after a successful pulumi up or when a policy pack attached to the stack is updated.
Results are unified into the same Policy Findings hub you use today, giving you a single pane of glass for all preventative and audit policy findings.

How to Get Started

You can enable audit scans for your IaC stacks by adding them to an Audit Policy Group.

Navigate to the Policies tab in the left navigation bar of the Pulumi Cloud console.
Create a new Audit Policy Group or select an existing one.
Select Pulumi Stacks and add the specific stacks you want to monitor.
Add Policy Packs to the group.
Save the policy group. That’s it!

The next time any of the selected stacks completes a pulumi up, a post-deployment evaluation will be automatically triggered, and the results will populate in the Policy Findings hub.

Audit policy scans consume workflow minutes from your Pulumi Cloud plan. Each scan counts toward your monthly quota based on the complexity and number of resources evaluated. See pricing documentation for details.

A Complete Governance Picture

With the addition of post-deployment evaluation for IaC stacks, you now have a complete, 360-degree view of your cloud environment. You can use audit scans for cloud accounts to get a handle on your entire live footprint, and use audit scans for stacks to easily assess your IaC-managed footprint without adding friction to your development process.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to continuously scan resources and identify violations
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

Policy Findings Hub: Move From Alert Fatigue to Action

Alejandro Cotroneo — Wed, 05 Nov 2025 00:03:00 +0000

For platform and security teams, enabling robust cloud scanning often creates a new problem: an unmanageable firehose of policy alerts. Identifying a violation is only the first step. Without a system to manage the lifecycle of these findings, teams are quickly overwhelmed, leading to prioritization paralysis and a perpetually growing backlog.

The Policy Findings hub in Pulumi Cloud is the solution to this alert fatigue. It’s a purpose-built, collaborative workspace that turns a noisy list of violations into organized, actionable tasks. The hub brings clarity and structure to the compliance process, guiding teams from initial discovery to a verified fix.

From Raw Data to Actionable Insights

The Policy Findings hub is designed with distinct views for every stakeholder involved in the governance lifecycle.

1. The Overview Tab: A Dashboard for Leaders

For a platform lead or security manager, the goal is to understand the big picture. The Overview tab provides a high-level dashboard of your organization’s compliance health, answering key questions at a glance:

What is our overall resource compliance score?
Are we trending in the right direction?
Which parts of our cloud infrastructure (stacks, accounts, etc.) carry the most risk?

This view helps leadership track progress and make data-driven decisions about where to focus engineering efforts.

2. The Compliance Tab: The Auditor and Infosec Workspace

For the infosec members and auditors, context is everything. Simply listing thousands of violations is not helpful. The Compliance tab provides a policy-centric view, grouping all findings by the specific control they violated (e.g., a specific rule within CIS or NIST).

This is crucial when preparing for an audit or assessing adherence to a specific security framework, as it allows you to see exactly where you are compliant and where you have gaps, control by control.

3. The Issues Tab: The Team’s Daily Workspace

This is the space where insight is turned into action. The Issues tab is a collaborative triage board designed for the day-to-day workflow of platform and development teams. It provides the full toolset needed to manage the lifecycle of an issue from start to finish:

Triage and Prioritize: Filter issues by severity, resource type, or policy to focus on what matters most. Set a priority level from P0 (critical) to P4 (low).
Assign Ownership: Assign issues to specific team members to ensure clear ownership and accountability.
Manage Lifecycle: Mark an issue as “Ignored” with a justification. This is a critical workflow for acknowledging intentional exceptions, which cleans up your dashboard and allows the team to focus on legitimate issues.

And for the most critical part of the workflow — the fix itself — we’ve integrated our AI agent, Pulumi Neo, directly into this view.

After selecting one or more issues, your team can assign the task to Neo. It will analyze the violations and automatically generate a pull request with the necessary code changes. For unmanaged resources, Neo will even generate the code to import them into Pulumi and apply the fix. This turns a complex manual task into a simple review-and-merge process, allowing your team to finally burn down the backlog.

Turning Alerts into Action

Effective governance goes beyond identifying violations. It requires a structured system that turns every finding into a clear and trackable path to resolution. The new Policy Findings hub provides that end-to-end workflow, from visibility to accountability to automated remediation.

By organizing policy data into meaningful views and integrating Pulumi Neo directly into the issue management process, teams can move past alert fatigue and focus on what matters most: fixing problems quickly and maintaining continuous compliance.

This new experience is now available. Navigate to the Policies > Findings tab in the Pulumi Cloud to explore your new compliance dashboard and start turning alerts into action.

Try Pulumi Policies

Ready to try these features?

Sign up for Pulumi Cloud and start a Neo task
Read the Get Started guide to manage compliance across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

New Compliance Packs for CIS, NIST, and PCI DSS

Luke Ward — Wed, 05 Nov 2025 00:02:00 +0000

Achieving compliance with industry standards such as CIS, NIST, or PCI DSS is a foundational step for every organization. Yet for many teams, it’s often a manual, months-long process that involves interpreting controls, authoring custom policies, and validating configurations across multiple clouds. These challenges often slow progress toward a known and secure cloud state.

We’re changing that. To simplify this journey, Pulumi launched a new suite of pre-built compliance policy packs for CIS Controls v8.1, NIST SP 800-53 Rev. 5, and PCI DSS v4.0.

These packs are your accelerator for the “Get Clean” journey, allowing you to enforce critical security and compliance baselines across your cloud infrastructure in minutes, not months.

More Than Just Detection: The Complete Governance Lifecycle

Traditional security tools are reactive, scanning for problems after resources have been deployed. With Pulumi, these new compliance packs are the engine for an end-to-end governance lifecycle that integrates directly into your cloud operations.

Audit for Full Coverage: Run these packs in audit mode to scan your entire cloud estate, including resources managed by Pulumi and those created through other means. This gives you an instant, comprehensive view of your current compliance posture.
Triage and Remediate: When a pack finds a violation, the finding appears in the new Policy Findings hub. From there, your team can triage, assign, and track the issue through its entire lifecycle. And with our new AI-powered capabilities, you can assign the issue to Pulumi Neo to automatically generate a pull request with the fix.
Prevent Non-Compliance: Once your environment is clean, you use these same packs as preventative guardrails. By running them during pulumi up, you block non-compliant resources before they are ever created, ensuring you “Stay Clean.”

This tri-modal capability—Audit, Remediate, and Prevent—is uniquely powerful, allowing you to fix existing issues while stopping new ones from being introduced.

New and Expanded Compliance Packs

Our new policy packs provide extensive, out-of-the-box coverage for some of the most widely adopted security frameworks. They are authored and maintained by Pulumi experts and join our existing library to provide a comprehensive toolkit for cloud governance.

Framework	AWS	Azure	Google Cloud
CIS Controls v8.1	✅	✅	✅
NIST SP 800-53 Rev. 5	✅
PCI DSS v4.0	✅
HITRUST CSF v11.5	✅	✅	✅
Pulumi Best Practices	✅	✅	✅

Benefits of Pre-Built Packs

Accelerate Compliance: Implement comprehensive governance controls in minutes without authoring hundreds of policies from scratch.
Leverage Expert Knowledge: Packs are authored and maintained by Pulumi, incorporating deep expertise in cloud and the nuances of each framework.
Codify Controls for Audits: Demonstrate to auditors that specific compliance controls are consistently enforced through code, providing a clear evidence trail.
Reduce Risk Proactively: Catch common security risks and compliance violations before deployment, drastically reducing your organization’s exposure.

Get Started Today

These policy packs are available now and are the perfect way to begin your governance journey with Pulumi.

To get started, head to the Policies page in your Pulumi Cloud organization and click on the All tab to find these new packs. Add them to an Audit Policy Group and run a scan. Within minutes, you’ll see a complete picture of your compliance posture in the Policy Findings hub, ready for triage and remediation.

Need a compliance pack for a standard that isn’t listed here? Please let us know by raising a request on our GitHub repository.

Try Pulumi Policies

New to Pulumi? Start your governance journey today.

Sign up for Pulumi Cloud and start a compliance task with Neo
Read the Get Started guide to apply and manage policies across your cloud infrastructure
Join the Community Slack to share feedback on the new features

For complete documentation, visit our Policies documentation.

How to Implement Robust Security Guardrails Using Policy as Code

Adam Gordon Bell — Tue, 30 Sep 2025 00:00:00 +0000

Welcome to the third post in our IDP Best Practices series, where we explore how to implement policy as code with Pulumi CrossGuard to create deployment guardrails that make self-service infrastructure both powerful and safe.

Platform engineering presents a fundamental tension: we want to enable developer velocity while maintaining security and compliance. Every platform team faces the same question: how do you give teams the freedom to deploy infrastructure quickly without compromising on safety, security, or organizational standards? The answer isn’t to choose between speed and safety, but rather to embrace automated guardrails powered by policy as code that make both possible simultaneously.

Want hands-on experience? Access the complete demo code and policy examples from this workshop.

The Platform Engineering Challenge: Speed vs. Safety

Let me tell you a story that perfectly captures the platform engineering dilemma. Statsig, a fast-growing feature flag platform processing an incredible 2 trillion events daily, had one infrastructure engineer named Jason who handled all infrastructure requests. Everything worked smoothly until Jason went on parental leave. Suddenly, the entire engineering organization ground to a halt. Infrastructure requests piled up, deployments slowed to a crawl, and the team faced a stark realization: their entire infrastructure capability depended on a single person.

This crisis forced them to confront a fundamental question that every growing engineering team eventually faces: How do you enable self-service infrastructure without sacrificing security, compliance, or operational stability? The answer wasn’t to hire more Jasons or to lock down infrastructure even tighter. Instead, they discovered that deployment guardrails with policy as code could transform their infrastructure conversation from “talk to the infrastructure person” to “ship with confidence, knowing guardrails will catch any issues.”

Think of it like building a system of roads with guardrails. When you create well-designed infrastructure components with proper safety barriers, teams can drive fast and confidently, knowing they’re protected from going off the cliff. The guardrails don’t slow them down; they enable speed by removing fear.

Understanding Platform Engineering Layers

Before we dive into implementing guardrails, we need to understand the architecture of a modern platform and where policies fit within it. Think of your platform as having three distinct layers, each with different security and access requirements.

At the foundation, you have your Layer 1: Foundational Infrastructure, which includes security controls, shared networking, and identity management systems like OIDC and IAM. Platform teams typically manage this layer with strict access controls because it forms the security backbone of your entire infrastructure.

Building on that foundation is Layer 2: Shared Infrastructure, which encompasses VPCs, compute platforms, and load balancers. These are standardized components that teams can use but with some room for customization based on specific needs.

The most dynamic layer is Layer 3: The Workloads Layer, where deployable artifacts, pipelines, and operability tools live. This is where the rubber meets the road, where most self-service activity happens and, consequently, where guardrails become absolutely critical. Developers need maximum freedom at this layer to innovate and ship quickly, but this freedom also introduces the most risk. It’s precisely here that policy-driven guardrails prove their worth, enabling that freedom while automatically preventing dangerous configurations.

What Are Deployment Guardrails?

Deployment guardrails are automated policies that act as your infrastructure’s safety net. Rather than relying on manual reviews or hoping developers remember all the security requirements, guardrails automatically prevent misconfigurations before they reach production. They enforce security standards without human intervention, guide developers toward best practices through immediate feedback, and enable safe self-service by catching issues at the earliest possible moment.

A helpful analogy is to think of guardrails like type checking in programming languages. Just as TypeScript doesn’t restrict your ability to write JavaScript but rather catches type errors before runtime, deployment guardrails don’t limit your infrastructure creativity. They simply ensure you’re following secure patterns and catch potentially dangerous configurations before they cause problems in production.

Introducing Pulumi CrossGuard: Policy as Code

Pulumi CrossGuard is Pulumi’s policy as code framework that brings the same engineering rigor to compliance and security that you apply to your application code. Instead of maintaining policy documents in wikis or relying on manual reviews, you can write policies in familiar programming languages like Python, TypeScript, or Go. These policies then enforce themselves across all your cloud resources and providers, running at different stages of the deployment lifecycle and integrating seamlessly with your CI/CD pipelines for automated enforcement.

Key Policy Types

CrossGuard supports two fundamental types of policies, each serving different validation needs:

Resource Policies: Validate individual resources

def restrict_dangerous_ports(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:lb/targetGroup:TargetGroup":
 port = args.props.get("port")
 dangerous_ports = ["22", "23", "3389"]
 if str(port) in dangerous_ports:
 report_violation("Dangerous port detected. Avoid using SSH, Telnet, or RDP ports.")

Stack Policies: Validate relationships across resources

def validate_microservice_encryption(args: StackValidationArgs, report_violation: ReportViolation):
 microservice_components = []
 s3_buckets = []

 for resource in args.resources:
 if resource.resource_type == "custom:infrastructure:Microservice":
 microservice_components.append(resource)
 elif resource.resource_type == "aws:s3/bucket:Bucket":
 s3_buckets.append(resource)

 if microservice_components and s3_buckets:
 for bucket in s3_buckets:
 encryption = bucket.props.get("serverSideEncryptionConfiguration")
 if not encryption:
 report_violation("S3 bucket must have encryption enabled when used with microservice components.")

Building Practical Guardrails: Real-World Examples

Let’s walk through building guardrails for a microservice platform, starting with the component from our previous workshop.

Example 1: Port Security Policy

Problem: Developers might accidentally expose services on dangerous ports like SSH (22) or RDP (3389).

Solution: A policy that blocks dangerous port configurations.

import pulumi_policy as policy

def restrict_dangerous_ports_validation(args, report_violation):
 """Prevent services from running on dangerous ports."""
 if args.resource_type == "aws:lb/targetGroup:TargetGroup":
 port = args.props.get("port")
 dangerous_ports = ["22", "23", "3389", "5432", "3306"]

 if str(port) in dangerous_ports:
 report_violation(
 f"Port {port} is not allowed. This port is commonly used for "
 f"administrative services and should not be exposed via load balancer."
 )

restrict_dangerous_ports = policy.ResourceValidationPolicy(
 name="restrict-dangerous-ports",
 description="Prevent services from using dangerous ports",
 validate=restrict_dangerous_ports_validation,
 enforcement_level=policy.EnforcementLevel.MANDATORY
)

Example 2: Resource Limits Policy

Problem: Teams might request oversized resources, leading to cost overruns.

Solution: A policy that enforces reasonable resource limits with advisory warnings.

def limit_memory_validation(args, report_violation):
 """Limit memory allocation for microservices."""
 if args.resource_type == "custom:infrastructure:Microservice":
 # Extract memory from component tags or properties
 memory_str = args.props.get("memory", "512Mi")

 # Parse memory value (assuming format like "2Gi", "1024Mi")
 if memory_str.endswith("Gi"):
 memory_gb = float(memory_str[:-2])
 if memory_gb > 1:
 report_violation(
 f"Memory allocation of {memory_str} exceeds recommended limit of 1Gi "
 f"for microservices. Consider optimizing your application or "
 f"contact the platform team for exceptions."
 )

limit_memory = policy.ResourceValidationPolicy(
 name="limit-microservice-memory",
 description="Enforce reasonable memory limits for microservices",
 validate=limit_memory_validation,
 enforcement_level=policy.EnforcementLevel.ADVISORY
)

Example 3: Cross-Resource Security Policy

Problem: When microservices use S3 buckets, encryption should be mandatory.

Solution: A stack policy that validates encryption across related resources.

def microservice_s3_encryption_validation(args, report_violation):
 """Ensure S3 buckets used with microservices have encryption enabled."""
 microservice_resources = []
 s3_buckets = []

 # Collect relevant resources
 for resource in args.resources:
 if resource.resource_type == "custom:infrastructure:Microservice":
 microservice_resources.append(resource)
 elif resource.resource_type == "aws:s3/bucket:Bucket":
 s3_buckets.append(resource)

 # If we have both microservices and S3 buckets, check encryption
 if microservice_resources and s3_buckets:
 for bucket in s3_buckets:
 sse_config = bucket.props.get("serverSideEncryptionConfiguration")
 if not sse_config:
 report_violation(
 f"S3 bucket '{bucket.name}' must have server-side encryption "
 f"enabled when used with microservice components."
 )

microservice_s3_encryption = policy.StackValidationPolicy(
 name="microservice-s3-encryption",
 description="Ensure S3 buckets used with microservices are encrypted",
 validate=microservice_s3_encryption_validation,
 enforcement_level=policy.EnforcementLevel.MANDATORY
)

Policy Enforcement Models

Pulumi CrossGuard supports multiple enforcement models to fit different workflows, and understanding when to use each model is crucial for effective policy implementation.

The Preventative Model

The most common approach is the preventative model, where policies run before resources are created. This gives you fast feedback and prevents bad deployments from ever reaching the cloud. When you run pulumi preview, policies are evaluated immediately, and if violations are found during pulumi up, the deployment is blocked. This model works particularly well for validating port configurations, resource limits, and other settings that you can check without needing to see the actual deployed resource.

# Policies run automatically during preview and deployment
pulumi preview # Policies evaluated here
pulumi up # Policies block deployment if violations found

The Detective Model

Sometimes you need to validate the actual cloud state, including auto-generated values like ARNs or IP addresses. That’s where the detective model comes in. These policies run after resources are created, making them perfect for compliance scanning and drift detection. While they can’t prevent initial deployment of non-compliant resources, they excel at catching configuration drift and validating properties that only exist after deployment.

CI/CD Integration

The third model integrates policies directly into your deployment pipeline. This ensures consistent enforcement across all teams and creates natural deployment gates. For example, you might configure GitHub Actions to run policy validation on every pull request, blocking merges if violations are found. This approach combines the best of both worlds: early feedback during development and guaranteed enforcement before production.

# GitHub Actions example
- name: Run Policy Validation
 run: |
 pulumi preview --policy-pack ./policies
 if [ $? -ne 0 ]; then
 echo "Policy violations found. Deployment blocked."
 exit 1
 fi

Policy Remediation: Beyond Detection

Modern policy frameworks don’t just detect violations; they can automatically fix them:

def auto_tag_resources(args, report_violation):
 """Automatically add required tags to resources."""
 if args.resource_type == "aws:s3/bucket:Bucket":
 tags = args.props.get("tags", {})

 if "Department" not in tags:
 # Instead of just reporting, fix the issue
 if not hasattr(args, 'tags'):
 args.props["tags"] = {}
 args.props["tags"]["Department"] = "Engineering"
 return args.props # Return modified properties

 return None # No changes needed

auto_tag_policy = policy.ResourceValidationPolicy(
 name="auto-tag-resources",
 description="Automatically add required tags",
 validate=auto_tag_resources,
 enforcement_level=policy.EnforcementLevel.REMEDIATE
)

Server-Side Policy Enforcement

For enterprise deployments, Pulumi provides server-side policy enforcement that ensures policies can’t be bypassed. The process starts by publishing your policies to your Pulumi organization with pulumi policy publish ./my-policies. Once published, you can create policy groups that combine multiple policies with specific enforcement levels, targeting particular stacks or environments while configuring exceptions for special cases. The beauty of this approach is that policies run automatically without requiring CLI flags, providing consistent governance across your entire organization without relying on developers to remember to include policy packs in their commands.

Compliance-Ready Policies

While custom policies address your specific organizational needs, compliance requirements often follow industry standards. Pulumi provides hundreds of pre-built policies for common compliance frameworks:

import { PolicyManager } from "@pulumi/policy";
import { policyManager } from "@pulumi/compliance-ready-policies/policy-manager";

new PolicyPack("aws-compliance-ready-policies-typescript", {
 policies: [
 ...policyManager.selectPolicies({
 vendors: ["aws"],
 services: ["ec2", "s3"],
 severities: ["medium", "high", "critical"],
 topics: ["encryption"],
 frameworks: ["pcidss"],
 }, "mandatory"),
 ],
});

This automatically includes policies for major compliance frameworks like PCI DSS for payment card industry standards, SOC 2 for security and compliance controls, ISO 27001 for information security management, and CIS Benchmarks for security configuration standards.

Add guardrails with policy as code

Write policies in Python or TypeScript, enforce them across every deployment, and give teams self-service infrastructure that stays secure and compliant.

Get started

Best Practices for Policy Implementation

After implementing policies at dozens of organizations, we’ve learned that successful policy adoption follows predictable patterns. The key is to adopt a product mindset: think of your policies as a product serving your development teams, not as bureaucratic rules imposed from above. Start small and iterate based on real feedback rather than trying to implement a comprehensive policy framework from day one.

Start Small and Iterate

Begin with just two or three critical policies that address your most pressing risks. Use advisory enforcement initially, which warns developers about violations but doesn’t block deployments. This gives your team time to understand and adapt to the policies. Only after gathering feedback and refining the policies should you graduate to mandatory enforcement.

Provide Clear, Actionable Error Messages

Nothing frustrates developers more than cryptic policy violations. Your error messages should explain not just what’s wrong, but how to fix it:

def good_error_message(args, report_violation):
 if violation_detected:
 report_violation(
 "S3 bucket encryption is required for compliance. "
 "Add serverSideEncryptionConfiguration to fix this. "
 "See: https://docs.company.com/s3-encryption"
 )

Embrace Progressive Enforcement

Think of enforcement levels as a dial, not a switch. Start with advisory mode to warn about issues, move to mandatory to block deployments, and eventually implement remediation to automatically fix common issues. This progression gives teams time to adapt while gradually raising the security bar.

Test Your Policies Thoroughly

Policies are code, and like any code, they need testing. Write unit tests for your policies to ensure they catch violations correctly and don’t produce false positives:

# Test policies with unit tests
def test_dangerous_port_policy():
 # Mock resource with port 22
 args = create_mock_args("aws:lb/targetGroup:TargetGroup", {"port": 22})
 violations = run_policy(restrict_dangerous_ports, args)
 assert len(violations) == 1
 assert "dangerous port" in violations[0].message.lower()

Document Escape Hatches

No matter how well-designed your policies are, there will always be edge cases. Rather than forcing teams to work around policies in dangerous ways, provide clear, documented escape hatches. Create processes for requesting exceptions, handling emergency exemptions, and appealing for policy changes. As one platform engineer put it, you need “guardrails outside the guardrails” because platform adoption will never be 100%, and that’s okay. This transparency builds trust and ensures policies remain effective enablers rather than bureaucratic obstacles to circumvent.

Real-World Success: Statsig’s Transformation

Remember Statsig’s infrastructure crisis when Jason went on parental leave? Let’s look at how they transformed their platform using the guardrails approach we’ve been discussing. After implementing policy-driven guardrails, their infrastructure story completely changed.

As Tyrone Wong, Infrastructure Engineer at Statsig, explains: “We had a single infra owner. Parental leave forced us to build self-service, and that’s when everything clicked. Developers open a PR, Pulumi previews the change right in the PR, and CI blocks risky changes. That’s how you move fast safely. The magic was turning ’talk to the infra person’ into ‘ship with guardrails.’”

The results speak for themselves. Deployment times dropped from 1.5 weeks to mere minutes. The infrastructure ticket queue that once haunted their Slack channels disappeared entirely. Security actually improved through automated policy enforcement, eliminating the human error factor. Most importantly, developer satisfaction soared as teams gained the autonomy to ship infrastructure changes without friction or fear.

When asked if developers were actually using the self-service platform, Tyrone’s response was telling: “Yeah, people are actually using it because there’s changes they wanted to get done. Previously it became this giant effort with lots of meetings, people being concerned, and Google docs about what the changes would be. Now people can just put together a PR, we have our discussions there, see if anything gets flagged, and move forward.”

Building Your Policy Strategy

Implementing deployment guardrails isn’t a big-bang transformation; it’s a journey that unfolds in phases. Based on patterns we’ve seen across successful implementations, the first week or two should focus on assessment. Start by understanding your current state, auditing existing infrastructure patterns to identify what teams are actually deploying. Look for common misconfigurations that have caused incidents or near-misses, and document your security and compliance requirements as specific, enforceable rules. Most importantly, survey your developers to understand their pain points with the current infrastructure process, as this assessment forms the foundation for policies that solve real problems rather than creating new ones.

In weeks three and four, build your foundation by implementing three to five core policies that address your most critical risks. Set up CI/CD integration so policies run automatically on every pull request, starting with advisory enforcement to gather feedback without blocking deployments. Create clear documentation and runbooks that explain not just what the policies do, but why they exist and how to work with them.

By the second month, you’re ready to expand. Add compliance-specific policies for regulatory requirements and implement server-side enforcement to ensure policies can’t be bypassed. Create formal processes for policy exemptions and exceptions, and begin measuring policy effectiveness through metrics like violation rates and remediation times.

Remember that policy implementation is never “done.” Continuously monitor violation patterns to identify areas where policies might be too strict or too lenient. Refine policies based on developer feedback and incident data, add automated remediation for common violations to reduce manual fixes, and gradually expand coverage to new services and teams using lessons learned from early adopters.

Measuring Policy Success

You can’t improve what you don’t measure, and policy effectiveness is no exception. Successful teams track metrics across three critical dimensions to validate their policy strategy.

From a security perspective, start by monitoring your policy violation rate: the percentage of deployments that trigger policy warnings or blocks. This tells you whether your policies are catching real issues or creating unnecessary friction. Track time to remediation to understand how quickly teams fix violations when they occur. Most importantly, measure the reduction in security incidents caused by misconfigurations. If your policies aren’t reducing incidents, they’re not addressing the right risks.

Security is only half the equation, though. The developer experience dimension is equally important. Monitor deployment velocity to ensure policies aren’t slowing teams down. Regular developer satisfaction surveys reveal whether teams see policies as helpful guardrails or annoying obstacles. Track support ticket volume; successful policy implementation should reduce infrastructure-related requests as teams become more self-sufficient.

Finally, don’t forget to measure the operational health of your policy system itself. Policy coverage shows what percentage of your resources are protected by policies, while the exemption rate reveals whether policies are practical or if teams constantly need exceptions. Track remediation automation to see how many violations are fixed automatically versus requiring manual intervention. Together, these metrics paint a complete picture of your policy program’s health and help you continuously improve your approach.

Common Pitfalls and How to Avoid Them

Even with the best intentions, policy implementations can go wrong. Through years of helping organizations implement policy as code, we’ve identified four critical pitfalls that can derail your efforts.

The first and most common trap is over-engineering policies. It’s tempting to create sophisticated policies that handle every edge case, but overly complex policies are hard to understand and maintain. Teams won’t trust what they don’t understand. Instead, start with simple, clear policies that address specific risks. Use descriptive naming and provide examples of both compliant and non-compliant configurations. Remember, a simple policy that everyone follows is better than a perfect policy that everyone circumvents.

Equally dangerous is falling into “policy theater”: implementing policies because you think you should, not because they address real risks. This creates friction without improving security. Every policy should trace back to an actual incident, security requirement, or compliance need. If you can’t explain why a policy exists with a concrete example, it probably shouldn’t exist.

Poor developer experience is another common failure point. Nothing kills policy adoption faster than cryptic error messages and unclear remediation steps. When a developer hits a policy violation at 5 PM on a Friday, they need clear guidance on how to fix it. Invest heavily in documentation, helpful error messages, and examples. Consider your policies’ error messages as part of your product’s user experience.

Finally, inadequate testing can erode trust quickly. Policies that break legitimate use cases will be worked around or disabled. Before enforcing any policy, test it thoroughly with real scenarios from your production workloads. Run policies in advisory mode first to catch false positives, and have teams attempt real deployments with policies enabled to ensure they don’t block valid configurations.

The Future of Policy as Code

As infrastructure becomes increasingly complex and distributed, policy as code is evolving beyond simple rule enforcement to become an intelligent layer that understands context and intent. Three major trends are shaping this evolution.

First, we’re seeing the emergence of AI-enhanced policies with smart detection systems that use machine learning to identify anomalies that rule-based policies might miss. These systems learn from your infrastructure patterns and can provide contextual recommendations that adapt based on actual usage. Even more exciting is predictive enforcement: imagine policies that can identify risky patterns before they become violations, guiding developers away from problems they haven’t encountered yet.

Second, the multi-cloud reality is driving the need for universal governance. Organizations need policies that work seamlessly across AWS, Azure, and GCP, with federated enforcement that maintains consistency across multiple cloud accounts and regions. Compliance automation is also maturing, with systems that automatically collect evidence for audits and generate compliance reports without manual intervention.

Finally, policy enforcement is moving closer to where developers actually work. IDE integration will soon provide real-time policy feedback as you write infrastructure code, catching issues before you even attempt to deploy. Self-service exemption workflows will let developers request and receive policy exceptions through automated approval processes. Perhaps most intriguingly, we’re seeing the development of learning policies: systems that improve and adapt based on developer feedback and usage patterns, becoming more helpful over time rather than more restrictive.

Conclusion: Enabling Safe Self-Service at Scale

We started this post with a fundamental tension in platform engineering: the need for both speed and safety. Through the lens of Statsig’s transformation and the technical deep-dive into Pulumi CrossGuard, we’ve seen that this isn’t actually a tension that needs resolving. It’s a false dichotomy that policy as code eliminates entirely.

The key insight from successful platform teams like Statsig is that guardrails don’t restrict freedom; they enable it. When developers know that automated policies will catch dangerous configurations, they gain the confidence to move fast and experiment. When platform teams know that policies automatically enforce security and compliance standards, they can focus on building better platforms instead of reviewing every change. This is the magic of policy as code: it transforms infrastructure governance from a bottleneck into an accelerator.

But perhaps the most important lesson is that policy as code isn’t about saying “no” to developers. It’s about intelligent automation that makes the secure path the path of least resistance. It’s about catching mistakes before they become incidents. It’s about encoding your organization’s hard-won knowledge into systems that help every developer benefit from that experience.

As you embark on your own journey to implement deployment guardrails, remember that perfection isn’t the goal; progress is. Start small, iterate based on feedback, and gradually expand your coverage. Your developers will thank you for the clarity and confidence that comes with well-designed guardrails, and your security team will sleep better knowing that policies are enforced automatically and consistently.

The path from manual reviews to automated guardrails is well-traveled and well-documented. Our complete policy examples provide real-world implementations you can adapt to your needs, while the CrossGuard documentation offers deep technical details for advanced use cases. If you’re on AWS, AWSGuard’s pre-built policies offer immediate value, and our compliance-ready policy catalog addresses specific regulatory requirements.

The future of infrastructure management isn’t about choosing between developer autonomy and operational control. It’s about using policy as code to achieve both, creating platforms that are simultaneously powerful and safe, flexible and compliant, fast and secure.

In our next post, we’ll explore Day 2 Platform Operations, diving into how to maintain infrastructure compliance after deployment and automatically remediate configuration drift. Because getting to production is just the beginning; keeping your infrastructure secure and compliant over time is where the real challenge lies.

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

Policy Comes to Team and Enterprise, with New Out-of-the-box Policies and Management Experience

Luke Ward — Wed, 17 Sep 2025 00:00:00 +0000

Pulumi’s Infrastructure as Code has included a powerful policy engine from day one. Over the past year, we’ve been enhancing it significantly to provide stronger governance for modern cloud platforms. Until now, these capabilities were limited to our Business Critical tier. Today, we’re excited to announce that policy guardrails are now available to all Team and Enterprise customers. Alongside this, we’re launching a redesigned policy management experience and introducing out-of-the-box policy packs that make it easier than ever to secure, govern, and optimize your cloud environments—even when powered by AI agents like Pulumi Neo.

Policy as Guardrails for AI Infrastructure

As developer velocity accelerates, AI agents like Neo are helping teams create and manage infrastructure at unprecedented speed. That speed creates a governance challenge: how do you ensure security, compliance, and cost-effectiveness without slowing developers down?

Policy guardrails provide the answer. Pulumi’s Policy as Code (PaC) framework applies DevOps best practices to governance, letting you codify rules, test them through pull requests, and version them alongside your infrastructure. With policies in place, you can ensure that every change stays within your organization’s standards, whether it is a human developer or Neo making a change.

What Makes Pulumi Policy Different

Unlike many other policy solutions, Pulumi Policy uses general-purpose programming languages such as TypeScript and Python rather than restrictive DSLs or YAML. This unlocks richer and more flexible capabilities, including:

Conditional logic to codify your organization’s nuanced rules.
Reusable functions and abstractions to create a shared library of policies.
Unit tests to validate policy behavior before rollout.

With today’s updates, this foundation is easier to adopt and scale across your teams than ever before.

New Simplified Experience

While Pulumi Policy has always allowed you to enforce compliance using TypeScript and Python, the existing workflow could be cumbersome—discovering policies required switching between the console and CLI, and applying them involved multiple steps.

We’ve removed that friction to provide the seamless guardrails needed for this high-velocity, AI-driven world. The new experience is built around a streamlined, in-console workflow for discovering, applying, and managing your policies.

In-Console Discoverability

We are making it easier to find and understand policy packs. You can now browse a rich set of pre-built policy packs directly within the Pulumi Cloud console—no CLI or context switching required.

You’ll find:

A rich browsing experience: See all available policy packs in one place.
Detailed information: Each pack comes with a clear description of the policies included.
Organization-approved packs: Org admins can curate a list of approved policy packs, ensuring your teams—and AI agents like Neo—are using a vetted set of policies.

New Pre-Built Policy Packs

To help you establish guardrails immediately, we have authored several pre-built policy packs. We are excited to highlight two that are available today:

Pulumi Best Practices: A foundational set of recommended governance and security controls that serves as a strong starting point for any organization.
HITRUST CSF v11.5: Provides predefined controls that help align cloud resources with HITRUST CSF requirements.

Streamlined Policy Management and Application

The new policy management experience dramatically simplifies policy application:

Intuitive Interface: Browse, select, and apply policies through a streamlined workflow using Policy Groups to bundle related policies and apply them to your stacks or cloud accounts.
Expanded Scale: We’ve eliminated the 4,000 stack UI limit on policy groups, allowing you to scale policies across your entire infrastructure.
Granular Enforcement: Configure the enforcement level (advisory or mandatory) for policies to either warn developers or block non-compliant deployments entirely.

Preventative and Audit Approaches

Pulumi Policy supports two complementary approaches to governance.

Preventative policies: Block non-compliant deployments during pulumi up, providing real-time guardrails for developers and AI agents.
Audit policies: Continuously scan existing resources for ongoing compliance monitoring, giving you a complete picture of your cloud security posture.

This dual approach ensures new deployments meet standards while maintaining visibility across your entire infrastructure. Learn more in our Preventative vs. Audit Policies guide.

How to Get Started

Getting started with the new policy management experience is straightforward:

Browse Policy Packs: Navigate to the Policies tab in your Pulumi Cloud console to discover pre-built policy packs like Pulumi Best Practices and HITRUST CSF. Learn more about Policy as Code configuration and setup.
Choose Your Approach: Decide whether you need preventative policies (to block non-compliant deployments during pulumi up) or audit policies (for continuous compliance monitoring across all cloud resources).
Create Policy Groups: Set up policy groups to bundle related policies and apply them to your stacks or cloud accounts.
Configure Enforcement: Set enforcement levels (advisory, mandatory, or remediate) for each policy based on your requirements.

Now Available To Team and Enterprise Customers

To ensure every organization can build with confidence, these policy management enhancements and the pulumi-best-practices policy packs are now available to Team and Enterprise customers. Checkout our pricing page for more information.

Conclusion

Governance doesn’t need to be a roadblock—it can be a foundation that accelerates innovation. With enhanced policy management and ready-to-use guardrails, Pulumi helps your teams and AI agents like Neo move fast while staying secure, compliant, and cost effective.

Try the new experience in Pulumi Cloud today, and let us know what you think in the Pulumi Community Slack.

Enforcing Policy as Code on Discovered Resources with Pulumi

Tyler D — Tue, 04 Feb 2025 00:00:00 +0000

In this post, we’re introducing a powerful new capability in Pulumi Insights that extends policy as code (PaC) beyond infrastructure as code to automatically govern all cloud resources in your environment. By unifying policy enforcement across both IaC and discovered resources, you can now write policies once and apply them universally - dramatically simplifying how organizations maintain security and compliance standards at scale.

What is Policy as Code (PaC)?

Policy as Code (PaC) is a way to define and enforce infrastructure policies using code. Instead of relying on manual processes or static configuration files, PaC enables automated policy enforcement in a consistent, versioned way. Pulumi’s CrossGuard feature allows you to write policies in general purpose programming languages, applying them across various cloud platforms such as AWS, Azure, GCP, and Kubernetes.

You can read more about CrossGuard in Pulumi’s CrossGuard documentation.

Accounts and Insights

Before diving into how you can configure PaC for discovered resources, it’s important to understand how Pulumi discovers resources within your cloud environment regardless of how they were created. Pulumi Insights provides visibility into the state of your cloud resources by using read only access to your cloud environment in order to catalog the resources it contains. This is done through the Accounts page in Pulumi, which shows all the accounts for discovering resources you have added to your Pulumi organization. On this page, you can add new accounts which you can then add to policy groups to begin evaluating all of your cloud resources using your organization’s policy as code.

After you have added an account, you can connect it with one or multiple Policy Groups to enforce the policies within those groups across your stacks and Insights accounts. Once linked to a Policy Group, your resources will be automatically evaluated against the policies you define whenever those policies or resources are updated.

Setting Up Policy Groups for Discovered Resources

To apply policies to your discovered resources, you first need to set up a Policy Group. A Policy Group in Pulumi enforces policies across a group of stacks and accounts in your organization. Each Policy Group can contain multiple stacks and accounts, and you can assign multiple Policy Packs to these groups.

Here’s an example of the Policy Group configuration page, where you can create and manage policy groups:

Once your Policy Group is set up, you can add Insights Accounts to the group, which will ensure that the resources in those accounts are evaluated against the policies in the group.

Running Policies on Discovered Resources

Now that your Policy Group is set up, you can start running policies against your discovered resources. Currently, Pulumi Insights supports running resource policies against all resource types supported by Pulumi Insights with support for stack policies coming soon. Pulumi Insights will evaluate each resource against the policies defined in your Policy Pack. If the resources violate any of the defined policies, those violations will show up on the Policy Violations page, which gives you a detailed view of any non-compliant resources.

Each violation includes details about the resource and the reason for the violation, helping you quickly identify and address issues.

Key Takeaways

With Pulumi’s new PaC over discovered resources feature, you can now apply the same policies to both IaC and discovered resources across your cloud environment. This enables you to write a policy once and have it apply across all of your cloud resources. This results in consistent, compliant infrastructure no matter how resources are provisioned.

To begin securing your cloud infrastructure, here are the steps to take:

Set up Policy Groups to enforce policies across stacks and accounts.
Link Insights Accounts to your Policy Groups.
View violations on the Policy Violations page and take action to resolve them.

This new capability is available for AWS, Azure, OCI, and Kubernetes. Stay tuned for more updates on policy enforcement and discover how you can leverage Pulumi for cloud security and compliance.

Try it yourself: Start enforcing policies across your discovered resources in minutes with Pulumi Insights. Check out our getting started guide to begin securing your entire cloud environment with policy as code.

For more information on getting started with Policy as Code, check out the following resources:

The Guide to Platform Engineering: 7 Steps to Get It Right

Sara Huddleston — Tue, 22 Oct 2024 07:47:03 +0000

In today’s fast-paced digital landscape, organizations are increasingly adopting platform engineering to optimize their software delivery and operations. Gartner predicts that by 2026, 80% of large software engineering organizations will have platform engineering teams to provide reusable services, components, and tools for application delivery. Additionally, by 2027, 80% of large enterprises will leverage platform engineering to scale DevOps initiatives in hybrid cloud environments effectively.

This shift is driven by the rise of cloud adoption, where many enterprises face the challenge of uncoordinated application teams deploying workloads in different ways across various cloud platforms. This siloed approach often results in a lack of standardization, security risks, and operational inefficiencies.

Platform engineering offers a strategic solution to these issues. This guide provides the essential steps to successfully implement platform engineering, from laying the foundation to scaling internal developer platforms (IDPs) for future growth.

On this article:

Step 1: Securing Executive Buy-in

The first step in your platform engineering journey is securing executive buy-in. This high-level support is essential, as platform engineering teams must create an organization-wide strategy that integrates internal developer portals (IDPs) and self-service capabilities. Leadership needs to understand how platform engineering can address inefficiencies caused by siloed application teams and uncoordinated cloud deployments.

To do this, present a clear roadmap with measurable outcomes, such as improved delivery speed and security. Use metrics like DORA (Deployment Frequency, Lead Time, Mean Time to Recovery) to demonstrate how platform engineering enhances security, standardization, and efficiency. Outline the required resources (headcount, budget, tooling) and align the project with business objectives.

Step 2: Staffing the Platform Engineering Team

Once you have executive backing, the next step is to assemble your platform engineering team. This team will develop and maintain your internal developer platform (IDP), ensuring it offers the organization secure, scalable, and self-service solutions.

Successful platform engineering teams are characterized by a strong customer focus, empathy for the needs of application teams, and the ability to act as the “glue” that binds the organization together. Key roles and responsibilities within the platform team include:

Customer-facing roles: Serve as the primary point of contact for application teams, understanding their needs and advocating for their requirements within the platform.
Infrastructure expertise: Possess deep knowledge of the underlying infrastructure, whether on-premises or in the cloud, to ensure the platform is reliable and scalable.
DevOps and automation skills: Leverage infrastructure as code (IaC) tools and techniques to automate the provisioning and management of the platform.
FinOps and cost optimization expertise: Understand the organization’s financial systems and processes to ensure the platform is cost-effective and aligned with budgetary constraints.
Software development capabilities: Develop the platform’s core components, including self-service interfaces and reusable infrastructure modules, using best practices in software engineering.

By assembling a team with this diverse set of skills and a customer-centric mindset, you’ll be well-positioned to build a platform that truly meets the needs of your application teams.

Step 3: Defining the Platform Mandate

Next, clearly define the platform team’s mandate to set expectations. This document should outline the platform’s purpose, the services it provides, and how it supports internal developer portals (IDPs) and self-service capabilities.

The platform mandate should serve as a central reference point for the platform team and its customers, ensuring everyone is aligned on the team’s mission and its value. Key elements to include in the platform mandate include:

Introduction: A high-level overview of the platform team’s purpose and the organizational outcomes it aims to achieve.
Supported systems: A list of the infrastructure, services, and tools that the platform team is responsible for managing and supporting.
Support model: Details on how application teams can access platform services, including any self-service capabilities and the team’s response times for different types of requests.
Team structure: An overview of the platform team’s members and their areas of expertise, making it easy for application teams to identify the right point of contact.

A well-defined mandate aligns the team and its customers with the platform’s value and purpose.

Step 4: Implementing the Pre-Production Pipeline

With a mandate in place, begin building the core capabilities, starting with a pre-production pipeline. This pipeline standardizes how application code moves from development to deployment, emphasizing security and consistency.

Key components of the pre-production pipeline include:

Version control: Implement a centralized version control system to manage application code and infrastructure as code (IaC) configurations.
Continuous integration (CI): Automate the build and testing of application artifacts, such as container images or deployment packages.
Artifact management: Provide a secure and versioned repository for storing and distributing the application artifacts produced by the CI process.
Static analysis: Integrate tools that can scan application code and dependencies for security vulnerabilities and other issues.
Application delivery: Automate the deployment of application artifacts to pre-production environments, such as staging or testing.

By establishing a standardized pre-production pipeline, you’ll ensure that all application teams follow a consistent, secure, and efficient process for getting their code into a production-ready state.

Step 5: Embracing Infrastructure as Code

Leveraging infrastructure as code (IaC) is crucial for managing the platform’s infrastructure. It enables consistent, scalable, and secure operations by automating the provisioning of resources, monitoring, and enforcing security policies.

Key areas where IaC can be applied within the platform include:

Foundational infrastructure: Provision and manage the underlying cloud resources, such as virtual networks, storage, and compute, that form the platform’s foundation.
Runtime platforms: Deploy and configure the runtime environments where application workloads will be executed, such as Kubernetes clusters or serverless functions.
Observability and monitoring: Set up the logging, metrics, and alerting systems that provide visibility into the platform’s health and performance.
Security and compliance: Implement security controls, such as secrets management and access policies, to ensure the platform meets regulatory and organizational requirements.
Pipelines and automation: Use IaC to define and version-control the platform’s own deployment and management pipelines, ensuring consistency and repeatability.

With infrastructure as code, the platform engineering team can ensure reliable, scalable, and secure infrastructure across the organization.

Step 6: Implementing Policy as Code

Alongside your IaC efforts, it’s important to set up a robust policy-as-code framework within your platform. Policy-as-code allows you to enforce security, compliance, and operational policies programmatically. This provides governance at scale, ensuring all teams follow the same rules.

Policy as code can be applied in two key ways:

Preventative controls: Implement policies that proactively validate and reject non-compliant infrastructure changes before they are provisioned, providing fast feedback to application teams.
Detective controls: Establish policies that continuously monitor the deployed infrastructure, triggering alerts or remediation actions when deviations from the desired state are detected.

By combining IaC and policy as code with self-service provisioning, you maintain security and compliance while giving teams autonomy.

Build your internal developer platform

Give developers self-service infrastructure with reusable components, golden paths, and governance built in using Pulumi IDP.

Explore Pulumi IDP

Step 7: Evolving Towards Self-Service

As your platform matures, the ultimate goal is to empower your application teams with self-service capabilities, allowing them to provision the infrastructure and resources they need quickly and autonomously. This self-service model can take various forms, from pre-defined infrastructure modules to fully automated deployment pipelines.

When implementing self-service capabilities, keep the following platform engineering best practices in mind:

Start small and iterate: Don’t try to boil the ocean. Begin with a few well-defined use cases, such as CI/CD pipelines or database provisioning, and gradually expand the self-service offerings as your platform team gains experience and confidence.
Focus on user experience: Ensure that the self-service interfaces, whether web-based or command-line, are intuitive and easy to use. Gather feedback from application teams and continuously refine the user experience.
Maintain stability and reliability: Even with self-service, the platform team is responsible for ensuring the underlying infrastructure and services remain stable and reliable. Implement robust monitoring, alerting, and incident response processes to maintain platform health.
Embrace a product mindset: Treat the platform as a product, with the application teams as your customers. Continuously gather feedback, measure key performance indicators, and iterate on the platform’s capabilities to meet evolving needs.

By gradually transitioning towards a self-service model, you’ll empower your application teams to move faster while maintaining the necessary guardrails and controls to ensure the platform’s long-term success.

Conclusion: Embracing the Platform Engineering Journey

Building a successful platform engineering strategy involves following a clear roadmap. But remember, implementing the platform engineering strategy is a journey, not a destination. By following the steps outlined in this guide, you’ll be well on your way to building a robust, secure, scalable, and customer-centric internal developer platform (IDP) that empowers your organization to deliver software more efficiently and effectively.

With the right approach and mindset, your platform engineering efforts will become a strategic enabler for your organization’s digital transformation.

Build secure, scalable platforms with confidence—register for the Platform Engineering Course

Frequently Asked Questions

What is Platform Engineering?

There are many definitions for platform engineering, one of which is designing, building, and maintaining internal platforms that streamline software delivery by providing reusable tools, services, and workflows for developers. It focuses on scalability, efficiency, and self-service capabilities for internal teams.

For a more in-depth explanation of real-world use cases, see What is platform engineering.

Who are the Platform Customers?

The platform customers are the end users, typically internal teams (e.g., application developers and DevOps engineers), who use the platform’s tools and services to build, deploy, and manage software.

What is an Internal Developer Platform (IDP)?

A centralized platform that offers developers the tools and environments they need to build, test, and deploy applications. It abstracts away the complexity of underlying infrastructure, allowing teams to focus on coding and delivery.

What is a Platform Team?

The platform engineering team is a dedicated group of engineers responsible for managing the internal platform. They ensure the platform meets the needs of the organization, providing reliability, security, and scalability.

What is a Self-Service Infrastructure?

A platform feature that allows development teams to provision, configure, and manage infrastructure resources on demand without relying on other teams, fostering agility.

What is Infrastructure as Code (IaC)?

The process of managing and provisioning infrastructure through code, allowing infrastructure to be versioned, automated, and managed consistently across environments.

For a more in-depth explanation, see the What is Infrastructure as Code? page.

What is Policy as Code (PaC)?

Policy as Code (PaC) defines security, compliance, and operational policies in code to automate their enforcement across infrastructure and application deployments.

What is Developer Experience (DevEx)?

The overall experience developers have with using the platform, tools, and workflows provided by platform engineering. Optimizing DevEx ensures that developers can work more efficiently and effectively.

For a more in-depth explanation, read Beyond Productivity: Developer Experience is Business Critical.

Remediation Policies: Continuous and Automatic Compliance

Joe Duffy — Fri, 20 Oct 2023 00:00:00 +0000

Pulumi’s policy as code engine, CrossGuard, is already very flexible, and can enforce custom or predefined policies across a wide variety of use cases, including security, compliance, cost, and overall best practices. CrossGuard warns or issues errors should a deployment attempt to violate a policy. Last week we announced a new extension to CrossGuard called remediation policies. Remediation policies don’t just check for compliance, they go ahead and actually fix the problems in place. This ensures that every deployment across your entire team conforms, no questions asked, while also not needing to pester end users to remember all of the rules as they write their infrastructure as code, such as tagging resources a specific way. In this post, we will dig deeper into remediation policies and their use cases.

A Refresher on CrossGuard

CrossGuard policies are rules that run during pulumi preview and up to check that resource state conforms to some set of criteria. You can use off-the-shelf policies like AWSGuard and the new Pulumi Compliance-Ready Policies or write your own.

To roll your own, you create a “policy pack” in one of the supported languages (currently JavaScript, Python, TypeScript, or Open Policy Agent (OPA) Rego). A policy pack is a collection of policies which are just objects and functions that are given an opportunity to inspect the resource graph and report whether any policy violations have been detected. They’re packaged natively (such as NPM, PyPI, etc) and Pulumi runs the policies at the right time with the right data to enforce them.

For example, this code enforces that S3 buckets are tagged:

import * as aws from "@pulumi/aws";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("aws-check-tags", {
 policies: [
 {
 enforcementLevel: "mandatory",
 name: "s3-tags",
 description: "Ensure required tags are present on S3 buckets.",
 validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (!bucket.tags || !bucket.tags["Company"] || !bucket.tags["Department"]) {
 reportViolation("S3 Bucket is missing required Company/Department tags");
 }
 }),
 },
 ],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ResourceValidationPolicy,
)

def s3_check_required_tags(args, report_violation):
 if args.resource_type == "aws:s3/bucket:Bucket":
 if ("tags" not in args.props or
 "Company" not in args.props["tags"] or
 "Department" not in args.props["tags"]):
 report_violation("S3 Bucket is missing required Company/Department tags")

PolicyPack(
 name="aws-check-tags",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 ResourceValidationPolicy(
 name="s3-tags",
 description="Ensure required tags are present on S3 buckets.",
 validate=s3_check_required_tags,
 ),
 ],
)

In the event of failure, we will see something like the following:

Policies:
 ❌ aws-check-tags@v0.0.1
 - [mandatory] s3-tags (aws:s3/bucket:Bucket: my-bucket)
 Ensure required tags are present on S3 buckets.
 S3 Bucket is missing required Company/Department tags

In this case, the policy is checking a single resource at a time — but stack-wide policies are supported too, where an entire stack’s worth of resources can be checked at once.

There are two ways to tell the Pulumi engine to run a policy pack:

Pass --policy-pack=... when running a pulumi preview or up; this just uses a policy pack locally from wherever the Pulumi CLI is being run.
Publish a policy to your organization using pulumi policy publish and then enable it using pulumi policy enable or in the Pulumi Cloud UI. After this is done, policies automatically run, without any opt-in necessary by the end user (and indeed, opt-out is not even possible). This is much better because you don’t need to worry about distributing policy packs a priori and users can’t forget to enable the right policies.

The first option is available to all state backends while the second requires Pulumi Cloud. The first is a fine option for experimenting, developing your own policy packs, or just getting started.

Finally, there are two levels of enforcement: mandatory violations issue errors that stop the deployment in its tracks; advisory violations issue warnings and are a good way to let a user know something lower priority has been detected and/or to gradually roll out policy enforcement. The same policy can be configured to be either advisory or mandatory when it is enabled depending on the scenario (or even none if you want to skip a policy but run others from the same policy pack).

Introducing Remediation Policies

Policies can now remediate violations to actually fix the problems they find in addition to or instead of reporting them as violations. Just like normal policies, a remediation is given a resource’s state for inspection. If the policy finds a problem, however, it can fix that state in place, and return it, and the engine will use the remediated state in place of the original state produced by the Pulumi program.

For example, this remediates, rather than validates, using the S3 tagging policy logic shown above:

import * as aws from "@pulumi/aws";
import { PolicyPack, remediateResourceOfType } from "@pulumi/policy";

new PolicyPack("aws-check-tags", {
 policies: [
 {
 enforcementLevel: "remediate",
 name: "s3-tags",
 description: "Ensure required tags are present on S3 buckets.",
 remediateResource: remediateResourceOfType(aws.s3.Bucket, (bucket, args) => {
 if (!bucket.tags || !bucket.tags["Company"] || !bucket.tags["Department"]) {
 bucket.tags = bucket.tags || {};
 bucket.tags["Company"] = bucket.tags["Company"] || "ACMECorp";
 bucket.tags["Department"] = bucket.tags["Department"] || "IT0001";
 return bucket;
 }
 }),
 },
 ],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ResourceValidationPolicy,
)

def s3_check_required_tags(args):
 if args.resource_type == "aws:s3/bucket:Bucket":
 had_violation = False
 if "tags" not in args.props:
 args.props["tags"] = dict()
 had_violation = True
 if "Company" not in args.props["tags"]:
 args.props["tags"]["Company"] = "ACMECorp"
 had_violation = True
 if "Department" not in args.props["tags"]:
 args.props["tags"]["Department"] = "IT0001"
 had_violation = True
 if had_violation:
 return args.props

PolicyPack(
 name="aws-check-tags-py",
 enforcement_level=EnforcementLevel.REMEDIATE,
 policies=[
 ResourceValidationPolicy(
 name="s3-tags",
 description="Ensure required tags are present on S3 buckets.",
 remediate=s3_check_required_tags,
 ),
 ],
)

To enable remediations to take place, the policy is configured with a new enforcement level, remediate, which is stricter than mandatory.

When we run pulumi up, rather than reporting a violation, we will see that it’s automatically remediated:

Policies:
 ✅ aws-check-tags@v0.0.1
 - [remediate] s3-tags (1 resource)

To see the full details, we can select details from the preview menu:

 Policy Remediations:
 aws-check-tags@v0.0.1 [remediate] s3-tags (aws:s3/bucket:Bucket: my-bucket)
 + tags : {
 + Company : "ACMECorp"
 + Department: "IT0001"
 }

This specific policy is written in a way that only works in remediation mode. That means if a different enforcement level, like advisory or mandatory is enabled, the policy will do nothing. It is possible to write a policy that can work in any enforcement level:

import * as aws from "@pulumi/aws";
import { PolicyPack, validateRemediateResourceOfType } from "@pulumi/policy";

new PolicyPack("aws-check-tags", {
 policies: [
 {
 enforcementLevel: /*any enforcement level possible*/,
 name: "s3-tags",
 description: "Ensure required tags are present on S3 buckets.",
 ...validateRemediateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (!bucket.tags || !bucket.tags["Company"] || !bucket.tags["Department"]) {
 reportViolation("S3 Bucket is missing required Company/Department tags");
 bucket.tags = bucket.tags || {};
 bucket.tags["Company"] = bucket.tags["Company"] || "ACMECorp";
 bucket.tags["Department"] = bucket.tags["Department"] || "IT0001";
 return bucket;
 }
 }),
 },
 ],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ResourceValidationPolicy,
)

def s3_check_required_tags(args, report_violation):
 if args.resource_type == "aws:s3/bucket:Bucket":
 had_violation = False
 if "tags" not in args.props:
 args.props["tags"] = dict()
 had_violation = True
 if "Company" not in args.props["tags"]:
 args.props["tags"]["Company"] = "ACMECorp"
 had_violation = True
 if "Department" not in args.props["tags"]:
 args.props["tags"]["Department"] = "IT0001"
 had_violation = True
 if had_violation:
 report_violation("S3 Bucket is missing required Company/Department tags")
 return args.props

PolicyPack(
 name="aws-check-tags-py",
 enforcement_level=# Any enforcement level possible,
 policies=[
 ResourceValidationPolicy(
 name="s3-tags",
 description="Ensure required tags are present on S3 buckets.",
 validate_remediate=s3_check_required_tags,
 ),
 ],
)

Notice in the code that we are both reporting and remediating policy issues at the same time. This might seem not to make sense at first — if we’re remediating the policy error, doesn’t that by definition mean we don’t need to report the violation? Indeed, that is a choice you can make. However, these “dual mode” policies also ensure the same policy can be run with any enforcement level — advisory, mandatory, or remediate — as appropriate.

For instance, in some settings we may prefer to issue an error to the developer so that they fix their code. In other settings, we may prefer that this same remediation happens automatically. The policy remediations feature is very flexible in that it supports a range of policy enforcement.

Configurable Remediations

In the above example, we hard-coded the set of tags we want to check for. For a simple policy for a very targeted use case, that may be ok. However, if we are writing a more general purpose policy, or one that needs to run across many organizations, this hard-coding can be unfortunate.

Policy configuration, on the other hand, enables us to write rules that are parameterized. If we used policy configuration for this example, we could configure the set of tags to check for independent of the policy itself. This would mean that we could write a single tagging policy, once, and then enable/configure it many times. This is useful for enforcement in different organizations and also within the same organization if, say, if our production tags were different than development.

Here’s a rewritten variant of that policy above which uses policy configuration:

import * as aws from "@pulumi/aws";
import { PolicyPack, validateRemediateResourceOfType } from "@pulumi/policy";

new PolicyPack("aws-auto-tagger", {
 policies: [
 {
 enforcementLevel: "remediate",
 name: "s3-tags",
 description: "Ensure required tags are present on S3 buckets.",
 configSchema: {
 properties: {
 requiredTags: {
 type: "object",
 items: { type: "string" },
 },
 },
 },
 ...validateRemediateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 const config = args.getConfig<{ requiredTags?: Record<string, string> }>();
 if (config.requiredTags) {
 let hadViolations = false;
 if (!bucket.tags) {
 bucket.tags = {};
 }
 for (const key of Object.keys(config.requiredTags)) {
 if (!bucket.tags[key]) {
 reportViolation(`S3 Bucket is missing required tag '${key}'`);
 bucket.tags[key] = config.requiredTags[key];
 hadViolations = true;
 }
 }
 if (hadViolations) {
 return bucket;
 }
 }
 }),
 },
 ],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyConfigSchema,
 PolicyPack,
 ResourceValidationPolicy,
)

def s3_check_required_tags(args, report_violation):
 if args.resource_type == "aws:s3/bucket:Bucket":
 had_violations = False
 config = args.get_config()
 if config and "requiredTags" in config:
 if "tags" not in args.props or not args.props["tags"]:
 args.props["tags"] = dict()
 for tag, value in config["requiredTags"].items():
 if tag not in args.props["tags"]:
 report_violation(f"S3 bucket is missing required tag '{tag}'.")
 args.props["tags"][tag] = value
 had_violations = True
 if had_violations:
 return args.props

PolicyPack(
 name="aws-check-tags-py",
 enforcement_level=EnforcementLevel.REMEDIATE,
 policies=[
 ResourceValidationPolicy(
 name="s3-tags",
 description="Ensure required tags are present on S3 buckets.",
 config_schema=PolicyConfigSchema(
 properties={
 "requiredTags": {
 "type": "object",
 "items": { "type": "string" },
 },
 },
 ),
 validate_remediate=s3_check_required_tags,
 ),
 ],
)

Now when we enable the policy, we can supply a configuration file. Here is a policy.json file:

{
 "s3-tags": {
 "enforcementLevel": "remediate",
 "requiredTags": {
 "Company": "ACMECorp",
 "Department": "IT0001"
 }
 }
}

This can be done at the command line in one of two ways:

If using --policy-pack, we can also pass --policy-config-file=policy.json.
If using organization policies, supply it when enabling your pack, with pulumi policy enable --config=policy.json.

It is also possible to edit or alter the configuration in the Pulumi Cloud console UI:

This Pulumi Cloud console experience makes it very easy to set default policies that apply to all stacks in your organization, hyper-target individual stacks with specific policies, or even group stacks together and enforce policies homogeneously across them, e.g. “all SOC2 stacks.”

Example Use Cases for Remediations

Remediation policies are great for many use cases. Here are a few examples:

Tagging resources with standard, organization-wide tags.
Disabling Internet access for gateways and firewall rules.
Enabling encryption on storage or buckets.
Down-sizing virtual machine configuration to use less expensive machine types.

Clearly this is not an exhaustive list, but it should serve to jog your imagination.

There are certainly use cases where you may elect not to automatically remediate violations. For example, outright misconfigurations are likely better reported to the end user, so that the infrastructure as code author is aware and can fix the source code definitions. It may not always be advisable to silently correct mistakes. And yet, there are clear use cases where it is likely preferable; for instance, rather than pestering every end user in your organization to remember precisely what set of tags and their values you want on all resources, they can just be added automatically. This enhances compliance while also enhancing productivity — a win win!

Sources of Inspiration

Before winding down, it’s worth calling out a few sources of inspiration for this feature. When we initially built policy as code, we were inspired by static analysis more generally which we use all the time with programming languages. These techniques allow us to find and fix errors closer to the source, as we are writing code, rather than after the fact when it’s already too late.

That inspiration included technologies we built during the Trustworthy Computing era at Microsoft, such as PREfix, PREfast, FxCop, SAL, and advanced programming language type systems including Spec#. At the time, security vulnerabilities were running rampant, and the more code can be “correct by construction,” the fewer security mistakes will slip through the cracks and result in costly security flaws. The analogies with the current state of the art in the cloud are abundant.

The Roslyn project took this a step further. As the C# compiler was rewritten in C# itself, the entire compiler object model was suddenly accessible to C# code itself. This facilitated a much easier way to write static analyzers which were paired with code fixes. Code fixes are very similar to policy remediations in that they don’t just report problems, they actually fix them up!

Both Azure and Kubernetes have ways to automatically remediate policy problems also. Azure Policy offers a similar remediations feature, although it is somewhat difficult to extend since it is all expressed in JSON and limited to Azure Resource Manager resources. Kubernetes offers a mutating admission webhook controller that can rewrite Kubernetes manifests on the fly before they are ever actually applied to the desired state that the controller sees.

In some ways, remediation policies are reminiscent of Aspect Oriented Programming (AOP), a popular technique in the Java community in the 2000s. Generally speaking, AOP was seen as too “magical” for widespread use. However, for targeted compliance scenarios like those discussed earlier, this approach strikes the right balance. Furthermore, we took great steps to ensure you can always find out precisely when and why a remediation changed things.

Finally, Pulumi has always had transformations to perform in-memory modifications of resources as they get registered, either one at a time or across the whole stack. These run within a process and can hook resource registrations and mutate their state. The reason remediation policies are so different and interesting, however, is that they can be applied to programs without the program itself even having to opt-in. This is precisely what enables cross-organization enforcement.

Winding Down

Remediation policies take Pulumi’s very powerful policy engine, CrossGuard, to the next level. Using them you can not just detect incompliant resources but actually fix them automatically.

Everything described in this post, except for organizational enforcement, is available in the free Pulumi open source SDK. To get started, just run pulumi policy new in a directory to begin creating your new policy pack. Also, check out the CrossGuard get started guide, which walks through the entire process of creating a new policy pack from scratch and running it. You can read more details about policies and remediations in the documentation.

Check it out and let us know what you think!

Build The Best Developer Portal with Pulumi Templates

Meagan Cojocar — Thu, 12 Oct 2023 00:00:00 +0000

At Pulumi, we work with organizations that range from a few platform team members to entire departments for managing infrastructure. Many organizations, like Mercedes-Benz, have built internal developer platforms on top of Pulumi to enable developers to self-serve infrastructure templates, and partners like AWS Proton and Port have built integrations with Pulumi to enable self-service scenarios. We are thrilled to have announced yesterday the launch of our new suite of tools to build internal developer portals with Pulumi, a result of working directly with our customers to understand their problems and how Pulumi can solve it.

Pulumi launched Pulumi Templates last year, out of the box templates based for common architectures, such as serverless templates, container service templates and Kubernetes cluster templates. The introduction of these templates allows Pulumi customers to go from 0 to 1 much quicker, but as they scale their IaC complexity a need for custom templates arises. To address this, we are expending into managing custom templates as a self-service provisioning experience.

Introduction to Developer Portals with Pulumi

Many of our customers are building their own developer portals on top of Pulumi Automation API and Pulumi Deployments, but we also wanted to offer options for teams that cannot (or do not want to) build a custom solution. The suite of tools for building internal developer portals include:

New Project Wizard: Showcased in the GIF above, Pulumi Cloud now enables developers to provision infrastructure entirely via point-and-click in Pulumi Cloud with the new New Project Wizard experience. This offers a great out-of-the box developer portal experience for any team using Pulumi Cloud.
Organization Templates: Pulumi Cloud now supports registering your own custom templates for your organization which will be made available in the New Project Wizard. This enables platform teams to standardize infrastructure creation and distribute those best practices where developers are already spending their time.
Pulumi Backstage Plugin: For teams using Backstage, they can now integrate Pulumi directly within their Backstage instance, via support for a new Pulumi plugin as well as new Pulumi scaffolder actions.
pulumi new support for private templates: By default, pulumi new provides a number of templates provided by Pulumi, but now your organization can also use private templates.

Key Benefits

Ease of Deployment: With this new functionality, you can quickly find and deploy the services you need, reducing the time and complexity of managing your cloud infrastructure. As a developer, if you are looking for a platform team sanctioned way to deploy a Kubernetes cluster, instead of chasing it down you can head to Pulumi Cloud, find the golden template and deploy it.

Enhanced Distribution: As a platform team member, share templates and configurations with your developers to ensure consistency and collaboration across your organization. It’s as simple as adding the template to a repo and selecting that repo in Pulumi Cloud. Now all of your developers have access to it when they go to create new infrastructure.

Combination with Other Features: The new template experience seamlessly integrates with your existing Pulumi workflows, providing a unified experience across your infrastructure management. Increase your developer productivity by using this suite of features in combination with Pulumi ESC. Attach an Environment to your template to have it come with configuration and secret values. Once the templates are deployed they will show in the Pulumi Cloud console use Policies over it, set up Review Stacks on the new stack to get ephemeral environments tied to PRs, find the resources that were deployed with Resource Search, and all the other Pulumi Cloud features.

Extensibility: You can leverage the out of the box New Project Wizard Experience or build developer portals with Pulumi yourself using any combination of: the Pulumi Backstage Plugin, pulumi new public and private templates, Automation API, Pulumi Deployments, or the Pulumi Cloud REST API.

Getting Started

New Project Wizard

The New Project Wizard allows anyone in your organization to pick a template they want to install, create the repo or directory for it, and walk through configuring the deployment of that template. We’ve added support for configuring Pulumi Deployments, meaning any template can be deployed without needing the Pulumi CLI locally, or any other CI/CD configuration. Follow these steps to be up and running with your infrastructure in a few clicks:

You can either 1/ use the UI or 2/ use Deploy with Pulumi buttons. If using the UI, navigate to the “New Project” tab. Select “Use a template” if you’d like to create a fully featured project, or select “Use a starter” if you want to create a bare-bones project with only the minimal necessary boilerplate file structure and Pulumi code. If you are using Deploy with Pulumi buttons, you can embed a button on your templates inside GitHub to enable point-and-click deployment of those templates.
In order to use templates you will need to authorize Pulumi with GitHub so that it can clone private repositories as template sources and commit new code for your projects. Click the “Authorize GitHub” button and accept the required permissions if you would like to use templates.
On the next screen select your deployment method. You may need to install the Pulumi GitHub app if you haven’t already to use Pulumi Deployments.
You’ll now be prompted to enter some information about the project you’re about to create: the project and stack name, the configuration details specific to that template, the repo to use when committing your new project code, and optionally the Environment you want to use. Environments enable you to use a bundle of pre-configured secrets and configuration values without needing to re-specify all of them during project creation.
After you’ve configured your project settings, you will be able to configure the behavior of Deployments, including when to trigger new Deployments and environment variables to include with your updates.

And just like that you have created a new project from a template that is deployed, without the use of the Pulumi CLI.

Organization Templates

Pulumi now allows customers on the Pulumi Cloud Enterprise and Business Critical editions to define Organization Templates to help get projects off the ground faster. A Pulumi organization admin can specify an Organization Template Source (or Sources) which will then be populated in the New Project Wizard experience described above.

Navigate to the “Integrations” tab to define your Organization Templates Source. Enter sources as github.com/<owner>/<repo>/<optional subdirectory>. A source can be a directory containing either a Pulumi.yaml, or other subdirectories with their own Pulumi.yaml files. A single repository can provide multiple templates from various subdirectories. For example, these are both valid sources: github.com/pulumi/templates (all public Pulumi templates) and github.com/pulumi/templates/aws-typescript (a specific public template).

The Pulumi.yaml file can optionally contain a template section, which typically includes a config section for specifying required config values for the project. Each config value can have a description and a default value which can be overridden. Config values can be marked as secret, which ensures values in templated projects will be stored with secure encryption.

name: my-aws-project
runtime: nodejs
description: My AWS project description
template:
 config:
 aws:region:
 description: The AWS region to deploy into
 default: us-west-2
 myAccessToken:
 description: My access token
 secret: true

The above snippet includes an aws:region configuration value with a default value of us-west-2, as well as a myAccessToken secret without a default value.

Pulumi & Backstage

We’ve seen many developer portal technologies rapidly growing in popularity over the last few years. In particular, we’ve seen Pulumi users adopting Backstage and as a result we built the Pulumi Backstage Plugin to address the needs of organizations using Backstage and Pulumi together. There are now two ways to use Pulumi from within Backstage, you can leverage both or just one or the other:

Pulumi Scaffolder Backend Module
Pulumi Backstage Plugin

Pulumi Scaffolder Backend Module: The Pulumi Scaffolder Backend Module extends the scaffolding with two new actions: Pulumi New and Pulumi Up. The Pulumi New action is a custom action that allows you to create a new Pulumi project from a template using the pulumi new Pulumi CLI command. The Pulumi Up Action is a custom action that allows you to run the pulumi up command, which creates or updates resources in a stack.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: kubernetes-template
 title: Kubernetes Cluster
 description: |
 A template for creating a new Kubernetes Cluster.
 tags:
 - pulumi
 - kubernetes
spec:
 steps:
 - id: pulumi-new-component
 name: Cookie cut the component Pulumi project
 action: pulumi:new
 input:
 name: "${{ parameters.component_id }}-infrastructure"
 description: ${{ parameters.description | dump }}
 organization: ediri
 stack: ${{ parameters.stack }}
 template: "https://github.com/my-silly-organisation/microservice-civo/tree/main/infrastructure-${{ parameters.cloud }}-${{ parameters.language }}"
 config:
 "node:node_count": "${{ parameters.nodeCount }}"
 folder: .

With a few clicks, developers can create new software projects provisioned with best practices, with code managed in the right repositories, and with the right configurations, all from a self-service UI.

Pulumi Backstage Plugin: Backstage Plugins are extensions or add-ons to the core Backstage application that allow you to integrate additional tools, services, and functionalities into the platform, enhancing its capabilities and customizing it to meet the specific needs of your development environment.

The Pulumi Backstage Plugin extends Backstage by displaying essential details like the Pulumi stack, organization, project name, and description, as well as providing an activity view with aggregated information from the Pulumi Cloud. See a screenshot of the new Pulumi tab within Backstage below:

Check out the Pulumi Backstage Plugin in the Backstage Plugin directory or the Roadie Pulumi Backstage Plugin guide to get started today.

Wrapping it up

The launch of this new functionality for internal developer portals marks a significant step forward in our commitment to providing powerful, turn-key tools for platform teams. We believe these features will enhance your experience with Pulumi, whether you’re a seasoned cloud expert leading a team of platform engineers or just getting started on your IaC journey.

As always, we welcome your feedback in the Pulumi Cloud Requests repository and are here to support you every step of the way on your platform engineering journey.

Pulumi for Platform Teams: New Features for Developer Portals, Policy and Deployments

Luke Hoban — Wed, 11 Oct 2023 04:00:00 -0700

Over the last two years, we’ve seen a huge surge in adoption of Pulumi by Platform Teams – centralized teams within a business responsible for building out core cloud infrastructure and providing tools to the rest of the organization to maximize the productivity, cost efficacy, compliance and velocity of application and service delivery throughout the organization. These teams use Pulumi to manage their own cloud infrastructure complexity, to offer best practices components to their organizations, to enforce organizational policy, and to drive infrastructure delivery automation.

Today, we’re excited to announce a broad range of new features that extend Pulumi Cloud’s support for Platform Teams, across the entire lifecycle of cloud delivery.

Developer Portals: Every platform team we work with is looking to expose reusable cloud infrastructure components and templates via a developer portal of some kind. Many are building their own custom developer portals on top of Pulumi Automation API and Pulumi Deployments, but we also wanted to offer options for teams that cannot (or do not want to) build a custom solution. Today, we are releasing three new options for Platform Teams:

🆕 Organization Templates and New Project Wizard: Pulumi Cloud now supports registering your own custom templates for your organization, and enabling developers in your organization to provision them entirely via point-and-click in Pulumi Cloud with the new New Project Wizard. This offers a great out-of-the box developer portal experience for any team using Pulumi Cloud.
🆕 Pulumi Backstage Plugin: For teams using Backstage, they can now integrate Pulumi directly within their Backstage instance, via support for a new Pulumi plugin as well as new Pulumi scaffolder actions.
🆕 pulumi new support for private templates: By default, pulumi new provides a number of templates provided by Pulumi, but it can also use your own private templates.

Policy and Compliance: Platform teams need robust and flexible solutions for establishing policy and compliance guardrails for their cloud infrastructure. Pulumi’s existing CrossGuard policy-as-code framework provides the richest option for defining and enforcing policy across all infrastructure in an organization, using the full capabilities of your favorite languages. Today, we are extending that support with two important new features for platform teams:

🆕 Compliance Ready Policies: New pre-built policy packs for for enforcing common security and compliance policies (PCI DSS, ISO 27001 and CIS) across a broad range of cloud providers (AWS, Azure, Google Cloud and Kubernetes), and dozens of services within each platform.
🆕 Remediation Policies: Pulumi Policy as Code now supports authoring policies which don’t just warn or error, but actually change the infrastructure directly to remediate compliance gaps. Remediation policies can be configured and applied across any subset of stacks within an organization.

Deployments and Delivery: Managing the delivery of cloud infrastructure changes across a wide variety of environments is an essential component of a cloud platform, and we released Pulumi Deployments in preview last year to provide a rich solution for infrastructure delivery directly within Pulumi Cloud. Today, we are making that support Generally Available (GA) along with a few key enhancements:

🆕 Deployments GA: Pulumi Deployments is now generally available, with pricing and support available across all Pulumi Cloud editions.
🆕 Deployments Support for GitHub Enterprise: Pulumi Deployments now supports integration with GitHub Enterprise as well as GitHub.com.
🆕 Org-Wide Deployments Overview Page: A new page where you can see all deployments across the organization, giving you a single pane of glass to manage company wide deployments.
🔜 Deployments Customer Managed Agents: Customers will soon be able to run deployments inside agents they run within their own infrastructure, for cases where this is required for unique compliance or security reasons.

Together with Pulumi ESC (Environments, Secrets and Configuration) which we announced yesterday, and the core Pulumi IaC infrastructure as code platform, these new features provide a rich collection of building blocks and out of the box experiences for empowering platform teams via Pulumi Cloud. At every layer of the Platform Engineering stack, Pulumi and Pulumi Cloud offer key technologies to accelerate your Platform Engineering projects.

Organization Templates and New Project Wizard

We’ve introduced a new wizard experience to create Pulumi projects into Pulumi Cloud, making it easier than ever to get started deploying new infrastructure with Pulumi.

The new project wizard allows anyone in your organization to pick a template they want to install, and walk through configuring the deployment of that template. We’ve added support for configuring Pulumi Deployments automatically, so that the template can be deployed without needing the Pulumi CLI locally, or any other CI/CD configuration. Just a few clicks and you have deployed your infrastructure.

We’ve also added integration with the newly released Pulumi ESC so that you can set up environments (and the configuration and credentials needed to deploy to them) that users within your organization can deploy into, determine who can use which environments using RBAC, and then allow those users to deploy templates directly into the environments they can access – no need to copy secrets, credentials or configuration around!

We’ve also added the ability for organizations to provide their own custom set of Organization Templates — templates specific to their organization, which can live in either public or private Git repositories. The Organization Template Source provided will populate the templates that are displayed to members in the New Project wizard experience.

Together, Organization Templates and the new New Project Wizard offer a foundational developer portal experience directly within the Pulumi Cloud console. Users can come to Pulumi Cloud, select one of the pre-defined templates set up by their Platform Team, and then in a few clicks have it deployed into a predefined cloud environment.

The New Project wizard is available now for all Pulumi users, and Organization Templates are available to Pulumi Enterprise and Business Critical users. Check out the documentation to get started.

Backstage Plugin

We’ve seen many developer portal technologies rapidly growing in popularity over the last few years. In particular, we’ve seen many Pulumi users adopting Backstage. Last week we launched a new Pulumi Backstage Plugin to address the needs of organizations using Backstage and Pulumi together.

The new Pulumi tab gives you direct access to all Pulumi stack activity associated with your backstage projects that include Pulumi stacks.

The Pulumi Backstage Plugin also supports two new scaffolding actions, pulumi:new and pulumi:up, which can be used to template out new Pulumi projects and to trigger updates to Pulumi stacks, fully integrated into the Backstage scaffolding system.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: kubernetes-template
 title: Kubernetes Cluster
 description: |
 A template for creating a new Kubernetes Cluster.
 tags:
 - pulumi
 - kubernetes
spec:
 steps:
 - id: pulumi-new-component
 name: Cookie cut the component Pulumi project
 action: pulumi:new
 input:
 name: "${{ parameters.component_id }}-infrastructure"
 description: ${{ parameters.description | dump }}
 organization: ediri
 stack: ${{ parameters.stack }}
 template: "https://github.com/my-silly-organisation/microservice-civo/tree/main/infrastructure-${{ parameters.cloud }}-${{ parameters.language }}"
 config:
 "node:node_count": "${{ parameters.nodeCount }}"
 folder: .

Check out the Pulumi Backstage Plugin in the Backstage Plugin directory or the Roadie Pulumi Backstage Plugin guide to get started today.

Compliance Ready Policies

We first released our CrossGuard policy-as-code framework nearly 4 years ago, and have seen many large organizations leverage its rich expressiveness, flexibility and early prevention features to enforce key compliance criteria for their organization. Support in Pulumi Cloud for automatically enforcing these policies across all Pulumi updates within an organization allows platform teams to put compliance guardrails in place for users within their organization.

However, traditionally each organization has needed to build their own policies, resulting in some activation energy needed to start benefiting from CrossGuard. As we’ve worked with many customers to build out their own internal compliance policies using CrossGuard, we’ve identified some common compliance standards and policies that we can offer directly as part of CrossGuard.

Today, we are making a large collection of new policies available for CrossGuard users. These policies support many common compliance standards (PCI DSS, ISO 27001 and CIS) across a broad range of cloud providers (AWS, Azure, Google Cloud and Kubernetes), and dozens of services within each platform.

These policies are offered as a library, from which Platform Teams can enable the subset they want to apply. For example:

import { PolicyPack } from "@pulumi/policy";
import { policyManager } from "@pulumi/compliance-policy-manager";

new PolicyPack("aws-iso27001-compliance-ready-policies-typescript", {
 policies:[
 ...policyManager.selectPolicies({
 vendors: ["aws"],
 services: ["ec2", "eks"],
 severities: ["critical", "high"],
 frameworks: ["iso27001"]
 }, "advisory"),
 ],
});

The new Policy Pack wizard also makes it easier than ever to create a new policy pack from the compliance-ready policies, and enable it within your organization.

Check out the documentation and open source repository to get started with Compliance-Ready Policies today.

Remediation Policies

Existing CrossGuard policies have always had the ability to be set to Advisory to emit a warning when they fail, or to Mandatory to prevent the Pulumi deployment from completing when they fail. This enables strict prevention of non-compliant infrastructure deployments before they even get into production.

However, in many cases, it’s clear what change needs to be made to the infrastructure to make it compliant. Today, we’ve launched new support in CrossGuard for Remediation Policies, a new kind of policy which actually fixes up the infrastructure to be compliant instead of just warning or erroring!

This is a magical experience for both policy authors and infrastructure engineers.

const s3NoPublicRead: ResourceValidationPolicy = {
 name: "s3-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcementLevel: "remediate",
 remediateResource: remediateResourceOfType(aws.s3.Bucket, (bucket, args) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 // Modify the ACL and return the new bucket state to use instead.
 bucket.acl = "private";
 return bucket;
 }
 }),
};

def s3_no_public_read_remediator(args: ResourceValidationArgs):
 if args.resource_type == "aws:s3/bucket:Bucket" and "acl" in args.props:
 acl = args.props["acl"]
 if acl == "public-read" or acl == "public-read-write":
 # Modify the ACL and return the new bucket state to use instead.
 args.props["acl"] = "private
 return args.props

s3_no_public_read = ResourceValidationPolicy(
 name="s3-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcement_level=EnforcementLevel.REMEDIATE,
 remediate=s3_no_public_read_remediator,
)

Check out the documentation to get started adding remediation policies to your policy-as-code configuration today.

Deployments GA

In the last year since we launched Pulumi Deployments in preview, we’ve seen incredible growth in usage and scale of Pulumi Deployments across the Pulumi user base. Customers use Pulumi Deployments for a single built-for-purpose CI/CD solution for their Pulumi infrastructure delivery, but also leverage rich API-driven deployments, Review Stacks, Click-to-Deploy within the Pulumi Cloud Console, and much more.

As part of General Availability, we are announcing pricing for deployments at $0.01 per deployment minute. The new pricing will be effective November 1st. Individual Edition users get 500 minutes free per month, and Team Edition users get 3,000 minutes free per month. Full details of the pricing can be found on the Pricing Page.

In addition to pricing, we’re making available several new features in the Deployments platform.

The new Deployments pane in the Pulumi Cloud console provides a unified view across all deployments in your organization. This includes in progress and queued deployments so that you can easily access any currently in flight deployments, as well as a full history of all deployments performed across all stacks you have access to within your organization.

And finally, we’re extending Pulumi Deployments to support additional key enterprise needs. We recently added support for connecting Pulumi Deployments to GitHub Enterprise, and we will be delivering support for self-hosted Pulumi Deployments agents which can be run within your own infrastructure later this month. You can fill out this form to register for the private preview of self-hosted agents today.

Conclusion

Pulumi Cloud offers a rich and broad platform to support any platform team today. Across the entire lifecycle of cloud infrastructure and application delivery, Pulumi Cloud supports platform teams in building cloud platforms for their organizations which empower developers via rich IaC components and developer portals, enable seamless delivery through Deployments and Automation API, provide robust compliance guardrails through Compliance-Ready Policies and Remediation Policies, and securely manage secrets and configuration across a variety of environments with Pulumi ESC.

It’s never been easier to build your internal developer platform with the help of Pulumi Cloud.

How a Bank Modernized Its Software Engineering With Infrastructure as Code Automation

George Huang — Thu, 03 Aug 2023 00:00:00 +0000

This blog post summarizes a presentation by Dennis Sauvé at PulumiUP 2023.

Washington Trust Bank, the largest independently-owned full-service commercial bank in the Northwest, has served personal, private, commercial and wealth management clients throughout the region since 1902. It has assets exceeding $11 billion and currently has 42 branches and offices in Idaho, Oregon, and Washington.

As an FDIC-governed financial institution, it is imperative for the bank to maintain secure, reliable, and compliant cloud resources to protect clients’ personal data. On the other hand, it also aimed to create more agile development teams as it modernized its software development and infrastructure. Dennis Sauvé, the bank’s first DevOps Engineer, recognized Infrastructure as Code (IaC) as the solution to these challenges.

Embracing an Infrastructure as Code approach would allow them to automate building and deploying their cloud infrastructure, eliminate infrastructure provisioning as a bottleneck, and empower developers to self-service infrastructure and increase productivity.

Background

The main challenge was managing Azure infrastructure in an efficient and secure way that kept pace with the bank’s rapid growth. Previously, they ran on-premise infrastructure and deployed with BAT and Powershell scripts. Now, they had migrated to Azure and wanted to increase development speed through CI/CD for cloud infrastructure.

In addition, cloud resources’ security and reliability were paramount. They needed a way for the infrastructure and information security teams to work together to implement security best practices for infrastructure, including how to prevent insecure resources from being provisioned.

The bank decided to adopt IaC to create reliable and rapid deployments while ensuring that its cloud infrastructure stayed compliant and secure.

Why Washington Trust Bank Chose Pulumi

The bank evaluated several options, including Terraform and Azure Bicep. However, Pulumi stood out due to its versatility, support for multiple clouds and native Azure support, and the ability to write IaC in the bank’s preferred language, TypeScript. The ease of using Pulumi with GitHub, its ability to be used in conjunction with Azure CLI, and its comprehensive support for CI/CD through GitHub Actions were also compelling factors.

Dennis praised Pulumi, saying, “Pulumi was exactly the Swiss Army Knife versatility we were looking for. We’ve only uncovered more of what we love about Pulumi as our relationship has evolved.”

Benefits of Using Pulumi

Pulumi helped Washington Trust Bank improve efficiency by maintaining its infrastructure in code, promoting the security of its infrastructure, and accelerating development speeds. It automated deployment of web services for its development teams, data management tools for its business insights team, and orchestrated its entire hub-and-spoke cloud architecture.

Improved Development Speed with Reusable Infrastructure Packages and CI/CD

Pulumi’s automation capabilities played a transformational role. By freeing the infrastructure team from handling manual deployments, it could focus on improving developer productivity. The team created reusable and repeatable infrastructure components built around strict IT security standards in the form of Frazure, an internal NPM package.

Frazure allows the bank’s developers to easily provision out-of-the-box resources for cloud services and covers the necessary Azure resource groups, vnets, and other resources. The package encapsulates best practices, such as how resource groups and their virtual networks can be created, including subnet IP spaces, peerings to and from the hub virtual network, user-defined routes and more.

To deploy, developers open a pull request which kicks off a CI/CD pipeline in GitHub Actions and provisions testing environments and tests. Once the PR is reviewed and approved, the changes are automatically deployed to staging and live environments. This automated process enabled the bank to accelerate the building, testing, and deployment of new applications, translating into rapid value delivery to their customers.

Safeguards for Infrastructure

Pulumi also gave the bank total confidence in being able to rapidly recover its cloud infrastructure in the case of a failure in Azure. The integration of Pulumi with GitHub Actions provided the team with a precise delta of changes to be made to the environment. Coupled with mandatory reviews from InfoSec and infrastructure, this significantly reduced the likelihood of deploying unapproved changes, thereby enhancing the reliability of their deployment processes.

Policy as Code Guardrails with Pulumi CrossGuard

Pulumi CrossGuard adds an extra layer of security and control and is used in conjunction with Azure Policies, which are used for auditing purposes. CrossGuard prevents the deployment of undesired, insecure, or expensive resources during the preview and deployment stage, thus preventing developers from even reaching Azure to provision resources. Custom error messages give developers context on why their deployment was not allowed.

Pulumi Cloud Policy Packs allow them to group and deploy many policies simultaneously. The Policy Packs prevent specified resources from being deployed into staging and live environments. For example, one policy requires all SQL databases to use TLS 1.2 by default and another ensures all storage buckets have public access disabled by default. These capabilities helped bolster the security of the bank’s cloud infrastructure.

Financial services cloud modernization with Pulumi

The DevOps and development teams at Washington Trust Bank rely on Pulumi as a key tool in their cloud modernization, while maintaining high security and quality standards. Pulumi played a vital role in streamlining their cloud infrastructure management, enabling their developers to be more productive, and improving the security and reliability of its cloud infrastructure.

Sign up for a free account to try deploying infrastructure on any cloud, or register for an upcoming workshop to learn more about how Pulumi can help you ship cloud infrastructure faster and more safely.

Go to more case studies

FinOps With Pulumi

Matt Small — Tue, 14 Feb 2023 00:00:00 +0000

What is FinOps?

The FinOps Foundation eloquently defines FinOps as “an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.” Simply put, FinOps is the continuous effort to control cloud spend.

Just as organizations have adopted operations-focused best practices into software development cycles and have considered how to best insert security best practices along the way, financial best practices may also be codified by developers writing cloud programs.

Adopting a FinOps practice brings real world OpEx(Operating Expenses) considerations to the decisions that cloud engineers regularly make. When you add FinOps to your Cloud Center of Excellence, technical teams bring financial context into service level and recovery objectives, scaling and placement decisions, and business continuity planning. Developers are typically more conscious of the resources they are using and consider the impact of their application design decisions at both development, test and production scale. Therefore organizations usually realize substantial OpEx savings while better forecasting their growth.

Who is Responsible for Cloud Financial Decisions?

In most smaller organizations, developers themselves are often responsible for the decisions that impact cost. In larger organizations, this responsibility typically falls to a central IT or Cloud Platform team, often seen as the cost center for infrastructure, and the best team to optimize that spend continuously. Some organizations are evolving toward FinOps as a practice, with dedicated teams responsible for enabling the organization to make smarter financial decisions and negotiating with cloud vendors for discounts.

Ultimately, the cloud account owner is responsible for the cloud bill, and failure to pay that bill will result in the suspension of cloud services. Given that infrastructure is often code, developers or IT teams are often made responsible for the task of optimization. Optimization recommendations may range from simply deleting orphaned cloud resources to re-architecting the entire application to use a modern serverless framework that would consume less resources overall.

Establishing FinOps Practices

The first step of establishing many FinOps practices is determining the allocation of costs. It is easy to allocate costs to individual users launching cloud services, but it becomes compoundingly hard once pipeline automation, team structure, and business unit reporting come into play. As an organization scales, it grows increasingly difficult to allocate costs across different business units and teams, across environments such as development versus production, or across application component services such as the data layer. Further, how does an organization account for supporting systems and services running alongside applications in the cloud, including third-party commercial software?

When starting your FinOps Journey is essential to understand cost allocation, typically done with consistent and enforced tagging of cloud resources. Creating a Tag Policy is covered below.

FinOps: Reactive vs. Proactive Optimization

Most FinOps processes today are reactive; once you have received your bill, you will observe (and pay) the costs and resources accounted for, review your architecture and make necessary adjustments such as reserving, reallocating or removing resources. Next month, you will do it again, also factoring in your company’s cloud growth, application design changes, team shifts and other dynamics that occurred in the meantime. Many platforms, tools, and job descriptions are oriented toward this reactive optimization process.

Proactive optimization and enforcement means providing real time feedback on how cloud engineering architectural changes may impact cost and creating preventative policies which do not allow for budget-busting cloud services to be provisioned. This is an evolving practice in many modern cloud-centric organizations. As more cloud operations are defined as code, this preventative, proactive optimization model is becoming more popular.

Financial optimization can also come in the form of strategic sourcing; most cloud providers offer multiple discount mechanisms, including large enterprise discount plans for committed consumption that may extend to third party SaaS software purchased through the cloud marketplaces, as Pulumi is. This level of optimization will provide dramatic savings on your top-line spend.

FinOps with Pulumi

Using cloud engineering practices with Pulumi, you have the opportunity to implement both proactive and reactive models to control your cloud spend.

As an infrastructure as code platform, Pulumi is in the unique position to be proactive about managing your costs.

You can design guardrails on your provisioning to limit expensive resource types or quantities,
Direct resources to reserved allocations,
Ensure resources are tagged and traceable to the correct cost center,
Connect resources to your observability and dedicated FinOps platforms,
Provide preventative visibility and control.

Consider uses for CrossGuard Policy as Code, multi-language components for defining resource abstractions, and Automation API to package up orchestration into web service endpoints, as described in Pulumi Features below.

If you are proactively managing your infrastructure, then reactively, the largest contributor to financial overrun is drift; the misalignment between the desired state and the actual state. Pulumi is used to define your desired state; however, many things may cause the actual state to begin to deviate from the desired state in your code, such as manual actions from the cloud console or ad-hoc deployment pipelines.

Drift detection, which is the name given to continuously scanning your environment to compare the actual state with the desired state and alerting and/or automatically remediating the difference in state, is a primary method of managing these creeping cloud costs. Leverage an automation system, such as a CI tool, to implement continuous scanning against your Pulumi code as described below.

Remediation of any infrastructure mismanagement requires infrastructure reconfiguration action to be taken; often resources need to be replaced with better suited, more cost effective resources, and resources that were provisioned outside of acceptable policies may have to be destroyed. However, any remediation should carefully consider the underlying reasoning for the misalignment in the first place. That should include both the reason for the initial deployment specifications as well as any decisions for why that’s no longer acceptable. Be sure to consider all architectural decisions, such as disaster recovery and business continuity planning, regional latency, and any other impact to service level objectives (SLOs). Understanding the context will help you code preventative measures into your Pulumi programs going forward and the self-documenting nature of infrastructure-as-code will ensure your decisions are memorialized for future developers and operators, for example, in a Stack README as described.

Automation of remediation is a goal for many cloud engineering organizations; if the perfect state is defined in code, then any drift may indicate the need to reconcile back to the desired perfect state. Given that some cloud resources may necessarily drift due to limitations in how they are managed, a combination of alerting and remediation of known patterns is implemented. For example, you might choose to detect and deprovision any newly instantiated resource not provisioned by Pulumi, but allow manual resizing of resources if needed. Just be sure to capture any infrastructure and improvements you want to make default and/or repeatable as infrastructure as code.

Best First Action: Implement a Tag Policy

Getting started with a FinOps usually falls to the resource owners or Cloud Engineering teams themselves. The more resources you have, the more complex and noisy things are going to get and the harder it will be to both allocate costs and resources where they are needed, as well as identify and eliminate the unneeded ones.

Implementing Tag Policy is the best first action to take. Tags are the set of required cloud metadata tags for any resources provisioned by your organization. While not every resource in every cloud may be tagged, most are. Getting into the practice early will help you maintain accountability for what you are running, demystify your cloud bills as they grow larger, and help update the application architecture or make cost-effective product decisions long-term.

A Basic Tag Policy for FinOps will include:

Owner - the person responsible for this resource that you would contact if you had to (e.g., johndoe@pulumi.com)
Origin - the pipeline, process, and/or system through which this came to be (e.g., ArgoCD, Jenkins, Pulumi)
Business Unit - the team responsible typically maps to the cost center associated (e.g., Sales, Engineering)
Environment - the teams/customers this deployment services (e.g., Dev, Staging, Production)
Application Component - the part of the application that this resource serves (e.g., data pipeline, authentication, front end)*

You will now be able to report on and manage resources in those tag groups. It’s advisable that you do not create too many required tags, or it will quickly get difficult to manage and it increases the likelihood of multiple tags applying, which reduces the insightfulness of the data.

Read more about Tag Policy implementation with Pulumi below, and for extended reading, refer to this post, Automatically Enforcing AWS Resource Tagging Policies from CEO, Joe Duffy.

Pulumi Features in Context

Multi-Language Components

Multi-language components allow you to create repeatable infrastructure patterns, modular abstractions of resources and/or groups of resources that meet your desired configuration standards. Packaging up resources within and across clouds, implementing standard deployment best practices, and making those components available to developers reduces the cognitive load that they have when building new applications from those pre-assembled, ready-to-run components.

Use these guardrails to enforce Tag Policies, for example that every tag for “Production” is actually “Production” and not “Prod” or “production” (yes, case sensitivity matters). Or you may ensure teams only deploy resources such as VMs to regions where you have allocated Reserved Instances or other financial benefits in your application architecture. With MLCs end users have access to your component and not to the underlying infrastructure resources, guaranteeing repeatabality, however, in order to realize the benefits of MLCs, your developers must be empowered to leverage them, but limited from using other methods.

CrossGuard

CrossGuard Policy as Code allows an Organization to define global rules for how resources may be provisioned and prevent resources from being provisioned by Pulumi in any other configuration. Pulumi Stacks that do not meet the Organization’s financial, security, data protection, or other pre-defined standards are prevented from provisioning any resources, and the developer is instructed to correct their desired configuration or program in accordance with the Organization-wide policies.

Policy as code ensures that any Pulumi code written and run meets an organization’s stated policies. It is the ultimate preventative weapon to prevent financial, security, or other placement and provisioning decisions that may lead to exposure or overrun.

Go here for examples of FinOps policies to get you started!

Automation API

Of the many things Automation API allows you to do, one is you can create an HTTP endpoint for a Pulumi program. Organizations have used this to control easy on/off switches for applications such as provisioning/deprovisioning single tenant SaaS architectures, short lived environments, and complex testing and blue/green deployments. Because of the encapsulation of a Pulumi program and the simplification this provides, this endpoint may be directly exposed to those responsible for making the financial decisions in the moment, such as a Sales Engineer who must turn on a new POC environment for testing who then must be sure to shut that off when completed. Oftentimes, these decisions are automated in processes and pipelines.

Pulumi FinOps in Practice: Sweeping up Dev and QA

A common automation in FinOps is to destroy things that don’t meet your Tag Policy. These “Sweeper Bots” will continuously query AWS for resources with specific tags and delete them. Read more about how Pulumi has implemented this using Pulumi to set tags and Lambda to sweep through and remove resources that meet certain specifications in this post, Controlling AWS Costs with Lambda and Pulumi.

Conclusion

In the manner of “Crawl, Walk, Run”, it’s best to start by implementing policies as code in a manner that will cause the most benefit while causing the least amount of change and/or downtime. Make sure you have the appropriate billing tags applied to all supported resources, ensuring you are able to allocate costs to the appropriate business units in your company. Then add in additional policies to make sure you are using instances covered by any reserved instance or similar savings plans. Continue evolving your infrastructure and policy as code strategy to incorporate both preventative and reactive checks and balances.

Have questions about using Pulumi when implementing FinOps in your IaC pipelines? Contact us and let us know your questions or request a demo.

Six Things You Might Not Know About the Pulumi Service

Chris Smith — Mon, 24 Jan 2022 00:00:00 +0000

As a reader of this blog, you’ve probably heard of the Pulumi Service, the default state-management backend of the Pulumi CLI. If that’s the case, there’s also a good chance you’ve heard of a number of the Service’s key features, like helping you organize your projects and stacks, collaborate with others with the help of organizations, or handle sensitive data securely with built-in support for encrypted secrets.

What you might not know, though, is that we’re adding new features to the Pulumi Service all the time, and that some of these features can be fairly easy to miss. So in this post, we’ll highlight a handful of the features you might not be aware of, and that we think make it even easier to manage your infrastructure with Pulumi.

Let’s get started!

Feature 1: Stack Tags

The first thing we’ll cover is the Pulumi stack tags feature. Stack tags are key/value pairs that are associated with your Pulumi stack. You can use them for any number of purposes, from keeping things organized to even flagging whether or not it’s okay for a script to reclaim the stack’s resources.

While you can create, edit, and remove stack tags using the Pulumi CLI (see pulumi stack tag), you can also do so in the Pulumi Console:

Once set, you can quickly filter stacks on your organization’s Projects tab as well.

Feature 2: Link Updates to your CI/CD pipeline

Another helpful thing the Pulumi Service can do is link the Pulumi stack update to the CI/CD job or run that was used to perform it, as well as to the specific source commit:

When Pulumi updates a stack, it will store some information about the local machine state, such the current git SHA if the stack resides in a git repository. It is with this data that the Pulumi Service links to relevant services where possible.

If you’re curious to know all of the information Pulumi has for a stack update, you can navigate to the Environment tab for that update:

Feature 3: Custom Update Messages

One of the most useful pieces of additional data stored with each update is the message property. By default, Pulumi will use whatever the latest git commit message is. But did you know you can customize that message from the command line?

By passing the --message (or -m) flag to pulumi up, you can provide a custom update message, which can help explain the context for why you made a particular infrastructure change:

$ pulumi up --message "Release the hounds\!"

Feature 4: Viewing Resource Changes

Another thing you might have missed is that the Pulumi Service supports multiple views for a stack update’s logs.

The standard view mimics the Pulumi CLI’s output. However, you can switch to the Diff or Diagnostic views, too.

The Diff view displays all of the properties of modified resources, along with their previous/updated values. This can be helpful when trying to understand exactly what happened for a stack update.

The Diagnostic view just outputs so-called “diagnostic” messages from the Pulumi update. Most commonly, this is where you will see the output of things like calls to JavaScript’s console.log(...) or Python’s print(...) functions. It’ll also include the output of dependent tools, like the output when building Docker containers.

Feature 5: Stack Resource Visualization

Another cool feature of the Pulumi Service is being able to visualize a stack’s resources and their relationships to one another. This is a really important feature!

One of the advantages of using an infrastructure as code tool like Pulumi is that you aren’t just creating a flat list of resources. Instead, by the virtue of how the code and resource graph is structured, you are building a graph of resources.

This means that Pulumi has a semantic understanding of not only what resources are in your stack but also how they relate to one another.

If you navigate to a stack’s Resources tab, by default you see them listed in a table. You can filter this list by resource type, or by providing a custom filter:

However, in order to see the expanded resource graph, click the Graph View button. This will switch to rendering the resources as an interactive graph.

Notice here that the resources that are part of a component are grouped together. Also, you can double click on those nodes in the graph to expand or collapse them!

Feature 6: Drilling into Resource Properties

But you don’t need to just settle for a “top-level view” of your resources. You can click on any specific resource on the Resources tab, and see all of the properties of that resource.

This allows you to see all of the properties that Pulumi is tracking for that resource. It will also show you any relationships to other resources in the same stack.

The Pulumi Service also links you to the resource’s cloud provider’s console where possible, so you can see even more details.

Is your resource missing a link to the cloud provider console? With new services being launched from the myriad providers Pulumi supports every day, it’s hard to keep up. So if you would like us to add cloud provider links, please file an issue over in the pulumi/console-requests GitHub repository so we can update our database.

There are plenty of other features to check out in the Pulumi Service, and we have exciting improvements on the way! As always, feel free to stop by the Pulumi Community Slack to learn more, ask questions, or share anything cool you’re up to!

Empower Your Team with Policy as Code

Sophia Parafina — Mon, 08 Mar 2021 18:12:25 -0700

Policies set the guardrails for your applications and infrastructure. They define many aspects of how your company manages its applications and infrastructure. Security, safe use of resources, and compliance with external standards are just a few examples of what a policy can define.

Historically, policies were written and enforced by compliance and security teams who set down the rules as text documents. More recently, teams often use a cloud provider’s GUI to set policies. Both of these approaches are error-prone and far too slow to keep up with complex, rapidly changing infrastructure and automated systems. They also can’t take advantage of the accepted best practices for software development.

Instead, just as you define infrastructure as code, so too should you define policies as code.

What Do You Gain with Policy as Code?

The short answer to this question is that you can apply software engineering principles and approaches to your policies, just as you do with your applications and with infrastructure as code. Here are some of the specific benefits:

Clarity

Policies written as code are unambiguous pieces of logic. They can be read both by humans and by machines. There’s no way to misinterpret them, which is a real problem with text documents.

Version control

When policies are described as code, they can be checked into source control, versioned, and code-reviewed. They become a part of your automated pipelines.

Testing

As any critical system grows in complexity, people can start to feel nervous about making changes. When policies are written as code, they can be tested, just as you test your applications and infrastructure. You can integrate your policies into your automated testing system as easily as any other code you write.

Familiar tools such as IDEs

When policy is code, you can use familiar tools, such as the IDEs you use to write other pieces of code to develop new policies, refactor existing policies, and catch errors early.

Automation

As we mentioned, policy as code can be sent through your automated CI/CD pipelines for fast testing and deployment. For most companies, their infrastructure has become too large and complex to use manual procedures such as documents and GUIs to make changes.

Common Use Cases

Policies can encompass many areas. Here are just a few.

Authorization control. You can implement fine-grained access control for applications. For example, a service can make an API call to a policy engine to determine whether a request is authorized or not.
Infrastructure provisioning. You can create policies that require tagging, provisioning certain types of resources, and secure network settings.
Kubernetes control. You can manage Kubernetes resources such as pods, namespaces, and nodes. You can ensure container images come from trusted registries.
Cost control. One way to control your cloud costs is to set policies based on pricing. You can calculate the cost of a resource ahead of time and create a policy limiting the amount you spend to deploy it. For an example of how tagging on AWS can control costs, take a look at Automatically Enforcing AWS Resource Tagging Policies.

There can be many other uses. Use your imagination. Another benefit of policy as code is that it makes experimentation easy.

Learn More

Ready to learn more? With Pulumi, you can create and manage infrastructure and policies with the languages and tools you already know. To help you implement policy as code, check out this CrossGuard, our product that uses policies to enforce gated deployments. With it, administrators can apply policies to particular stacks. Any violation will gate or block an update from proceeding. Give Pulumi a try and get started for free today.

Policy as Code for Any Cloud Provider

Sophia Parafina — Tue, 27 Oct 2020 00:00:00 +0000

Policies protect your infrastructure by controlling access, set limits that reduce the blast radius of an incident, and manage infrastructure operations. Policies are commonly created through a form on a cloud provider’s administrative console, making replicating or versioning the policy more difficult. With Policy as Code, you can apply software engineering practices such as automated testing, deployment, and version control when creating policies.

CrossGuard is Pulumi’s Policy as Code solution that lets you create, verify, apply, and enforce policies. Policies are standalone packages that can be run against any Pulumi stack. That means your policies are language agnostic and work with any language supported by Pulumi. Policy Packages are policy bundles that evaluate every resource in your stack, whether deployed in AWS, Azure, Google Cloud, or Kubernetes.

The key features of CrossGuard are:

Policy SDK for coding custom policies using TypeScript/JavaScript or Python
Validating infrastructure before deployment by verifying it locally
Policy Packs for enforcing best practices for security, reliability, and cost
Validating all the infrastructure deployed by an organization.

Whether you create policies for a single project or across your organization, CrossGuard enforces best practices for cost, compliance, security, and team practices.

Parts of a policy

A policy is made up of the following parts:

a name
a description
an enforcement level
a resource validation
a message to report the violation

Policies enforce a specific logic. In the example above, Kubernetes can’t expose services to the Internet. We accomplish this by not allowing a spec to create LoadBalancer when a service is declared. Policies are checked during pulumi preview and during pulumi update to enforce defined restrictions.

There are two types of policies, a ResourceValidationPolicy that validates a particular resource in a stack, and a StackValidationPolicy that validates the stack as a whole. When CrossGuard calls a ResourceValidationPolicy, it checks each resource in the stack. These checks are before a resource is created and blocks any resources that fail the policy logic.

A StackValidationPolicy is run against the entire stack, requiring all the resources to be created and registered. Resources that fail validation will be blocked from being created or modified during pulumi up. Out of compliance resources will fail during preview or update, and we recommend running pulumi preview to catch these resources. Stack validation policies inspect multiple resources at once. This lets you validate resources dependent on other resources, such as a database that requires persistent storage.

Now that we understand how CrossGuard works. let’s look at examples for several cloud providers and Kubernetes.

Examples

The following examples are a common scenario showing how to prevent access to data in AWS, Azure, Google Cloud Platform, and Kubernetes using either TypeScript or Python to create policies. You can try out any of these policies by creating a new directory and running pulumi policy new, e.g.:

$ mkdir az-python-storage-policy && cd az-python-storage-policy
$ pulumi policy new azure-python

AWS

import * as aws from "@pulumi/aws";
import { PolicyPack, ReportViolation, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("policy-pack-typescript", {
 policies: [{
 name: "s3-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 reportViolation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def s3_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:s3/bucket:Bucket" and "acl" in args.props:
 acl = args.props["acl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html")

s3_no_public_read = ResourceValidationPolicy(
 name="s3-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 validate=s3_no_public_read_validator,
)

PolicyPack(
 name="aws-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 s3_no_public_read,
 ],
)

Azure

import * as azure from "@pulumi/azure";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("azure-typescript", {
 policies: [{
 name: "storage-container-no-public-read",
 description: "Prohibits setting the public permission on Azure Storage Blob Containers.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(azure.storage.Container, (container, args, reportViolation) => {
 if (container.containerAccessType === "blob" || container.containerAccessType === "container") {
 reportViolation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_container_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "azure:storage/container:Container" and "containerAccessType" in args.props:
 access_type = args.props["containerAccessType"]
 if access_type == "blob" or access_type == "container":
 report_violation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources")

storage_container_no_public_read = ResourceValidationPolicy(
 name="storage-container-no-public-read",
 description="Prohibits setting the public permission on Azure Storage Blob Containers.",
 validate=storage_container_no_public_read_validator,
)

PolicyPack(
 name="azure-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_container_no_public_read,
 ],
)

Google Cloud

import * as gcp from "@pulumi/gcp";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("gcp-typescript", {
 policies: [{
 name: "storage-bucket-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on GCP Storage buckets.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(gcp.storage.BucketACL, (acl, args, reportViolation) => {
 if (acl.predefinedAcl === "public-read" || acl.predefinedAcl === "public-read-write") {
 reportViolation("Storage buckets acl cannot be set to public-read or public-read-write.");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_bucket_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "gcp:storage/bucketACL:BucketACL" and "predefinedAcl" in args.props:
 acl = args.props["predefinedAcl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation("Storage buckets acl cannot be set to public-read or public-read-write.")

storage_bucket_no_public_read = ResourceValidationPolicy(
 name="storage-bucket-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on GCP Storage buckets.",
 validate=storage_bucket_no_public_read_validator,
)

PolicyPack(
 name="gcp-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_bucket_no_public_read,
 ],
)

Kubernetes

import * as k8s from "@pulumi/kubernetes";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("kubernetes-typescript", {
 policies: [{
 name: "no-public-services",
 description: "Kubernetes Services should be cluster-private.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(k8s.core.v1.Service, (svc, args, reportViolation) => {
 if (svc.spec && svc.spec.type === "LoadBalancer") {
 reportViolation("Kubernetes Services cannot be of type LoadBalancer, which are exposed to " +
 "anything that can reach the Kubernetes cluster. This likely including the " +
 "public Internet.");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def no_public_services_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "kubernetes:core/v1:Service" and "spec" in args.props:
 spec = args.props["spec"]
 if "type" in spec and spec["type"] == "LoadBalancer":
 report_violation(
 "Kubernetes Services cannot be of type LoadBalancer, which are exposed to " +
 "anything that can reach the Kubernetes cluster. This likely including the " +
 "public Internet.")

no_public_services = ResourceValidationPolicy(
 name="no-public-services",
 description="Kubernetes Services should be cluster-private.",
 validate=no_public_services_validator,
)

PolicyPack(
 name="kubernetes-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 no_public_services,
 ],
)

All Clouds and all resources

Policy as Code is a powerful tool for protecting and managing your infrastructure. As you can see, Pulumi supports policies for all resources on all clouds. We have examples and articles to get you started with Policy as Code.

Authoring CrossGuard Policy with Open Policy Agent (OPA)

Luke Hoban — Fri, 14 Aug 2020 00:00:00 +0000

We’re excited to announce the addition of Open Policy Agent (OPA) Rego language support to Pulumi’s CrossGuard policy-as-code framework. This enables Pulumi CrossGuard policy to be authored in either JavaScript/TypeScript/Python or in the popular Rego language using OPA.

Pulumi’s CrossGuard policy-as-code framework provides the ability to author, apply and enforce policy directly as part of your Pulumi deployments. With the new support for OPA Rego, CrossGuard supports a broad spectrum of policy authoring options, from expressive imperative languages to a popular industry-standard declarative policy language.

OPA-based rules for CrossGuard get all the core benefits of Pulumi’s policy-as-code framework - policies can be run on previews to get warnings about errors before you even deploy, policies can produce either advisory or mandatory recommendations allowing flexibility in flagging and enforcing policy violations, and policies can be applied and enforced across an entire organization through the Pulumi Service.

What is Pulumi CrossGuard?

Pulumi CrossGuard is a policy-as-code framework for enforcing policy across Pulumi infrastructure deployments on any cloud or in Kubernetes. CrossGuard can be used to enforce policy for compliance, security, best practices or cost control.

Pulumi’s web console offers tools to manage and enforce CrossGuard policy across your organization, ensuring that every infrastructure project is held to a high bar on policy compliance.

CrossGuard policy is enforced during previews, ensuring that policy violations are found during development, not just at deployment time. At deployment, policies are enforced on each resource immediately before changes to that resource are applied. As a result, any change that would violate policy is rejected before being applied to your target cloud or Kubernetes environments.

What is OPA?

Open Policy Agent (OPA) provides policy-based control for cloud native environments. OPA provides a single authoring language (Rego) and policy runtime, which can be used to enforce policy in a wide variety of environments including Kubernetes, Envoy, Terraform Kafka, SQL, Linux - and now Pulumi!

The Rego language is declarative, easy to use, and expressive - along with good integration in tools like Visual Studio Code.

Using OPA with Pulumi CrossGuard

To get started with OPA and CrossGuard, start by downloading and installing Pulumi, then get the OPA plugin with:

$ pulumi plugin install analyzer policy-opa v0.0.2
[analyzer plugin policy-opa-0.0.2] installing
Downloading plugin: 6.11 MiB / 6.11 MiB [===========================] 100.00% 0s
Moving plugin... done.

You are now ready to apply OPA-based policies to your Pulumi deployments. Create a folder for your policies named policy-kubernetes and place two files in it - PulumiPolicy.yaml and kubernetes.rego.

Your PulumiPolicy.yaml should look like this. Note that it specifies the runtime to use for the policy rules is opa.

description: A minimal Policy Pack for Kubernetes using OPA.
runtime: opa

Your kubernetes.rego should look like this.

package kubernetes

name = input.metadata.name

labels {
 input.metadata.labels["app.kubernetes.io/name"]
 input.metadata.labels["app.kubernetes.io/instance"]
 input.metadata.labels["app.kubernetes.io/version"]
 input.metadata.labels["app.kubernetes.io/component"]
 input.metadata.labels["app.kubernetes.io/part-of"]
 input.metadata.labels["app.kubernetes.io/managed-by"]
}

deny[msg] {
 input.kind = "Deployment"
 not labels
 msg = sprintf("%s must include Kubernetes recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels ", [name])
}

The rule above uses the standard OPA Rego language to express a rule that enforces that any Deployment resource in Kubernetes must have a set of defined labels applied to it. All OPA rules used in Pulumi will be applied to an input object, which is a JSON representation of the resource inputs for the Pulumi resource being validated. In particular, for a Kubernetes Deployment resource, this will have top level kind, apiVersion, metadata, and spec fields which can be used to query aspects of the resource for policy enforcement.

To test our rule, we can create a new Pulumi Kubernetes project and deploy it with the policy enforced.

First we create a new project kubeapp in a sibling folder:

$ cd .. && mkdir kubeapp && cd kubeapp
$ pulumi new kubernetes-typescript

This will create a project that deploys a single Kubernetes Deployment (but without our required labels!).

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

const appLabels = { app: "nginx" };
const deployment = new k8s.apps.v1.Deployment("nginx", {
 spec: {
 selector: { matchLabels: appLabels },
 replicas: 1,
 template: {
 metadata: { labels: appLabels },
 spec: { containers: [{ name: "nginx", image: "nginx" }] }
 }
 }
});
export const name = deployment.metadata.name;

We can deploy this to any Kubernetes cluster (configure your kubectl context locally to point at the desired cluster) with our policy applied with:

$ pulumi up --policy-pack ../policy-kubernetes
Previewing update (dev):
Type Name Plan Info
+ pulumi:pulumi:Stack simple-kubernetes-dev create 1 error
+ └─ kubernetes:apps:Deployment nginx create
Diagnostics:
pulumi:pulumi:Stack (simple-kubernetes-dev):
error: preview failed
Policy Violations:
[mandatory] kubernetes v0.0.1 deny (nginx: kubernetes:apps/v1:Deployment)
nginx-me0llhgr must include Kubernetes recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels

Note that the preview fails because the policy was violated, preventing me from deploying this resource to my cluster!

The policy defined above has a “mandatory” policy, defined in OPA with deny. We can also define “advisory” policies using warn rules. For example, if we changed our policy from deny to warn and rerun - we will see the preview succeed:

$ pulumi up --policy-pack ../policy-kubernetes
Previewing update (dev2):
Type Name Plan
+ pulumi:pulumi:Stack simple-kubernetes-dev2 create
+ └─ kubernetes:apps:Deployment nginx create
Policy Violations:
[advisory] kubernetes v0.0.1 warn (nginx: kubernetes:apps/v1:Deployment)
nginx-ylgvoqpk must include Kubernetes recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels

In the previous examples, we manually applied our policy to our deployment with the --policy-pack option. But we can also publish our policy pack to the Pulumi Service and configure it to be enforced across our organization. To do, go back to the policy folder and run pulumi policy publish.

$ cd ../policy-kubernetes
$ pulumi policy publish
Obtaining policy metadata from policy plugin
Compressing policy pack
Uploading policy pack to Pulumi service
Publishing "kubernetes" to "lukehoban"
Published as version 2
Permalink: https://app.pulumi.com/lukehoban/policypacks/kubernetes/2

You can now navigate into the Pulumi Service and configure the new policy to be part of the “default” policy pack (or create a new one), and applied to all stacks in your Organization (or select specify stacks to enforce the policy on).

We can now run our deployment without the --policy-pack argument and our policy will still be enforced on this deployment (and any others done by any other users in our organization)!

$ pulumi up
Previewing update (dev2):
Installing policy pack kubernetes 2...
Finished installing policy pack
Type Name Plan
+ pulumi:pulumi:Stack simple-kubernetes-dev2 create
+ └─ kubernetes:apps:Deployment nginx create
Policy Violations:
[advisory] kubernetes v0.0.1 warn (nginx: kubernetes:apps/v1:Deployment)
nginx-q4ilsuqq must include Kubernetes recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
Do you want to perform this update? yes
Updating (dev2):
Type Name Status
+ pulumi:pulumi:Stack simple-kubernetes-dev2 created
+ └─ kubernetes:apps:Deployment nginx created
Policy Violations:
[advisory] kubernetes v0.0.1 warn (nginx: kubernetes:apps/v1:Deployment)
nginx-6ooayw4j must include Kubernetes recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
Outputs:
name: "nginx-6ooayw4j"
Permalink: https://app.pulumi.com/lukehoban/simple-kubernetes/dev2/updates/1

We can now navigate to the URL for our update and see that the policy was enforced. Note the badge showing that this deployment was protected by policy enforcement and the list of policy violations.

Using OPA Rego with Pulumi

OPA-based rules are easy to write for Pulumi. The input object represents each individual resource that will be deployed by Pulumi, and the rules are applied independently to each Pulumi resource when it is deployed. The schema for each resource is the same as the properties available when defining the resource. Critically, although we highlighted Kubernetes above, Pulumi’s resource model spans any cloud or Kubernetes, with providers for more than 50 Cloud and SaaS platforms available. And OPA-based rules can target any or all of these in a single deployment.

For example - the policy file above could be expanded to include:

# Enforce that AWS EC2 Instance public IP is not enabled
warn[msg] {
 input.associatePublicIpAddress
 msg := "Associating public IP addresses is discouraged"
}

# Enforce that Kubernetes Pod images must be published by `hooli.com`
deny[msg] {
 input.kind == "Pod"
 image := input.spec.containers[_].image
 not startswith(image, "hooli.com/")
 msg := sprintf("image '%v' comes from untrusted registry", [image])
}

With support in Visual Studio Code, authoring both your infrastructure and policy in a rich IDE using Pulumi is also possible.

Conclusion

OPA support in Pulumi CrossGuard enables authoring cloud infrastructure policy using a familiar and popular policy authoring language while leveraging Pulumi’s CrossGuard platform for policy enforcement from development to production. Along with existing support for TypeScript, JavaScript and Python - Pulumi CrossGuard offers a great breadth of authoring languages to meet the needs of any infrastructure team.

Check out the open source pulumi-policy-opa project to learn more about the OPA integration with CrossGuard. And get started with Pulumi for your modern cloud infrastructure and policy today.

Policy as Code with Python

Sophia Parafina — Tue, 16 Jun 2020 00:00:00 +0000

Policy as Code for Python is now GA in Pulumi 2.0. Policies written in code let you test, automate deployment, and enable version control. Python is a popular scripting language used for machine learning and artificial intelligence, data science, web development, and devops. It’s an ideal language for developers and operators to use in common.

Devops benefits greatly from policy as code because policies can use software development practices and verify resources without deployments that are costly in time and money. Organizations can also gain significant benefits through cost savings, fine-grained control over infrastructure, efficient deployments, improved compliance, and better use of cloud provider native resources.

How Policy as Code Works

Policies enforce specific criteria for a resource or a set of resources (stacks). For example, a common policy is to ensure that storage is not publicly accessible over the Internet or that virtual machines must have a firewall. Policies are enforced as either advisory, which prints a warning message the resource violates the policy; or mandatory, which prevents a resource deployment if it violates the policy.

Pulumi supports two types of policies:

ResourceValidationPolicy validates inputs of individual resources in a stack before the resource is created or modified.
StackValidationPolicy validates outputs of all resources in the stack after all resources have been created or modified.

ResourceValidationPolicy and StackValidationPolicy validations run during previews and updates. During previews, resources aren’t created or modified, so the ResourceValidationPolicy and StackValidationPolicy validations see a preview of what’s going to happen (as best we can determine). With stack validation policies, the validation happens after resources have been created or modified. Modifications to resources can’t be prevented, but using mandatory enforcement results in a deployment failing (despite the modified resources). If you run pulumi preview before an update and use a mandatory StackValidationPolicy, you can catch the problems before a real deployment occurs.

The difference is described in this table:

	Resource Validation	Stack Validation
What does it check?	Individual resources	All resources in the stack
When is the check performed?	Before resources are created/modified	After all stack resources have been created/modified
What information is available?	Resource input properties	Resource output properties (Note: inputs are propagated to outputs during preview)

Now that we have the basics of policy as code let’s take a look at example policies written in Python.

Examples

Policies are validation functions that validate resources in a Pulumi stack. In the examples below, we define a function that takes ResourceValidationArgs and ReportViolation as arguments. The function checks to see what type of resource and its arguments, these are used to determine if the resource violates the policy. If the resource is not compliant, the function reports the violation, and because the enforcement level is mandatory, the resource will not be deployed.

If you’d like to try out one of the examples, you can create a policy with pulumi policy new and run locally against a Pulumi program, specify pulumi up --policy-pack <path-to-policy-pack>.

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def s3_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:s3/bucket:Bucket" and "acl" in args.props:
 acl = args.props["acl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html")

s3_no_public_read = ResourceValidationPolicy(
 name="s3-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 validate=s3_no_public_read_validator,
)

PolicyPack(
 name="aws-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 s3_no_public_read,
 ],
)

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_container_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "azure:storage/container:Container" and "containerAccessType" in args.props:
 access_type = args.props["containerAccessType"]
 if access_type == "blob" or access_type == "container":
 report_violation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources")

storage_container_no_public_read = ResourceValidationPolicy(
 name="storage-container-no-public-read",
 description="Prohibits setting the public permission on Azure Storage Blob Containers.",
 validate=storage_container_no_public_read_validator,
)

PolicyPack(
 name="azure-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_container_no_public_read,
 ],
)

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_bucket_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "gcp:storage/bucketACL:BucketACL" and "predefinedAcl" in args.props:
 acl = args.props["predefinedAcl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation("Storage buckets acl cannot be set to public-read or public-read-write.")

storage_bucket_no_public_read = ResourceValidationPolicy(
 name="storage-bucket-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on GCP Storage buckets.",
 validate=storage_bucket_no_public_read_validator,
)

PolicyPack(
 name="gcp-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_bucket_no_public_read,
 ],
)

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def no_public_services_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "kubernetes:core/v1:Service" and "spec" in args.props:
 spec = args.props["spec"]
 if "type" in spec and spec["type"] == "LoadBalancer":
 report_violation(
 "Kubernetes Services cannot be of type LoadBalancer, which are exposed to " +
 "anything that can reach the Kubernetes cluster. This likely including the " +
 "public Internet.")

no_public_services = ResourceValidationPolicy(
 name="no-public-services",
 description="Kubernetes Services should be cluster-private.",
 validate=no_public_services_validator,
)

PolicyPack(
 name="kubernetes-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 no_public_services,
 ],
)

Summary

Policy as Code is an important tool for building a secure and efficient cloud infrastructure. Pulumi lets you efficiently test resources before deployment and entire stacks when deployed. Learn more about what you can do with Policy as Code:

Benefits of Policy as Code

Sophia Parafina — Wed, 27 May 2020 00:00:00 +0000

Writing infrastructure policy in a high-level programming language helps automate and enforce best practices. When policies are written with code, you can apply software development practices such as testing, automated deployment, and version control. Cloud providers typically offer a GUI to create policies, but creating policies is not easily repeatable, nor can you version policies. Moreover, policies must be tested against a live system, which means using an existing system or configuring and deploying an ephemeral version.

While the benefits of writing policies as code are evident for developers and operators, the organizational benefits are even more significant. Organizations can realize cost savings, improved compliance, efficient deployments, fine-grained control over infrastructure, and better use of cloud provider native resources. Let’s take a look at these benefits in-depth.

Controlling Costs

A sizeable monthly cloud bill due to unused resources left running or using over-sized instances for small tasks is an industry cliché. One way to control costs is to set policies based on pricing. With pricing data online, we can calculate the cost of a resource ahead of time and create a policy that limits the amount spent to deploy it. In a previous article, we provided an example policy that finds all the resources in a deployment and calculates the total monthly cost. The policy sets the monthly cost permitted and sends a warning if the deployment exceeds it.

But what about unused or abandoned resources? We can use a cloud provider’s resources to implement a watchdog function with a policy that cleans up unused resources. In this article, we show how to use a serverless function to find unused resources daily and shut them down. We implemented this system at Pulumi and reduced our operating costs by 64%.

We can use cloud provider native tools and practices in combination with policy to control costs. Using AWS as an example, Joe Duffy wrote an article on using tags for cost tracking, automation, and organization. If you are not familiar with tags, they are a simple key/value pair applied to a resource. Tags let you manage, search, and filter resources.

The article showed how you could use your favorite programming language to tag a resource to enable cost tracking by project, stack, and cost center. Joe then demonstrated how to use policy as code to enforce tagging of resources when they are created. The article also shows how to automatically tag resources and enables resources to pass the tagging policy.

Compliance

Policy as Code is a way to enforce infrastructure policies that prevent inadvertent access to resources such as databases and storage or to enforce cost policies.

Controlling access to resources is basic infrastructure security. Leaving services open to the internet is less of a problem in production, but what about development environments? Developers often have much leeway to deploy resources when build a new application; similarly, testing environments maybe less secure than production. Furthermore, development instances may remain inadvertently available long after they have been used for development.

Controlling ingress and egress to and from resources and not exposing them on the Internet is a best practice. Policies that run at the level of the organization can mitigate the likelihood of unauthorized access to resources or even data breaches. Regardless of the type of environment, whether its dev, test, production, Policy as Code can enforce best practice across the organization.

Another area of concern is securing your software supply chain. Although your infrastructure runs on a cloud provider, it is not exempt form vulnerabilities as shown by CVE-2020-8835 which allows container escape to get root privileges on the host node. On Google Cloud, nodes running on Ubuntu running Kubernetes 1.16 and 1.17 were affected. You can write a policy that checks the version of GKE and prevents those version from being deployed.

Validate Before or During Deployment

One of the shortcomings of using a cloud provider GUI to create policies is that they can only be tested on deployed resources. One solution is to implement an ephemeral environment for testing, but this incurs resource costs as wells as time spent deploying. A feature of Pulumi’s deployment engine is that it constructs a preview of the resource graph. When it creates the preview, it also tests if resources are compliant with the included policies. The policies are run before a resource is registered, and inputs (configuration parameters) are validated. Out-of-compliance resources are blocked from being created or modified by the policy.

There are cases where it is necessary to deploy a resource to test policy; for example, a resource property is required to provision another resource. For these instances, the Pulumi engine supports testing either the entire stack or selected resources. This is analogous to integration testing vs. unit testing. You can run policies against a stack as a whole, i.e., when all resources are registered and will not prevent resources that are out of compliance from being created.

In either case, your infrastructure is validated before it’s deployed, saving both time and money.

Best Practices as Policies

All cloud providers offer a set of best practices for deploying resources. Best practices can be implemented as policies, but instead of managing them as individual policies, wouldn’t it be more efficient to organized similar policies as a bundle? This is the idea behind Policy Packs. They provide a way to group similar policies based on how you manage your infrastructure. For example, you may have several policies for storage based on how they are tagged. Policy packs don’t restrict which policies you combine; you can have Kubernetes policies bundled with container registry policies. You create Policy Packs according to the requirements and needs of your organization.

You can apply a Policy Pack to a single stack of resources or across multiple stacks. A group of stacks that use the same Policy Pack is a Policy Group. Note that a stack can belong to multiple Policy Groups. A typical application of Policy Groups is to set policies for environments; for example, you might have a more permissive Policy Group for your development and staging environments and more restrictive one for production.

Policy as code enables you to deploy best practices as policies. Moreover, you can organize policies in bundles or Policy Packs based on your organizational requirements. This provides repeatable and fine-grained control over the resources you deploy. You can apply Policy Packs on individual resource stacks or across multiple stacks as Policy Groups, giving you granular control over how and which resources are deployed.

Working with Cloud Native Resources

Cloud providers have methods for managing access to resources such as IAM (Identity Access and Management) policies and ACL (Access Control Lists). This is one type of policy, but it doesn’t cover the full range of actions available for managing your infrastructure. Pulumi uses cloud provider APIs to build and maintain infrastructure. The Pulumi engine works with cloud provider resources in conjunction with Policy as Code.

In a previous article, we demonstrated how to use the IAM Access Analyzer in conjunction with Policy as Code. IAM Access Analyzer validates all resources per-region with a single analyzer. It creates a record for each problem identified and shows which policy is responsible for granting wider access to resources than would be best practice. Policy as Code applies policy packs to stacks of resources anytime infrastructure is deployed.

The IAM Access Analyzer works on deployed resources, so in the example, we have to deploy the infrastructure first before running the analyzer using a Pulumi program. When the scan of a resource is complete, it returns the detailed results that we can pass to the policy for validation. In this way, we can use cloud provider native tools in conjunction with Policy as Code to manage and protect our infrastructure.

Conclusion

We often talk about Policy as Code in terms of repeatability, versioning, and testing, which benefits developers and operators directly. The benefits extend beyond DevOps and into the success of an organization. Policy as Code provides the following organizational benefits:

means for automated cost control,
compliance to avoid downtime by securing resources,
validating infrastructure before creating resources (another cost-saving measure),
encoding best practices for resource stacks,
and working with cloud provider native resources to provide best of breed security and granular control.

Learn more about using programming languages for Policy as Code with our docs.

New Policy as Code Capabilities with CrossGuard

Erin Krengel — Tue, 05 May 2020 00:00:00 +0000

In a previous blog post, I introduced CrossGuard, Pulumi’s Policy as Code solution. As part of our 2.0 release, CrossGuard is now generally available and has some awesome new features to improve the user experience around managing Policy Packs.

General Availability

CrossGuard is enabled for enterprise organizations in the Pulumi Service, and as always, the open source offering is available for all to use.

Improved CLI support

We have added richer CLI support for CrossGuard. Organization administrators can now manage their Policy Packs from the CLI. In addition to being able to publish Policy Packs, you may now enable a Policy Pack by simply running:

$ pulumi policy enable <organization>/<pack-name> <version>

This same command can be used to upgrade a previously enabled Policy Pack.

Organization administrators may also disable a Policy Pack by running:

$ pulumi policy disable <organization>/<pack-name>

By default, the enable and disable commands use an organization’s default Policy Group. Using the --policy-group flag, you can specify another Policy Group. You can also specify latest instead of a specific Policy Pack version to enable the latest version of that Policy Pack.

Options, Parent, and Dependencies

Policies now have access to more information about the resources under review. With access to the options, parent, and dependencies of a resource, you can now write even more thorough policies.

You may access a resource’s options via the ResourceValidationArgs parameter. In the below example, we enforce that all DynamoDB tables be protected to prevent data loss.

new PolicyPack("aws-policies", {
 policies: [
 {
 name: "dyanmodb-table-protected",
 description: "DynamoDB tables must be protected.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.dynamodb.Table, (_, args, reportViolation) => {
 if (!args.opts.protect) {
 reportViolation(`DynamoDB tables must be protected to prevent data loss.`);
 }
 }),
 },
 ],
});

Access to the parent and dependencies of a resource allows you to author policies about the relationship between resources. For example, you may want to make sure that each DynamoDB table in a stack has an attached scaling policy.

new PolicyPack("aws-policies", {
 policies: [
 {
 name: "dyanmodb-table-protected",
 description: "DynamoDB tables should have an autoscaling policy.",
 enforcementLevel: "advisory",
 validateStack: (args, reportViolation) => {
 const tables = args.resources.filter(r => r.isType(aws.dynamodb.Table))

 for (const table of tables) {
 const scalingPolicies = table.dependencies.filter(r => r.isType(aws.appautoscaling.Policy));
 if (!scalingPolicies || scalingPolicies.length === 0) {
 reportViolation(`DynamoDB table ${table.name} is missing a scaling policy.`);
 }
 }
 }
 },
 ],
});

Python Support

As of our 2.0 launch, you can now author Policy Pack in Python. Our multi-language approach allows you to author a Policy Pack using our NodeJS or Python SDK and enforce the pack on a stack written in any language.

The Python-based Policy Pack prohibits public permission of Azure Storage Blob Containers.

def storage_container_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "azure:storage/container:Container" and "containerAccessType" in args.props:
 access_type = args.props["containerAccessType"]
 if access_type == "blob" or access_type == "container":
 report_violation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources")

storage_container_no_public_read = ResourceValidationPolicy(
 name="storage-container-no-public-read",
 description="Prohibits setting the public permission on Azure Storage Blob Containers.",
 validate=storage_container_no_public_read_validator,
)

PolicyPack(
 name="azure-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_container_no_public_read,
 ],
)

Configuration

And lastly, the feature I am most excited to share with you all is Configurable Policy Packs. Using configuration, you can author Policy Packs that are reusable and flexible for your organization’s various needs.

For example, you may have a policy that restricts the allowed EC2 instance types. This set of instances may vary between your non-production stack and production stacks.

new PolicyPack("aws-policies", {
 policies: [
 {
 name: "allowed-ec2-instance-type",
 description: "EC2 instance type must be of an approved type.",
 enforcementLevel: "mandatory",
 configSchema: {
 properties: {
 allowedTypes: {
 type: "array",
 default: ["t2.nano", "t2.micro", "t2.small"]
 },
 },
 },
 validateResource: validateResourceOfType(aws.ec2.Instance, (instance, args, reportViolation) => {
 const config = args.getConfig<{ allowedTypes?: string[] }>();
 if (!config.allowedTypes) {
 reportViolation(`No EC2 instance types have been approved.`);
 return;
 }
 if (!config.allowedTypes.includes(instance.instanceType)) {
 reportViolation(`EC2 type must be an allowed instance type: ${config.allowedTypes}. ` +
 `${instance.instanceType} is not allowed type.`);
 }
 }),
 },
 ],
});

Using this configuration, you can make this deviation, allowing larger, more costly instances only in production. We can enable this configurable Policy Pack for our Policy Group prod-stacks using configuration that allows for other instance types.

{
 "allowed-ec2-instance-type": {
 "allowedTypes": ["t2.medium", "t2.large"]
 }
}

To enable the pack with this configuration, we can save the JSON to a file called prod-policy-config.json and then run:

pulumi policy enable aws-policies latest --policy-group prod-stacks --config prod-policy-config.json

Alternatively, we can enable the Policy Pack from the Pulumi Service.

Configuration allows organization administrators to quickly and easily tweak Policy Packs to meet a variety of use cases.

Wrapping Up

We’ve invested in improving the user experience for authoring and managing policy. Whether you’re an enterprise customer or an open source user, you can get started by taking CrossGuard for a spin.

The Getting Started with Policy as Code webinar recording is also a excellent resource for seeing these features in action.

Automatically Enforcing AWS Resource Tagging Policies

Joe Duffy — Mon, 06 Apr 2020 00:00:00 +0000

AWS publishes best practices for how to tag your resources for cost tracking, automation, and organization. But how do you enforce that you’re doing it correctly across all of your projects? And is it really necessary to manually track down all those places where you missed a tag and manually patch things up? In this article, we’ll see how to use Policy as Code to enforce your team’s tagging strategies in addition to some powerful Infrastructure as Code techniques to automate applying your tags in a consistent way across all of your projects and resources.

Why Tag Your Resources?

A tag is simply a key/value label that you can apply to your AWS infrastructure resources. Tags enable you to manage, search for, and filter resources. There aren’t any predefined tags — you can use whatever makes sense for your scenario and business requirements.

Amazon recommends many tagging strategies, including technical tags like name and environment, automation tags like dates and security requirements, business tags like owner and cost center, and security tags for compliance. Each of these enables you to apply policies.

Specifying a tag in your Infrastructure as Code is easy. Not all resources are taggable (although the most important ones are); to tag a resource, specify a map of key/values using the tags property. For example, this code declares an S3 Bucket that carries three tags that enable cost allocation reporting: "user:Project", "user:Stack", and "user:Cost Center":

let aws = require("@pulumi/aws");
let pulumi = require("@pulumi/pulumi");

// Create an S3 bucket (with tags).
let config = new pulumi.Config();
let bucket = new aws.s3.Bucket("my-bucket", {
 tags: {
 "user:Project": pulumi.getProject(),
 "user:Stack": pulumi.getStack(),
 "user:Cost Center": config.require("costCenter"),
 },
});

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

// Create an S3 bucket (with tags).
const config = new pulumi.Config();
const bucket = new aws.s3.Bucket("my-bucket", {
 tags: {
 "user:Project": pulumi.getProject(),
 "user:Stack": pulumi.getStack(),
 "user:Cost Center": config.require("costCenter"),
 },
});

import pulumi
import pulumi_aws as aws

# Create an S3 bucket (with tags).
config = pulumi.Config()
bucket = aws.s3.Bucket('my-bucket',
 tags={
 'user:Project': pulumi.get_project(),
 'user:Stack': pulumi.get_stack(),
 'user:Cost Center': config.require('costCenter'),
 },
)

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/go/pulumi"
 "github.com/pulumi/pulumi/sdk/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Create an S3 Bucket (with tags):
 _, err := s3.NewBucket(ctx, "my-bucket", &s3.BucketArgs{
 Tags: pulumi.Map({
 "User:Project": pulumi.String(ctx.Project()),
 "User:Stack": pulumi.String(ctx.Stack()),
 "User:Cost Center": pulumi.String(config.Require(ctx, "costCenter")),
 })
 })
 return err
 }
}

using Pulumi;
using Pulumi.Aws.S3;
using System.Collections.Generic;
using System.Threading.Tasks;

class Program {
 static Task Main() {
 return Deployment.RunAsync(() => {
 // Create an S3 Bucket (with tags):
 var config = new Config();
 var bucket = new Bucket("my-bucket", new BucketArgs {
 Tags = {
 { "User:Project", Deployment.Instance.ProjectName },
 { "User:Stack", Deployment.Instance.StackName },
 { "User:Cost Center", config.Get("costCenter") },
 },
 });
 });
 }
}

In this example, we’re using the project and stack names from the current project, and requiring an explicit cost center configured using pulumi config set costCenter 11223344. Of course, this is just for illustration purposes — we can easily use anything for these keys and values.

Suppose our team requires certain tags, though: How do we ensure we don’t forget them?

Enforcing Tagging Strategies

Policy as Code is a way to enforce infrastructure policies, such as ensuring we’re not opening databases to the internet, that we’re leveraging strong encryption in all the right places, that we aren’t violating cost policies, and so on. And it’s a great way to ensure we’re tagging everything.

Imagine we forgot to tag our S3 Bucket from earlier:

// Oops -- no tags!
let bucket = new aws.s3.Bucket("my-bucket");

// Oops -- no tags!
const bucket = new aws.s3.Bucket("my-bucket");

# Oops -- no tags!
bucket = aws.s3.Bucket('my-bucket')

// Oops -- no tags!
_, err := s3.NewBucket(ctx, "my-bucket", nil)
return err

// Oops -- no tags!
var bucket = new Bucket("my-bucket");

By applying the policy defined below, deployments that are missing the required tags will fail:

This approach not only ensures we don’t forget, but if you’re an infrastructure or security engineer, you can now apply this across your team to make sure your team doesn’t forget either.

Defining our Tags Enforcer Policy

This policy is ultimately defined as a simple policy pack as follows:

let policy = require("@pulumi/policy");
let isTaggable = require("../lib/taggable").isTaggable;

new policy.PolicyPack("aws-tags-policies", {
 policies: [{
 name: "check-required-tags",
 description: "Ensure required tags are present on all AWS resources.",
 configSchema: {
 properties: {
 requiredTags: {
 type: "array",
 items: { type: "string" },
 },
 },
 },
 validateResource: (args, reportViolation) => {
 const config = args.getConfig();
 const requiredTags = config.requiredTags;
 if (requiredTags && isTaggable(args.type)) {
 const ts = args.props[tags];
 for (const rt of requiredTags) {
 if (!ts || !ts[rt]) {
 reportViolation(
 `Taggable resource '${args.urn}' is missing required tag '${rt}'`);
 }
 }
 }
 },
 }],
});

import * as policy from "@pulumi/policy";
import { isTaggable } from "../lib/taggable";

new policy.PolicyPack("aws-tags-policies", {
 policies: [{
 name: "check-required-tags",
 description: "Ensure required tags are present on all AWS resources.",
 configSchema: {
 properties: {
 requiredTags: {
 type: "array",
 items: { type: "string" },
 },
 },
 },
 validateResource: (args, reportViolation) => {
 const config = args.getConfig<AwsTagsPolicyConfig>();
 const requiredTags = config.requiredTags;
 if (requiredTags && isTaggable(args.type)) {
 const ts = args.props[tags];
 for (const rt of requiredTags) {
 if (!ts || !ts[rt]) {
 reportViolation(
 `Taggable resource '${args.urn}' is missing required tag '${rt}'`);
 }
 }
 }
 },
 }],
});

interface AwsTagsPolicyConfig {
 requiredTags?: string[];
}

This project defines a policy pack containing a set of policy rules, in this case, just one. That rule takes in a configurable set of tags to ensure they exist on every taggable AWS resource. If a tag is missing, a violation is reported and the deployment fails.

This leverages a library that helps to identify taggable AWS resources (see this repo for the full example code). Although this policy is written in TypeScript, it can be applied to stacks written in any language.

At this point, we can apply our policy pack to our infrastructure project in two ways: at the CLI or in the SaaS web console.

Applying Tags Enforcement in the CLI

This policy pack is configurable so that you can enforce arbitrary tags without needing to change the pack’s code, making it reusable. For the CLI scenario, we will create a policy-config.json file that specifies the same three required tags shown above:

{
 "all": "mandatory",
 "check-required-tags": {
 "requiredTags": [
 "user:Project",
 "user:Stack",
 "user:Cost Center"
 ]
 }
}

Next, we can manually specify that our policy pack is applied using the CLI’s --policy-pack flag, along with --policy-pack-config to point at our configuration file:

$ pulumi up \
 --policy-pack=./policy \
 --policy-pack-config=./policy-config.json

Applying Tags Enforcement in the SaaS Console

It’s nice to be able to use the CLI for this — and all of that is available in open source, no matter whether you’re using the SaaS or not. However, it requires manually distributing policy packs and remembering to pass --policy-pack with the right configuration for every update.

The Pulumi Enterprise SaaS console lets you manage policy packs and apply them to your organization’s stacks in a central way — and then every update that the pack is applied to automatically runs the policy checks. Let’s give it a try.

First, let’s publish the pack:

$ pulumi policy publish
Obtaining policy metadata from policy plugin
Compressing policy pack
Uploading Policy Pack to Pulumi service
Publishing "aws-tags-policies" - version 0.0.1 to "acmepolicy"

Permalink: https://app.pulumi.com/acmepolicy/policypacks/aws-tags-policies/0.0.1

This stores the policy pack in the Pulumi SaaS:

From there, we can enable it in the UI. First, we go to our organization’s “POLICIES” tab:

Every organization gets a default policy group, and that’s what we’ll use here. However, for sophisticated scenarios, you may want multiple policy groups (for instance, to enforce different tags for your production environments than your development ones).

Let’s “ADD” the new pack. This pops a dialog we can use to select the pack, its version, and our desired Enforcement Level (we’ll pick “mandatory”):

Finally, further down in the dialog, we can enter the tags we’d like to enforce:

Now that it is configured, all subsequent updates across the organization will run policy checks.

Enforce policy as code

Write policy as code with Pulumi to catch missing tags, block risky configurations, and keep every deployment compliant across your team.

Get started

Automatically Applying Tags

In all cases, after manually fixing our bucket, and adding the correct tags, the policy will pass:

This is great — we can now rest assured that all taggable AWS resources will be tagged before we provision them. But it sure is tedious to add these tags to every resource and then get policy violations errors anytime we forget. One of the advantages of using Infrastructure as Code is that we can automate the injection of these tags.

To do that, let’s write a function that detects taggable resources and merges in automatic tags:

let pulumi = require("@pulumi/pulumi");
let isTaggable = require("./taggable").isTaggable;

/**
 * registerAutoTags registers a global stack transformation that merges a set
 * of tags with whatever was also explicitly added to the resource definition.
 */
module.exports = {
 registerAutoTags: function (autoTags) {
 pulumi.runtime.registerStackTransformation((args) => {
 if (isTaggable(args.type)) {
 args.props["tags"] = Object.assign(args.props["tags"], autoTags);
 return { props: args.props, opts: args.opts };
 }
 };
 },
};

import * as pulumi from "@pulumi/pulumi";
import { isTaggable } from "./taggable";

/**
 * registerAutoTags registers a global stack transformation that merges a set
 * of tags with whatever was also explicitly added to the resource definition.
 */
export function registerAutoTags(autoTags: Record<string, string>): void {
 pulumi.runtime.registerStackTransformation((args) => {
 if (isTaggable(args.type)) {
 args.props["tags"] = { ...args.props["tags"], ...autoTags };
 return { props: args.props, opts: args.opts };
 }
 return undefined;
 });
}

import pulumi
from taggable import is_taggable

# registerAutoTags registers a global stack transformation that merges a set
# of tags with whatever was also explicitly added to the resource definition.
def register_auto_tags(auto_tags):
 pulumi.runtime.register_stack_transformation(lambda args: auto_tag(args, auto_tags))

# auto_tag applies the given tags to the resource properties if applicable.
def auto_tag(args, auto_tags):
 if is_taggable(args.type_):
 args.props['tags'] = {**(args.props['tags'] or {}), **auto_tags}
 return pulumi.ResourceTransformationResult(args.props, args.opts)

package main

import (
 "reflect"

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

// registerAutoTags registers a global stack transformation that merges a set
// of tags with whatever was also explicitly added to the resource definition.
func registerAutoTags(ctx *pulumi.Context, autoTags map[string]string) {
 ctx.RegisterStackTransformation(
 func(args *pulumi.ResourceTransformationArgs) *pulumi.ResourceTransformationResult {
 if isTaggable(args.Type) {
 // Use reflection to look up the Tags property and merge the auto-tags.
 ptr := reflect.ValueOf(args.Props)
 val := ptr.Elem()
 tags := val.FieldByName("Tags")

 var tagsMap pulumi.Map
 if !tags.IsZero() {
 tagsMap = tags.Interface().(pulumi.Map)
 } else {
 tagsMap = pulumi.Map(map[string]pulumi.Input{})
 }
 for k, v := range autoTags {
 tagsMap[k] = pulumi.String(v)
 }
 tags.Set(reflect.ValueOf(tagsMap))

 return &pulumi.ResourceTransformationResult{
 Props: args.Props,
 Opts: args.Opts,
 }
 }
 return nil
 },
 )
}

static ResourceTransformation RegisterAutoTags(Dictionary<string, string> autoTags) {
 return args => {
 if (IsTaggable(args.Resource.GetResourceType())) {
 // Use reflection to look up the Tags property and merge the auto-tags.
 var tagp = args.Args.GetType().GetProperty("Tags");
 var tags = (InputMap<object>)tagp.GetValue(args.Args, null) ?? new InputMap<object>();
 foreach (var tag in autoTags) {
 tags[tag.Key] = tag.Value;
 }
 tagp.SetValue(args.Args, tags, null);
 return new ResourceTransformationResult(args.Args, args.Options);
 }
 return null;
 };
}

Now we can go back to our main program, use this new module, remove the explicit tags, and every taggable AWS resource we create will automatically get the tags we’ve specified:

let aws = require("@pulumi/aws");
let pulumi = require("@pulumi/pulumi");
let registerAutoTags = require("./autotag".registerAutoTags);

// Automatically inject tags.
let config = new pulumi.Config();
registerAutoTags({
 "user:Project": pulumi.getProject(),
 "user:Stack": pulumi.getStack(),
 "user:Cost Center": config.require("costCenter"),
});

// Create a bunch of AWS resources -- with auto-tags!

let bucket = new aws.s3.Bucket("my-bucket");

let group = new aws.ec2.SecurityGroup("web-secgrp", {
 ingress: [
 { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 ],
});

let server = new aws.ec2.Instance("web-server-www", {
 instanceType: "t2.micro",
 ami: "ami-0c55b159cbfafe1f0",
 vpcSecurityGroupIds: [ group.id ],
});

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";
import { registerAutoTags } from "./autotag";

// Automatically inject tags.
const config = new pulumi.Config();
registerAutoTags({
 "user:Project": pulumi.getProject(),
 "user:Stack": pulumi.getStack(),
 "user:Cost Center": config.require("costCenter"),
});

// Create a bunch of AWS resources -- with auto-tags!

const bucket = new aws.s3.Bucket("my-bucket");

const group = new aws.ec2.SecurityGroup("web-secgrp", {
 ingress: [
 { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 ],
});

const server = new aws.ec2.Instance("web-server-www", {
 instanceType: "t2.micro",
 ami: "ami-0c55b159cbfafe1f0",
 vpcSecurityGroupIds: [ group.id ],
});

import pulumi
import pulumi_aws as aws
from autotag import register_auto_tags

# Automatically inject tags.
config = pulumi.Config()
register_auto_tags({
 'user:Project': pulumi.get_project(),
 'user:Stack': pulumi.get_stack(),
 'user:Cost Center': config.require('costCenter'),
})

# Create a bunch of AWS resources -- with auto-tags!

bucket = aws.s3.Bucket('my-bucket')

group = aws.ec2.SecurityGroup('web-secgrp',
 ingress=[
 { 'protocol': 'tcp', 'from_port': 22, 'to_port': 22, 'cidr_blocks': ['0.0.0.0/0']},
 { 'protocol': 'tcp', 'from_port': 80, 'to_port': 80, 'cidr_blocks': ['0.0.0.0/0']},
 ],
)

server = aws.ec2.Instance('web-server-www',
 instance_type='t2.micro',
 ami='ami-0c55b159cbfafe1f0',
 vpc_security_group_ids=[ group.id ],
)

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/go/aws/ec2"
 "github.com/pulumi/pulumi-aws/sdk/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/go/pulumi"
 "github.com/pulumi/pulumi/sdk/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Automatically inject tags.
 RegisterAutoTags(ctx, map[string]string{
 "User:Project": ctx.Project(),
 "User:Stack": ctx.Stack(),
 "User:Cost Center": config.Require(ctx, "costCenter"),
 })

 // Create a bunch of AWS resources -- with auto-tags!

 _, err := s3.NewBucket(ctx, "my-bucket", nil)
 if err != nil {
 return err
 }

 grp, err := ec2.NewSecurityGroup(ctx, "web-secgrp", &ec2.SecurityGroupArgs{
 Ingress: ec2.SecurityGroupIngressArray{
 ec2.SecurityGroupIngressArgs{
 Protocol: pulumi.String("tcp"),
 FromPort: pulumi.Int(80),
 ToPort: pulumi.Int(80),
 CidrBlocks: pulumi.StringArray{pulumi.String("0.0.0.0/0")},
 },
 },
 })
 if err != nil {
 return err
 }

 _, err = ec2.NewInstance(ctx, "web-server-www", &ec2.InstanceArgs{
 InstanceType: pulumi.String("t2.micro"),
 Ami: pulumi.String("ami-0c55b159cbfafe1f0"),
 VpcSecurityGroupIds: pulumi.StringArray{grp.ID()},
 })
 return err
 }
})

using Pulumi;
using Pulumi.Aws.Ec2;
using Pulumi.Aws.Ec2.Inputs;
using Pulumi.Aws.S3;
using System.Collections.Generic;
using System.Reflection;

class MyStack : Stack {
 static Config config = new Config();

 public MyStack() : base(
 new StackOptions {
 ResourceTransformations = {
 RegisterAutoTags(new Dictionary<string, string> {
 { "User:Project", Deployment.Instance.ProjectName },
 { "User:Stack", Deployment.Instance.StackName },
 { "User:Cost Center", config.Require("costCenter") },
 }),
 },
 }
 )
 {
 // Create a bunch of AWS resources -- with auto-tags!

 var bucket = new Bucket("my-bucket", new BucketArgs());

 var grp = new SecurityGroup("web-secgrp", new SecurityGroupArgs {
 Ingress = {
 new SecurityGroupIngressArgs {
 Protocol = "tcp", FromPort = 80, ToPort = 80, CidrBlocks = {"0.0.0.0/0"},
 },
 }
 });

 var srv = new Instance("web-server-www", new InstanceArgs {
 InstanceType = "t2.micro",
 Ami = "ami-0c55b159cbfafe1f0",
 VpcSecurityGroupIds = { grp.Id },
 });
 }

 // ...
}

Notice that we didn’t specify any tags by hand for the resource definitions and yet if we run a pulumi preview --diff, we see that the correct tags are applied automatically, thanks to the global stack transformation:

And running an ordinary update now passes:

Try adding some resources of your own — VPCs, EC2 instances, security groups, EKS clusters, anything — and it will automatically get tagged with these same cost center tags.

In Conclusion

In this post, we’ve seen some ways to enforce AWS tagging best practices. This includes manually applying tags using Infrastructure as Code, checking that the desired tags are applied to the relevant resources using Policy as Code, and even using some advanced techniques to automatically tag resources, reducing manual efforts and the chance of human error.

Check out these resources to get started with Pulumi’s open source platform:

Good luck making sure your team’s resources are tagged early and often with less manual effort!

Manage Any Infrastructure with Policy as Code

Sophia Parafina — Tue, 18 Feb 2020 00:00:00 +0000

In an earlier article, we introduced examples of Policy as Code to prevent two of the most common causes of data breaches. Policies are the guardrails of infrastructure. They control access, set limits, and manage how infrastructure operates. In many systems, policies are created by clicking on a GUI, making it difficult to replicate or version. Pulumi implements policy by writing it in Typescript, which ensures that you can write policies using software development practices such as automated testing, deployment, and version control.

Gareth Rushgrove said in a QCon presentation:

“My policy kit doesn’t need to just be about bits on disk and packages, and files, and my SSH config, and my firewall rules, and my network rules. It can be about my cloud instances and how they’re actually configured and set up at the API level. Ultimately, there’s an API somewhere, and I have a bunch of resources, and I want to set some policies about them.”

Pulumi released the CrossGuard preview last fall. CrossGuard lets you verify, enforce, and apply custom policies on resources in your infrastructure. You can run policies against any Pulumi stack, which means that you can apply policies written in TypeScript to stacks written in any language supported by Pulumi such as Python, Go, and .NET languages. Policy Packs are bundles of policies, and when you run pulumi up, CrossGuard evaluates every resource in the stack against the Policy Pack. CrossGuard works in AWS, Azure, Google Cloud Platform, and Kubernetes.

The CrossGuard preview provides the following key features:

Policy SDK for coding custom policies using TypeScript or Javascript
Running a Policy Pack locally to speed up development and testing of policies. Validate infrastructure before deployment.
AWSGuard is a ready-to-apply playbook for enforcing AWS best practices for security, reliability, and cost
Apply a Policy Pack across an organization to validate all the infrastructure deployed

CrossGuard ensures that you can enforce best practices for cost, compliance, security, and team practices for a single project or across your organization. Let’s look at how we can apply policies to infrastructure deployed across cloud providers and Kubernetes.

Controlling cost on AWS

The amount of an AWS monthly bill has become a cliché in the tech industry. From services using improperly sized AMIs to orphaned infrastructure left running, there are many ways to incur a huge bill. One way to limit infrastructure spend is to set a not to exceed policy. We want to calculate the costs before deployment. The pricing data is available online, but calculating the cost using configuration data to enumerate resources and services can be a manual process. However, if your infrastructure as code solution is Pulumi, you can use your preferred programming language to calculate the cost before deployment and check it against your policy.

The example below shows how the policy finds all the instances and validates the aggregate cost against the maximum monthly amount allowed. It does this by finding the monthly on-demand price and aggregating all the costs.

import * as aws from "@pulumi/aws";
import { PolicyPack, validateStackResourcesOfType } from "@pulumi/policy";
import { getMonthlyOnDemandPrice, formatAmount } from "./utils";
import { maxMonthlyCost } from "./config";

new PolicyPack("aws", {
 policies: [
 {
 name: "instance-cost-estimate",
 description: `Limit instance costs to $${maxMonthlyCost}.`,
 enforcementLevel: "mandatory",
 validateStack: validateStackResourcesOfType(aws.ec2.Instance, (instances, args, reportViolation) => {
 // Aggregate costs.
 let totalMonthlyAmount = 0;
 instances.forEach(instance => {
 totalMonthlyAmount += getMonthlyOnDemandPrice(instance.instanceType);
 });

 if (totalMonthlyAmount > maxMonthlyCost) {
 reportViolation(`Estimated monthly cost [${formatAmount(totalMonthlyAmount)}] exceeds [${formatAmount(maxMonthlyCost)}].`);
 }
 }),
 }
 ],
});

Setting the maximum amount and calculating the monthly on-demand price for all ec2 instances is aided by two helper classes config and utils. You can set variables such as maxMonthlyCost in config.ts. The utils can calculate costs from either a static file of prices, as demonstrated in the example, or through the Amazon Pricing API. Because we’re using a modern programming language, we can go beyond what a policy encoded in YAML or JSON can do.

config.ts

export const maxMonthlyCost = 500;

utils.ts

import * as fs from "fs";
import * as zlib from "zlib";

/**
* Cost-related helpers
*/
export const getPricingData = function (): (any) {
 const localFilePath = "./offers-ec2-us-east-1.json.gz";
 if (!fs.existsSync(localFilePath)) {
 throw new Error();
 }
 const localPricingDataGz = fs.readFileSync(localFilePath);
 const localPricingData = zlib.gunzipSync(localPricingDataGz);
 return JSON.parse(localPricingData.toString());
}

export const getMonthlyOnDemandPrice = function (instanceType: string): (number) {
 const pricingData: any = getPricingData();
 const pricingDataProducts: any = pricingData["products"];
 const pricingDataTermsOnDemand: any = pricingData["terms"]["OnDemand"];

 const arrValues = Array.from(Object.values(pricingDataProducts));
 const skus: any[] = arrValues.filter((it: any) =>
 it["attributes"]["instanceType"] === instanceType
 && it["attributes"]["operatingSystem"] === "Linux" // TODO: use AMI to determine this
 && it["attributes"]["preInstalledSw"] === "NA"
 && it["attributes"]["usagetype"] === `BoxUsage:${instanceType}`
 );
 if (skus.length > 1) {
 console.log("Shouldn't find more than one sku. Continuing with first...");
 }
 const sku = skus[0]["sku"];

 const skuCode = `${sku}.JRTCKXETXF`; // JRTCKXETXF = On demand offer term code
 const skuPricing: any = pricingDataTermsOnDemand[sku][skuCode];

 const priceRateCode = `${skuCode}.6YS6EN2CT7`; // 6YS6EN2CT7 = Price per hour rate code
 const priceDimension: any = skuPricing["priceDimensions"][priceRateCode];

 const pricePerHour = Number(priceDimension["pricePerUnit"]["USD"]);
 const costPerMonth = pricePerHour * 24 * 30;
 return costPerMonth;
}

export const formatAmount = function (amount: number): (string) {
 return '$' + amount.toFixed(2);
}

Compliance with Azure

The breadth and depth of services provided by cloud providers are vast. Beyond infrastructure services, you can access machine learning, image recognition, and voice services. If you can think of a service, it’s very likely a product offering. However, it’s best practice to operate your infrastructure under the principle of least privilege, i.e., only allowing access to resources needed to perform a job.

Azure Cloud Computing Services provides a list of services such as blockchain, mixed reality, Internet of Things. A best security practice is not to let unknown devices attach to your network. The policy below prohibits the use of IoT services because the endpoints are potentially untrusted and could be an entry point for bad actors.

import * as azure from "@pulumi/azure";
import * as pulumi from "@pulumi/pulumi";
import { PolicyPack, ReportViolation, ResourceValidationArgs, } from "@pulumi/policy";

const policies = new PolicyPack("azure", {
 policies: [
 {
 name: "prohibited-iot",
 description: "Use of IOT services is prohibited.",
 enforcementLevel: "mandatory",
 validateResource: (args: ResourceValidationArgs, reportViolation: ReportViolation) => {
 if (args.type.startsWith("azure:iot")) {
 reportViolation(`Use of [${args.type}] is prohibited.`);
 }
 },
 },
 ],
});

Control Ingress and Egress with Google Cloud Platform

Access control to resources is a fundamental part of infrastructure security. While production deployments may be tightly controlled, it’s not uncommon to spin up a dev infrastructure for testing during the development cycle. It isn’t unknown for devs to leave resources with public addresses on the Internet for a quick test and forget to tear it down after completing testing.

It’s a best practice to control ingress and egress of resources and not expose them on the Internet unless needed. The policy below issues a warning if a compute instance, or virtual machine has a public IP address, and it prohibits ingress from the public internet. When we run pulumi up or pulumi preview, the resource graph will show if either condition is met, and the deployment can be revised to follow the policies.

import * as gcp from "@pulumi/gcp";
import { validateResourceofType, PolicyPack, } from "@pulumi/policy";

const policies = new PolicyPack("gcp", {
 policies: [
 {
 name: "discouraged-gcp-public-ip-address",
 description: "Associating public IP addresses is discouraged.",
 enforcementLevel: "advisory",
 validateResource: validateResourceOfType(gcp.compute.Instance, (instance, _, reportViolation) => {
 const publicIps = instance.networkInterfaces.find(net => net.accessConfigs !== undefined);
 if (publicIps !== undefined) {
 reportViolation("`accessConfigs` should be undefined in most cases.");
 }
 }),
 },
 {
 name: "prohibited-public-internet",
 description: "Ingress rules with public internet access are prohibited.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(gcp.compute.Firewall, (firewall, _, reportViolation) => {
 const publicInternetRules = (firewall.sourceRanges || []).find(ranges =>
 ranges === "0.0.0.0/0"
 );
 if (publicInternetRules !== undefined) {
 reportViolation("`sourceRanges` should not be '0.0.0.0/0'");
 }
 }),
 },
 ],
});

Enforcing best practices with Kubernetes

Immutability was one of the fundamental concepts behind containers. All application dependencies were locked in place, guaranteeing that the application would run regardless of where it was deployed. That principle can be carried forward to Kubernetes; a deployment should pin the containers to a specific version to keep the infrastructure consistent.

During development, an application may use containers tagged latest. Given the complexity of modern applications, these containers may pass testing and go into production. It isn’t until the application is in production and a new pod spins up to replace a failing pod that the containers tagged latest break a dependency. The new pod with the latest tags would cause the application to fail. The policy example below would prevent deploying pods from using containers tagged latest.

import * as k8s from "@pulumi/kubernetes";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("k8s", {
 policies: [
 {
 name: "pin-image-versions",
 description: "Images should be pinned to a specific version",
 enforcementLevel: "advisory",
 validateResource: validateResourceOfType(k8s.apps.v1.Deployment, (deployment, _, reportViolation) => {
 (deployment?.spec?.template?.spec?.containers || []).forEach(container => {
 if (container.image && container.image.endsWith(":latest")) {
 reportViolation("Image version should not be 'latest'.");
 }
 })
 }),
 },
 ],
});

Conclusion

Whether you deploy your infrastructure on AWS, Azure, GCP, or Kubernetes, Pulumi’s CrossGuard can help manage your infrastructure. We’ve shown four policies for controlling cost on AWS, ensuring that Azure infrastructure is compliant by allowing only approved resources, controlled access to and from VMs in Google Cloud Platform, and enforced best practices on Kubernetes by pinning container versions by tag. These policies work across many different resources because they use a familiar programming language that provides the ability to create policies that can use external data sources to determine costs, reuse the same policy on different providers, and allow us to see any violations, advisory or mandatory, before deployment. Learn more about policy as code:

Getting Started With PaC

Sophia Parafina — Tue, 11 Feb 2020 00:00:00 +0000

Modern applications have brought many benefits and improvements, including the ability to scale and rapid iterations to update software. However, this has come at the cost of complexity. Modern infrastructure is composed of many resources that require detailed configuration to work correctly and securely. Even managed solutions from cloud service providers need additional configuration to ensure that services are secure and free of defects. Cloud providers, such as AWS, do allow you to create policies to ensure that applications are secure, but they are specific to resources that are already deployed. A significant benefit of Policy as Code is the ability to verify and spot problems before deploying your infrastructure.

Leaky Buckets

What do many of the most innovative companies in the modern cloud era have in common? They’ve all had massive data breaches from leaky AWS S3 Buckets. One of the most common reasons for data breaches is misconfigured AWS S3 Buckets. Both security professionals and bad actors use tools such as slurp to find open S3 buckets by just entering a domain, keyword, or even AWS credentials with the slurp CLI. Ideally, we want to proactively prevent public access to our S3 buckets before they are created.

Pulumi’s CrossGuard helps customers adhere to security best practices by checking the final state of a deployment against a set of policies and revealing any non-compliant services. CrossGuard is an SDK for writing policies for services, and it includes best practices playbooks for cloud providers such as AWS, Azure, and Google Cloud Platform. The Getting Started with PaC covers the case of leaking S3 buckets, but let’s do a quick review with an example showing how we can detect a leaky bucket before it gets deployed.

Note: If you haven’t installed Pulumi, follow the Pulumi Getting Started Start by creating an S3 bucket with Pulumi.

$ pulumi new aws-typescript

Running pulumi new creates the project files as well as the code to create a single S3 bucket. We’ll use an S3 ACL to make the bucket public by setting it to the canned ACL public-read.

const bucket = new aws.s3.Bucket("my-bucket", {
 acl: "public-read",
});

Next, we’ll create a Policy Pack, by creating a directory and making it the current working directory.

$ mkdir policypack && cd policypack

Then create the Policy Pack using pulumi policy new.

$ pulumi policy new aws-typescript

By default, this creates a policy that checks to see if the ACL sets the bucket to be publicly accessible.

new PolicyPack("aws-typescript", {
 policies: [{
 name: "s3-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 reportViolation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html");
 }
 }),
 }],
});

A policy consists of a name; a description that is displayed when the policy is violated; an enforcement level of either advisory or mandatory; and validateResource which specifies the type of resource, the resource, any arguments, and the message to report the violation.

We can test this locally using pulumi preview

$ pulumi preview --policy-pack <path-to-policy-pack-directory>

The preview will fail and return this output:

Diagnostics:
 pulumi:pulumi:Stack (test-dev):
 error: preview failed

 aws:s3:Bucket (my-bucket):
 mandatory: [s3-no-public-read] Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.
 You cannot set public-read or public-read-write on an S3 bucket. Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html

CrossGuard validated the desired state of the S3 bucket against the no-public-read policy stopped the preview. If we were deploying the S3 bucket, it would stop the deployment until the policy is met.

Exposed Databases

Like S3 buckets, exposed services are another source of data breaches. Misconfigured databases, failing to set passwords, or dev services open to the public are responsible for releases of Personal Identifiable Information (PII) that range well into the millions of customers. Many of these breaches were due to misconfigured Elasticsearch instances that were public and not secured with a password, such as the recent exposure of a Microsoft customer service database.

We’ll take the same approach that we used to secure S3 buckets. First, we’ll create an Elasticsearch deployment, write a policy, then apply it.

$ pulumi new aws-typescript

Replace index.ts with the following to deploy Elasticsearch:

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

const example = new aws.elasticsearch.Domain("example", {
 clusterConfig: {
 instanceType: "r4.large.elasticsearch",
 },
 elasticsearchVersion: "1.5",
 snapshotOptions: {
 automatedSnapshotStartHour: 23,
 },
 tags: {
 Domain: "TestDomain",
 },
});

In this example, we’ll use AWSGuard, which is a set of best practice policies for AWS. First, create a directory, change into it, and create a new policy.

$ mkdir awsguard && cd awsguard
$ pulumi policy new awsguard-typescript

The default policy enforcement level is advisory, but given the frequency of misconfigured Elasticsearch deployments, we’ll set to mandatory.

new AwsGuard({ all: "mandatory" });

When we run pulumi preview with the AWSGuard PolicyPack, we can see how it triggers violations based on best practices that can prevent data exposure.

$ pulumi preview --policy-pack ../awsguard/
Previewing update (dev):

 Type Name Plan Info
 + pulumi:pulumi:Stack elasticsearch-dev create 1 error
 + └─ aws:elasticsearch:Domain example create 2 errors

Diagnostics:
 pulumi:pulumi:Stack (elasticsearch-dev):
 error: preview failed

 aws:elasticsearch:Domain (example):
 mandatory: [elasticsearch-encrypted-at-rest] Checks if the Elasticsearch Service domains have encryption at rest enabled.
 Elasticsearch domain example-5510ef8 must be encrypted at rest.
 mandatory: [elasticsearch-in-vpc-only] Checks that the Elasticsearch domain is only available within a VPC, and not accessible via a public endpoint.
 Elasticsearch domain example-5510ef8 must run within a VPC.


Policy Packs run:
 Name Version
 pulumi-awsguard (../awsguard) (local)

Permalink: https://app.pulumi.com/spara/elasticsearch/dev/previews/bb6df58f-69aa-485a-99a4-d076bc067b84

AWSGuard flagged two recommended Elasticsearch best practices, encryption and deploying only within a VPC and not publicly. By enabling encryption at rest, unauthorized users cannot read data in Elasticseach clusters, storage, indices, and log files. By enabling Elasticsearch’s built-in encryption, your deployment follows recommended practices that comply with HIPAA and GDPR. AWS VPCs can keep the network traffic between your applications and Elasticsearch cluster within your infrastructure’s network and not over the public internet. Isolating Elasticsearch within your infrastructure can help mitigate the likelihood of data exposure.

CrossGuard available in Pulumi 2.0

The examples in this article demonstrate how to avoid common security pitfalls experienced by even large organizations. We’ve looked at the out of the box capability of CrossGuard by securing an S3 bucket and showed how best practices encoded in AWSGuard can warn of common configuration errors before deploying infrastructure. These examples provide a preview of how IaC can improve deployments by keeping your infrastructure secure.

As mentioned previously, CrossGuard is currently a technology preview. It will be GA with the release of Pulumi 2.0 with even more features, such as OPA integration, and more policy packs. We invite you to try it out and send us feedback either through Github issues or on the Pulumi Community Slack Channel.

Enforcing Different Kinds of Policies for Cloud Resources

Justin Van Patten — Thu, 19 Dec 2019 00:00:00 +0000

This post describes an early version of Pulumi CrossGuard (Policy as Code). The API and implementation details may have changed. For the most up-to-date information, please see the CrossGuard documentation.

We recently announced a new policy as code solution, CrossGuard that validates policies at deployment time. Policies are expressed as code and are used to prevent the creation of out-of-compliance resources. This allows an organization to prevent entire classes of security and reliability defects to ensure infrastructure is following best practices. Because policies are written using full-blown programming languages, it’s possible to do interesting things such as combining IAM Access Analyzer and Pulumi CrossGuard. In this post, we’ll take a closer look at the different types of policies that can be written.

Authoring Policies

A policy contains specific logic you want to enforce. For example, you may want to prevent the creation of public, world-readable storage objects on AWS S3, Azure BlobStore or other providers, or prevent the creation of a virtual machine without the proper firewalls in-place. Policies are run during pulumi preview and pulumi update, ensuring that cloud resource definitions comply.

Policies, written as validation functions, are evaluated against all resources in your Pulumi stack. If the validation function calls reportViolation, the associated resource is considered in violation of the policy.

There are two types of policies:

ResourceValidationPolicy - Validates a particular resource in a stack.
StackValidationPolicy - Validates the stack as a whole.

Let’s take a closer look at these and why you would use one over the other.

Resource Validation Policies

Pulumi CrossGuard calls ResourceValidationPolicy type policies for each resource in a stack. These policies are run before a resource is registered and thus block an out-of-compliance resource from ever being created or modified.

A resource validation function is passed args with more information about the resource (such as the resource’s type, input properties, name, and URN) and a reportViolation for reporting a policy violation. In most cases, you can use the helper function validateResourceOfType to filter the resource type you want to validate and provide stronger typing of the resource’s input properties.

The following is an example of a resource validation policy:

const ec2DetailedMonitoring: ResourceValidationPolicy = {
 name: "ec2-detailed-monitoring",
 description: "Detailed monitoring should be enabled for all EC2 instances.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.ec2.Instance, (instance, args, reportViolation) => {
 if (instance.monitoring !== true) {
 reportViolation("EC2 Instance should have monitoring enabled.");
 }
 }),
};

If you have multiple resources that require a similar policy, you can group them under one policy by setting validateResource to an array of callback functions. The example below shows a case where we want to run similar checks against multiple types of resources.

const elbLoggingEnabled: ResourceValidationPolicy = {
 name: "elb-logging-enabled",
 description: "Checks whether the Application Load Balancers and the Classic Load Balancers have logging enabled.",
 enforcementLevel: "mandatory",
 validateResource: [
 validateResourceOfType(aws.elasticloadbalancing.LoadBalancer, (loadBalancer, args, reportViolation) => {
 if (loadBalancer.accessLogs === undefined || !loadBalancer.accessLogs.enabled) {
 reportViolation("Elastic Load Balancer must have access logs enabled.");
 }
 }),
 validateResourceOfType(aws.elasticloadbalancingv2.LoadBalancer, (loadBalancer, args, reportViolation) => {
 if (loadBalancer.accessLogs === undefined || !loadBalancer.accessLogs.enabled) {
 reportViolation("Elastic Load Balancer must have access logs enabled.");
 }
 }),
 validateResourceOfType(aws.applicationloadbalancing.LoadBalancer, (loadBalancer, args, reportViolation) => {
 if (loadBalancer.accessLogs === undefined || !loadBalancer.accessLogs.enabled) {
 reportViolation("Application Load Balancer must have access logs enabled.");
 }
 }),
 ],
};

The upside to resource validation policies is that they prevent resources from being created/modified during updates. However, since resource validation policies are run before resources are created, you cannot verify things like the assigned name or properties of the “live” state the resources have. This means there are some types of policies that cannot be expressed in a resource validation policy. The good news is that there are other types of policies you can write, such as stack validation policies.

Stack Validation Policies

Policies of StackValidationPolicy are run against the stack as a whole. These policies are run after all stack resources are registered and thus do not block an out-of-compliance resource from being created or modified, but do fail the preview or update. To avoid creating out-of-compliance resources, we recommend running a preview command before an update.

However, there are cases where a policy requires a resource to exist in order to perform its validation, such as inspecting the resource’s output properties that are only available to already provisioned resources (e.g. checking if a resource’s id is referenced by another resource). In such cases, the policy can skip reporting violations during previews and only report violations during updates when the information it needs is available. Thus, the preview will succeed and the resources will be created or modified during the update, but the overall update operation will fail if any resources are in violation.

Stack validation policies also allow you to write policies that require inspecting multiple resources at once. For example, that a virtual machine and its persistent hard drive are in the same stack, and have congruent settings.

A stack validation function is passed args with information about all of the resources in the stack (such as each resource’s type, output properties, name, and URN) and a reportViolation callback for reporting a policy violation.

An example stack validation policy is shown below:

import { Resource } from "@pulumi/pulumi";
import * as q from "@pulumi/pulumi/queryable";
import * as aws from "@pulumi/aws";
import { PolicyPack, ReportViolation, StackValidation, StackValidationArgs, StackValidationPolicy } from "@pulumi/policy";

const s3BucketLoggingEnabled: StackValidationPolicy = {
 name: "s3-bucket-logging-enabled",
 description: "Checks whether logging is enabled for your S3 buckets.",
 enforcementLevel: "mandatory",
 validateStack: validateStackResourcesOfType(aws.s3.Bucket, (buckets, args, reportViolation) => {
 // First, save any bucket IDs that are being used as logging targets.
 const logBucketIDs: Set<string> = new Set();
 for (const bucket of buckets) {
 if (bucket.loggings) {
 for (const logging of bucket.loggings) {
 if (logging.targetBucket) {
 logBucketIDs.add(logging.targetBucket);
 }
 }
 }
 }

 // Then, check the buckets for violations.
 for (const bucket of buckets) {
 // Skip any buckets not provisioned (i.e., during previews).
 if (!bucket.id) {
 continue;
 }
 // If the bucket doesn't have any loggings and the bucket itself isn't being used as
 // a log target, it's in violation of the policy.
 if (!bucket.loggings || bucket.loggings.length === 0) {
 if (!logBucketIDs.has(bucket.id)) {
 // Report and associate the violation with the non-compliant bucket resource.
 reportViolation("Bucket logging must be defined.", bucket.urn);
 }
 }
 }
 }),
};

The example above checks whether logging is enabled on S3 buckets. If a bucket does not have a loggings property defined, it violates the policy unless the bucket is a logging targetBucket of another bucket. The policy check skips the check if the bucket’s id isn’t available, meaning this policy only runs during updates when the resource ids are available.

Resource Validation vs. Stack Validation

	Resource Validation	Stack Validation
What does it check?	Individual resources	All resources in the stack
When is the check performed?	Before resources are created/modified	After all stack resources have been created/modified
What information is available?	Resource input properties	Resource output properties (Note: inputs are propagated to outputs during preview)

With two different ways to write policies, you have more flexibility about how you want to describe and enforce your rules:

Use resource validation policies when you want to check individual types of resources and block them from being created or modified.
Use stack validation policies when you want to check the stack as a whole (all resources in the stack at once) after they’ve been created or modified.

Trying It Out

In this post, we’ve seen the different types of CrossGuard policies that can be written.

To give it a try, download and install Pulumi and get started with policy as code. For examples of policies, check out Pulumi CrossGuard policies for AWS (AWSGuard) or our policy examples. And as always, if you’d like to share what policies you have come up with on your own you can discuss them on the Pulumi Community Slack.

Running AWS IAM Access Analyzer at Deployment Time

Joe Duffy — Tue, 03 Dec 2019 00:00:00 +0000

Yesterday AWS announced an exciting new feature — the AWS Identity and Access Management (IAM) Access Analyzer — a service powered by automated reasoning that detects potentially-insecure access to your AWS resources, including S3 Buckets, SQS Queues, Lambdas, and more. At the same time, Pulumi announced a new policy as code solution, CrossGuard, that validates policies at deployment time. The question is: Can IAM Access Analyzer and Pulumi CrossGuard be combined to get the best of both solutions? The answer is Yes!

Fast Forward to Security By Default

Before diving into the details of how this all works, let’s see what this looks like in action.

By default, the IAM Access Analyzer runs in your account, monitoring for new resources and creating alerts as new problems are identified. This approach does not tell you as part of a deployment that a new problem has been introduced, however. In this post, we’ll use Pulumi CrossGuard to flag deployments that have introduced a new problem, so you find out about it right away.

Let’s try to create an S3 Bucket with public-read access:

import * as aws from "@pulumi/aws";
const bucket = new aws.s3.Bucket("my-bucket", {
 acl: "public-read",
});

The acl here means the S3 Bucket is available to the Internet — sometimes what you want, but usually not — and potentially a major security catastrophe waiting to happen! This is a very easy mistake to make. How do we prevent it?

Pulumi CrossGuard can stop such things. In fact, we have an AWSGuard policy pack that will enforce the best practices across all of the AWS services, out of the box, including security, compliance, and cost-based rules. That includes checking for public S3 buckets.

As AWS makes their own platform more secure by default, however, we would love to take advantage of it as soon as new features come out. And IAM Access Analyzer seems to have some very smart smarts behind it, which we would greatly benefit from, as articulated in this research paper.

Thanks to CrossGuard’s use of full-blown programming languages, we can easily tap into the AWS SDK support for IAM Access Analyzer. The result is that if we try to deploy the above program with our custom policy pack — pulumi up --policy-pack ~/iam-analyzer-policy — we get an error:

Nice! Security catastrophe averted! Now let’s dig into how it all works.

IAM Access Analyzer, Meet CrossGuard

First thing’s first: IAM Access Analyzer is new; and Pulumi CrossGuard is new. Both of them were announced just yesterday! So a lot of what we’re going to look at will evolve in the weeks to come. Nevertheless, the result is very exciting — as soon as we saw the IAM Access Analyzer announcement, we knew there could be magic in combining the two ideas.

The approaches are different but complementary:

IAM Access Analyzer uses a single analyzer per-region that validates all resources within it. For each problem it identifies, it creates a so-called “finding” which records what policy is responsible for granting wider access to specific resources than you might want.
CrossGuard, on the other hand, operates by applying individual policy packs to specific stacks of resources. This can be configured to run automatically anytime a deployment occurs in your organization, or explicitly using the --policy-pack argument shown above.

To see how they can work in partnership with one another, we will create a new CrossGuard policy pack that uses the new IAM service. We’ll walk the code step by step, but the full code is also available on GitHub.

First, we created this new policy pack with the following commands:

mkdir ~/iam-analyzer-policy
cd ~/iam-analyzer-policy
pulumi policy new aws-typescript

This populates the ~/iam-analyzer-policy directory with the scaffolding needed to create a policy pack.

By default, the template will have installed the @pulumi/pulumi, @pulumi/policy, and @pulumi/aws packages. We need some others:

npm install aws-sdk uuid

Now let’s import everything we need at the top of our index.ts file, which is where we’ll build out our policy:

import * as AWS from "aws-sdk"
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";
import { PolicyPack, ReportViolation, StackValidationArgs } from "@pulumi/policy";
import * as uuid from "uuid";

Next we’ll allocate our policy pack and its internal policies. We will only have a single rule at this time:

new PolicyPack("aws-typescript", {
 policies: [{
 name: "iam-access-analyzer",
 description: "Resource has IAM Access Analyzer errors.",
 enforcementLevel: "mandatory",
 validateStack: async (args: StackValidationArgs, reportViolation: ReportViolation) => {
 // interesting part goes here ...
 },
 }],
});

Notice we are using the validateStack callback to validate our resources. The alternative is to use validateResource, which runs on a single resource at a time. In this case, the stack-wide validation is easier, since we’ll be sharing a single IAM analyzer instance.

Let’s start filling out the validateStack function. First, during previews (indicated by the pulumi.runtime.isDryRun() function), we want to skip validation. The reason is that IAM Access Analyzer only runs against real resources already allocated. Perhaps in the future, it will let us query resources before they are created, but for now the best we can do is catch the mistake immediately afterwards. Thankfully, CrossGuard supports running both before provisioning, during previews, in addition to afterwards.

// If we're doing a dry-run, we skip this, because IAM Access Analyzer only analyzes actual resources.
// Ideally in the future, they will support scanning them *before* the problem is actually deployed!
if (pulumi.runtime.isDryRun()) {
 return;
}

Next, now that we know we’re doing an update, we want to create an IAM Access Analyzer SDK object that we can use to call the service:

// Create a fresh analyzer for this run.
const svc = new AWS.AccessAnalyzer({ region: aws.config.region || "us-east-1" });

Now we can provision the temporary analyzer itself that we’ll use for this validation pass:

const analyzerName = `iam-analyzer-${uuid.v4().toString()}`;
const resp = await svc.createAnalyzer({ analyzerName, type: "ACCOUNT" }).promise();
const analyzerArn = resp.arn!;
try {

Notice we’ve wrapped the subsequent code in a try block; you’ll see a finally below that deletes the temporary analyzer object.

Our illustration here creates and uses an IAM Access Analyzer with "ACCOUNT" scope, the only currently supported option at the time of this writing. Because of the restriction that there can only be one analyzer per account, per region, this may cause issues if you already have an analyzer pre-created, or need to run deployments in parallel. Depending on how the IAM Access Analyzer feature evolves, you may want to take a different approach than what is shown here.

Next up, we’ll look for all resource types supported by IAM Access Analyzer, and kick off a resource scan for each one:

 // Now, find all eligible resources, create a map of them, and kick off scans for each one.
 const analyzed: string[] = [];
 const analyzedUrns: {[arn: string]: string} = {};
 for (const res of args.resources) {
 let resourceArn: string | undefined;
 if ([ "aws:iam/role:Role", "aws:kms/key:Key", "aws:lambda/function:Function",
 "aws:lambda/layerFunction:LayerFunction", "aws:s3/bucket:Bucket", "aws:sqs/queue:Queue" ].
 indexOf(res.type) !== -1) {
 resourceArn = res.props.arn;
 }

 if (resourceArn) {
 await svc.startResourceScan({ analyzerArn, resourceArn }).promise();
 analyzed.push(resourceArn);
 analyzedUrns[resourceArn] = res.urn;
 }
 }

The startResourceScan function is asynchronous, so we’ll now need to wait until all of the requested resources have been analyzed. This requires us to poll the AWS API with appropriate pagination. We will wait up to 30 seconds for the results to converge:

 // Wait until all resources have been analyzed.
 const maxRetries = 30;
 for (let i = 0; i < maxRetries; i++) {
 const analyzed: {[arn: string]: boolean} = {};
 let nextToken: string | undefined;
 do {
 const result = await svc.listAnalyzedResources({ analyzerArn }).promise();
 for (const res of result.analyzedResources) {
 analyzed[res.resourceArn] = true;
 }
 nextToken = result.nextToken;
 } while (nextToken);

 let done = true;
 for (const arn of Object.keys(analyzedUrns)) {
 if (!analyzed[arn]) {
 done = false;
 break;
 }
 }
 if (done) {
 break;
 }

 if (i == maxRetries-1) {
 reportViolation(`Timed out waiting for IAM Access Analyzer results; is the region correct?`);
 return;
 } else {
 await new Promise((resolve) => setTimeout(resolve, 1000));
 }
 }

Now that we know the results are available, we simply have to list the detailed findings. In this example, our policy pack will only issue an error for every IAM configuration that leads to potentially unwanted public access. Each finding contains detailed information about the IAM resources causing unwanted access, the ARN of the target resource, and remediation information:

 // Now that the scan is ready, go ahead and list the findings, triggering errors as appropriate.
 let nextToken: string | undefined;
 do {
 const result = await svc.listFindings({ analyzerArn, nextToken }).promise();
 for (let finding of result.findings) {
 if (finding.isPublic && finding.resource) {
 // Only report violations for resources within this stack.
 const urn = analyzedUrns[finding.resource];
 if (urn) {
 reportViolation(
 `${JSON.stringify(finding.principal)} has ${finding.action} access to ` +
 `${finding.resourceType} ${finding.resource} (public) ${finding.error || ""} ` +
 `(message ID ${finding.id})`,
 urn);
 }
 }
 }
 nextToken = result.nextToken;
 } while (nextToken);

And finally, now that all of our scanning and results are available, we just need to clean up our temporary analyzer object:

} finally {
 // Ensure to delete the analyzer before returning.
 await svc.deleteAnalyzer({ analyzerName }).promise();
}

That’s it. Now we have a fully functioning policy pack that can be uploaded to our organization using pulumi policy publish, or run as shown earlier in the post with the --policy-pack flag to pulumi up or pulumi preview. The result?

mandatory: [iam-access-analyzer] Resource has IAM Access Analyzer errors.
{"AWS":"*"} has s3:ListBucket,s3:ListBucketByTags,s3:ListBucketMultipartUploads,s3:ListBucketVersions access to AWS::S3::Bucket arn:aws:s3:::my-bucket-298b5bc (public) (message ID ccaec287-92f3-4136-bb1f-f7a731efdf62)

Trying It Out

In this article, we’ve seen how to enforce AWS’s new IAM Access Analyzer policies at deployment time, using Pulumi’s new CrossGuard feature. This helps to catch security mistakes when you do a deployment — instead of later on, when the cost of a mistake is potentially significantly greater. Although both features are early and will evolve in the weeks to come, it’s nice to see it so easy to quickly combine two features the day after they were both announced, to advance the security of your infrastructure.

To give it a try, download and install Pulumi, grab the code from GitHub, and get started with policy as code, all using free open source.

Announcing CrossGuard Preview

Erin Krengel — Mon, 02 Dec 2019 00:00:00 +0000

This blog post discusses CrossGuard in “preview” status. CrossGuard is now fully released and integrated into Pulumi. For current information about Pulumi’s policy as code capabilities, please refer to the latest CrossGuard documentation.

Over the past few months, we have been hard at work on Pulumi CrossGuard, a Policy as Code solution. Using CrossGuard, you can express flexible business and security rules using code. CrossGuard enables organization administrators to enforce these policies across their organization or just on specific stacks. CrossGuard allows you to verify or enforce custom policies on changes before they are applied to your resources. CrossGuard is 100% open source and available to all users of Pulumi, including the Individual Edition. Advanced organization-wide policy management features are available to Enterprise customers.

You can run policies against any Pulumi stack, independent of the stack’s language. This means you can have policies written in TypeScript and run them against a Python-based stack. Policies are grouped in Policy Packs and run against a stack during both pulumi preview and pulumi up. Each resource in a stack is run through the Policy Pack prior to creation, meaning you can block the creation of out-of-compliance resources.

Why

Using Pulumi, developers and operators are empowered to self-provision their infrastructure and move quickly. One of our core goals is to allow you to codify best practices and share them with your team. We often hear from organization leaders that they are concerned about enforcing security and compliance best-practices. CrossGuard provides a way to automatically enforce compliance, allowing teams to operate self-sufficiently while still ensuring organization-wide requirements are met.

As an organization administrator, you may want to encourage use of smaller compute instances to optimize for cost. As a security engineer, you may want to ensure databases and other storage solutions are not publicly accessible. As a team lead, you may want to ensure your containers have reserved an appropriate amount of memory and CPU to meet your team’s requirements. Whether you’re an organization administrator, security engineer or team lead, CrossGuard provides you the capability to enforce best practice for cost, compliance, security, team practices, and much more.

Key Features

The key features available during the CrossGuard preview are:

Policy SDK to express custom policies using TypeScript or JavaScript
Run Policy Packs locally using the --policy-pack flag, available to all users
AWSGuard codifies best practices for AWS
Enforce Policy Packs across your organization or particular stacks in the Pulumi Service, for Team and Enterprise users
View policy errors and Policy Packs for an update in the Pulumi Service

Pulumi CrossGuard for Everyone

Pulumi CrossGuard has something to offer everyone in your organization.

For Organization Administrators

You want your organization to be able to move quickly and deliver business value. To do so, your team needs to be able to self-service their infrastructure. Pulumi CrossGuard gives you the peace of mind that you need to allow your team to work independently. Codify business and security policies to ensure your team meets the requirements you set forth.

For Security Engineers

There’s a lot of complexity to security and often the rest of your organization does not have all the knowledge they need to deliver software securely. Express security policies that allow you to share your knowledge and prevent issues from ending up in production.

For Developers and Operators

There are a ton of moving pieces in our ecosystems today. It is difficult to know everything about the cloud resources we use. Pulumi CrossGuard ensures you do not fall into the trap of insecure or unreasonable defaults.

CrossGuard in Action

With an understanding of what CrossGuard enables, let’s look at what that means in practice. The following is a policy pack definition that prohibits creating an AWS S3 bucket that is public readable. Our Policy Pack is not complicated. It uses a validateResourceOfType helper function to filter for the resource type we care about and reports a violation if present.

new PolicyPack("aws-typescript", {
 policies: [{
 name: "s3-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 reportViolation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html");
 }
 }),
 }],
});

We initially run pulumi preview for an S3 bucket that will pass the policy.

// Create an AWS resource (S3 Bucket)
const bucket = new aws.s3.Bucket("my-bucket");

We then modify the bucket to have its access control list (ACL) set to public-read, which will cause our bucket to be out-of-compliance.

// Create an AWS resource (S3 Bucket)
const bucket = new aws.s3.Bucket("my-bucket", {
 acl: "public-read",
});

While this is a simple demonstration of what you can do with Policy as Code, the framework is very flexible and supports much more complex policies. Our AWSGuard library is a great example of how you can use Policy as Code to write configurable policies.

Try it Today

Pulumi CrossGuard empowers everyone to build better, safer applications and infrastructure. Today, Pulumi CrossGuard is available to preview for all Pulumi users. For Enterprise organizations, administrators can opt-in to the preview via the “Policies” tab in the Pulumi Service. To get started with CrossGuard today, here are some resources:

If haven’t played around with Pulumi yet, here is Pulumi’s Getting Started tutorial.
Policy as Code Getting Started tutorial

We’ve initially released the capability to create policies with TypeScript or JavaScript (that work with Pulumi programs written in any supported language) and plan to add policy SDKs for other supported languages. We would love to hear any feedback you have! You can submit feedback via our Contact Us form or in our community slack.

Pulumi Blog: Policy as code

Enforce ISO 27001 Across Your AWS Infrastructure

Why ISO 27001 matters

How the pack maps to ISO 27001

Audit and prevent

A growing library of pre-built packs

Get started today

Try Pulumi policies

Policy Packs Can Now Access Pulumi ESC Environments

The problem

What’s new

How it works

Example: compliance API validation

Get started

Introducing the pulumi policy analyze Command for Existing Stacks

Why this command matters

Basic usage

Testing new policy packs as a developer

Using it in AI and agent workflows

Try it out

From Kubernetes Gatekeeper to Full-Stack Governance with OPA

What’s in the stable release

Kubernetes Gatekeeper compatibility

Walkthrough: Reusing policies from the gatekeeper-library

Part of the Pulumi Insights governance story

Frequently asked questions

Do I need to modify my existing Gatekeeper .rego files?

What happens with non-Kubernetes resources?

Do I need OPA installed locally?

When should I use OPA vs. TypeScript or Python for policies?

Get started

Run Pulumi Insights on Your Own Infrastructure

Insights at a glance

Why self-hosted?

How it works

Get started

Manage Cloud Visibility and Governance with Infrastructure as Code

What’s New

Insights Accounts: Discover Your Cloud Resources

Key Features

Example: Creating an AWS Insights Account

Policy Groups: Enforce Compliance at Scale

Example: Stack-Based Policy Group

Example: Account-Based Policy Group

Querying Policy Packs

Getting Started

Learn More

Enforce AWS Organizations Tag Policies with Pulumi

How it works

Getting started

Try it today

Announcing the Next Generation of Pulumi Policies: AI-Accelerated Governance for the Cloud

Part 1: Get Clean - From Thousands of Issues to a Compliant State

First, Gain Complete Visibility with the New Policy Findings Hub

The Solution to Remediation at Scale: AI-Powered Fixes with Pulumi Neo

Part 2: Stay Clean - The Universal Guardrail for Humans and AI

A New Era of Collaboration

Governance That Accelerates You

Try Pulumi Policies

New Audit Policy Scans for Pulumi Stacks

A Complete Audit Story: Cloud Accounts and IaC Stacks

Key Scenarios for Audit Scans for Stacks

How It Works

How to Get Started

A Complete Governance Picture

Try Pulumi Policies

Policy Findings Hub: Move From Alert Fatigue to Action

From Raw Data to Actionable Insights

1. The Overview Tab: A Dashboard for Leaders

2. The Compliance Tab: The Auditor and Infosec Workspace

3. The Issues Tab: The Team’s Daily Workspace

Turning Alerts into Action

Try Pulumi Policies

New Compliance Packs for CIS, NIST, and PCI DSS

More Than Just Detection: The Complete Governance Lifecycle

New and Expanded Compliance Packs

Benefits of Pre-Built Packs

Get Started Today

Try Pulumi Policies

How to Implement Robust Security Guardrails Using Policy as Code

Do I need to modify my existing Gatekeeper `.rego` files?