Pulumi Blog: Rbac

Pulumi IAM Expands: Manage Access at Scale with Tags, Roles, and Teams

Devon Grove — Thu, 19 Mar 2026 10:30:00 -0700

Since the launch of Pulumi IAM with custom roles and scoped access tokens, organizations have been using fine-grained permissions to secure their automation and CI/CD pipelines. As teams scale to hundreds or thousands of stacks, environments, and accounts, the next challenge is applying those permissions efficiently.

Today, we’re introducing three new capabilities to help you manage permissions more dynamically at scale: tag-based access control, team role assignments, and user role assignments.

Why tag-based access control?

With custom roles, you can define granular permissions using fine-grained scopes. However, applying those roles still requires selecting individual stacks, environments, or accounts one by one. For organizations managing a large number of Pulumi entities, this means either granting overly broad access or spending significant time on manual configuration. Tag-based access control solves this problem.

What’s new?

Tag-based access control

You can now create rules within a custom role that dynamically grant permissions based on entity tags. This works across IaC stacks, ESC environments, and Insights accounts. For example, when a new stack is created and tagged env:prod, anyone with a role containing a matching tag-based rule automatically gets the right permissions. No manual assignment required.

A single role can include multiple tag-based rules, and they are evaluated with OR logic. If an entity matches any of the rules, the permissions are granted. Within a single rule, you can combine multiple key-value conditions with implicit AND logic for precise targeting. For example, a rule with conditions env:prod and team:payments ensures access is granted only to production resources owned by the payments team.

Team role assignments

Custom roles can now be assigned directly to teams within your Pulumi organization. When an engineer joins a team, whether manually or via SCIM provisioning, they automatically inherit the permissions defined in the team’s assigned roles.

Teams support both inline permissions (ad-hoc access to specific stacks, environments, or accounts) and role-based permissions simultaneously. You can assign multiple roles to a single team, giving you full flexibility to compose access from reusable building blocks while retaining the ability to grant one-off access where needed. If you have existing workflows built around ad-hoc assignments to teams, those continue to work exactly as before. You can adopt roles incrementally or mix both approaches on the same team.

Team admins (or users with the team:update scope) can continue to manage their team’s inline permissions as they do today. However, assigning organization-level custom roles to a team requires additional permissions: role:read and role:update.

User role assignments

Custom roles can also be assigned directly to individual organization members. This is useful for users whose responsibilities span multiple teams or require permissions beyond the existing org-level Admin, Member, and Billing Manager roles.

How permissions work together

Permissions in Pulumi IAM are additive. A user receives the union of all permissions granted to them, including permissions from roles assigned directly to them as a user and permissions from roles assigned to any team they belong to. A user on both the “SRE” and “Security” teams inherits permissions from both team roles, plus any role assigned to them individually.

How to get started

Configuring tag-based access control and role assignments is done through the Pulumi Cloud console and REST API.

1. Create a custom role with tag-based rules

In Pulumi Cloud, navigate to Settings > Access Management > Roles and create a new custom role. In the role configuration, add tag-based rules that define which entities the role should apply to.

For example, to create a role that grants write access to all production stacks:

Click Create custom role and give it a descriptive name (e.g., “Production Deployer”)
Add a permission set (e.g., Stack Write) to the role
Under entity selection, choose Tag-based rule
Set the condition: tag key env equals prod
Save the role

2. Assign the role to a team

Go to Settings > Access Management > Teams, select a team, and assign your custom role. All team members immediately inherit the defined permissions.

3. Assign a role to an individual user

For users with unique access requirements, go to Settings > Access Management > Members, select a user, and assign a custom role directly.

Enforce tagging standards with Pulumi Policy

Tag-based access control relies on consistent tagging. If a stack is missing a tag or has an incorrect value, permissions won’t be applied as expected. Pulumi Policy closes this gap by letting you enforce tagging standards as a preventative policy group, so any pulumi up on a stack with missing or invalid tags is blocked before deployment. This ensures your tag-based RBAC rules always grant the correct permissions. Policy enforces the standard, RBAC enforces the access.

To learn how to write policies that validate stack tags, see Using stack tags in policies.

Pulumi Policy currently supports tag enforcement for IaC stacks. For ESC environments and Insights accounts, tags are managed through the Pulumi Cloud console or REST API.

Availability

Tag-based access control, team role assignments, and user role assignments are available today for customers on the Pulumi Enterprise and Pulumi Business Critical plans. Check out our pricing page for more details on editions and what’s included.

Conclusion

With custom roles providing fine-grained permissions, tag-based rules enabling dynamic access policies, and the ability to assign roles directly to teams and users, Pulumi IAM now provides everything you need to implement automated, least-privilege access control at scale. We’re excited to see how you leverage these new capabilities to secure and streamline your cloud operations.

Explore the IAM documentation to get started, and share your feedback in our GitHub repository.

Learn more

Pulumi IAM Now Available for Self-Hosted Pulumi Cloud

Davide Massarenti — Wed, 14 Jan 2026 11:18:00 +0000

We’re excited to announce that Pulumi Identity and Access Management (IAM) is now available for self-hosted instances of Pulumi Cloud. This foundational security capability brings the same enterprise-grade access management we launched for Pulumi Cloud SaaS to organizations running Pulumi on their own infrastructure.

Enterprise Security for Self-Hosted Deployments

Self-hosted Pulumi Cloud customers can now leverage the full power of Custom Roles and Granular Access Tokens to implement Zero Trust security principles and least privilege access controls within their own environments. This means you can:

Define Custom Permissions with fine-grained scopes (e.g., stack:delete, environment:read) tailored to your organization’s security requirements.
Create Custom Roles by combining these permissions with specific Pulumi entities (Stacks, Environments, etc.).
Generate Scoped Organization Access Tokens that are precisely limited to the permissions defined in their associated roles, dramatically reducing the blast radius if credentials are compromised.

Secure Automation for On-Premises Infrastructure

This release is powerful for self-hosted Pulumi Cloud deployments where security and compliance requirements are often even more stringent. You can now:

Implement Least Privilege CI/CD: Scope pipeline tokens to only the actions and resources they absolutely need, ensuring your automation follows the same security standards as your infrastructure.
Enhance Compliance Posture: Demonstrate precise, auditable control over programmatic access to auditors and security teams.
Reduce Operational Risk: Limit the potential impact of compromised tokens by restricting them to specific roles and permissions.

Getting Started

Self-hosted customers can access IAM features through the same intuitive interface available in Pulumi Cloud SaaS. Navigate to Settings -> Access Management -> Roles to begin creating Custom Permissions and Custom Roles, then generate scoped Organization Access Tokens from Settings -> Access Management -> Access Tokens.

For detailed information about Pulumi IAM capabilities, including step-by-step guides and best practices, see our comprehensive announcement blog post.

Learn More

Explore the IAM & RBAC documentation to get started:

We’re committed to bringing enterprise-grade security features to all Pulumi deployments, whether in the cloud or on-premises. If you have questions or feedback, please reach out through your account representative or our GitHub repository.

Announcing Pulumi Identity and Access Management (IAM)

Germán Lena — Mon, 09 Jun 2025 00:00:00 +0000

Cloud development is accelerating at an unprecedented pace, fueled by AI and the relentless drive for innovation. But this incredible speed demands unwavering trust in your security posture. How do you empower teams to deploy rapidly and frequently without opening doors to risk or violating compliance mandates? Today, we’re thrilled to answer that critical challenge by introducing Pulumi Identity and Access Management (IAM) – a foundational new capability designed to embed robust, granular security directly into your cloud development lifecycle, enabling you to innovate both quickly and safely with Pulumi. Pulumi IAM provides the unified framework for fine-grained authorization needed to confidently manage modern cloud infrastructure and applications across the entire Pulumi Cloud platform.

Our Vision for Pulumi IAM

Pulumi IAM is a foundational investment, delivering enterprise-grade access management through a phased approach. Today’s release marks the beginning, with much more planned:

Phase 1: Granular Access Tokens & Custom Roles (Available Today)
- Define custom, reusable Permissions with fine-grained scopes (e.g., stack:delete only).
- Create Custom Roles by combining Permissions with specific Pulumi Entities (Stacks, Environments, etc.).
- Generate Organization Access Tokens scoped precisely to these Custom Roles, perfect for secure automation.
Phase 2: User & Team Role Assignment (Coming Soon)
- Leverage OIDC configuration to dynamically assume Custom Roles for secure, tokenless authentication from CI/CD systems like GitHub Actions, GitLab, and more.
- Assign these powerful Custom Roles directly to individual users and teams within your Pulumi organization.
- Implement a complete overhaul of user and team access management, moving beyond the basic Admin/Member distinctions, and enabling reusability of custom building blocks permissions and roles that work for your organization
Phase 3: Advanced Authorization & Scalability (Future Release)
- Introduce Attribute-Based Access Control (ABAC), allowing policies based on tags or other attributes of Pulumi Entities (e.g., “grant ‘dev-role’ access to all stacks tagged ’env:dev’”).
- Enable the creation of Custom RBAC Policies with conditional logic for highly specific access scenarios and reuse them
- Provide mechanisms to manage permissions across hundreds or thousands of Pulumi Entities efficiently.

A Foundation for Zero Trust & Unified Security

Pulumi IAM isn’t just another feature; it’s a foundational pillar underpinning security across the entire Pulumi Cloud ecosystem, enabling organizations to implement Zero Trust principles for their infrastructure management. Modern security models assume breaches will happen and demand rigorous verification for every access request. Static, organization-wide roles no longer suffice where separation of duties, least privilege, and compliance are paramount.

Pulumi IAM addresses these challenges by providing:

Least Privilege Enforcement: Define precisely who can do what on which specific resources, minimizing the potential impact if credentials or accounts are compromised. This is core to Zero Trust – grant only the minimum necessary access, verified at the point of action.
Granular Control Across Pulumi:
- Infrastructure as Code (IaC): Apply fine-grained controls over Pulumi Stacks
- Secrets Management: Define specific access levels for Pulumi ESC Environments.
- Insights: Manage permissions for Pulumi Insights account settings.
Secure Automation: Provide secure, least-privilege tokens and OIDC integration for CI/CD pipelines and automation, drastically reducing the risk associated with over-privileged service accounts.
Unified, Scalable Governance: Establish a consistent authorization model that simplifies administration and scales from small teams to complex enterprise environments, ensuring security doesn’t hinder velocity.

Launching Today: Granular Access Tokens via Custom Roles

This vision begins today with the initial phase of Pulumi IAM, enabling you to define Custom Roles built from fine-grained Permissions and apply them specifically to Organization Access Tokens. This initial step provides immediate, significant security benefits, particularly for automation:

True Least Privilege for CI/CD: Scope pipeline tokens to only the actions (e.g., pulumi up) and Entities (e.g., stack: myapp-prod) they absolutely need.
Reduced Blast Radius: If a scoped token is compromised, the potential damage is limited strictly to the permissions defined in its associated role.
Enhanced Compliance: Demonstrate precise control over programmatic access to auditors.

How to Get Started with Granular Access Tokens

Configuring and using Custom Roles for scoped tokens is done via the Pulumi Cloud console:

1. Define a Custom Permission (Optional)

Create reusable sets of fine-grained scopes.

As an admin, navigate to Organization Settings -> Roles -> Permissions
Follow instructions for creating a custom permission.

2. Create a Custom Role

Combine permissions with specific resources.

As an admin, navigate to Organization Settings -> Roles
Follow instructions for creating a custom role.

3. Generate a Scoped Organization Access Token

Generate an organization access token with narrowed scope.

As an admin, navigate to Organization Settings -> Access Tokens -> Organization Access Tokens.*
Click “Create token”. Provide a description. Select your Custom Role from the “Role” dropdown. Generate the token.

New Scenarios Unlocked Today

This release immediately enables more secure and compliant workflows:

Secure Multi-Environment CI/CD: A single pipeline can use different tokens based on the target environment (dev, staging, prod), each assuming a role with appropriately restricted permissions (e.g., read-only for prod dependencies, write for the target stack).
Restricted Operational Scripts: An automation script designed only to read audit logs can use a token tied to a role granting only audit_log:read permission, preventing accidental or malicious modifications.
Safer ChatOps & Tooling: Integrations like ChatOps bots can operate with tokens scoped down to only necessary actions (e.g., triggering a pulumi preview on specific stacks).

Available Today: Custom Permissions, Custom Roles, and the ability to scope Organization Access Tokens using these roles, is available now for customers on the Pulumi Enterprise and Pulumi Business Critical tiers. Explore these features in your Pulumi Cloud organization settings!

Conclusion: Building a More Secure Future

Pulumi Identity and Access Management (IAM) represents a fundamental advancement in securing cloud development lifecycles managed by Pulumi, providing the controls needed to confidently embrace speed and scale. Today’s launch of Granular Access Tokens via Custom Roles provides immediate security improvements for automation and programmatic access, laying the vital groundwork for our comprehensive IAM vision rooted in Zero Trust principles.

This empowers platform and security teams with the fine-grained control needed to implement least privilege, enhance compliance, and scale Pulumi usage securely without sacrificing velocity.

We encourage our Enterprise and Business Critical customers to explore Custom Roles and Granular Access Tokens today. Dive into the documentation and start building roles tailored to your security requirements. We welcome your feedback and feature requests in our GitHub repository. Join us as we build a more secure foundation for cloud engineering!

Learn More

Learn more about Pulumi Cloud’s new IAM & RBAC features:

IaC Best Practices: Implementing RBAC and Security

Scott Lowe — Tue, 23 May 2023 00:00:00 +0000

This post continues our series of blog posts focused on IaC best practices. In earlier posts, we introduced Zephyr Archaeotech Emporium, the fictional company that sits at the center of this series, and discussed Zephyr’s primary use case for Pulumi: managing their online retail store. You read how Zephyr’s initial use of Pulumi changed to incorporate the use of short-lived per-developer stacks. Later, as Zephyr continued to grow, you saw how Zephyr restructured their Pulumi projects and stacks, and incorporated the use of Stack References. This post is a complement to the post on structuring Pulumi projects, concentrating on the use of role-based access control (RBAC) and security in Zephyr’s multi-project configuration.

The ultimate goal of this series is to discuss best practices for using Pulumi to manage a fairly complex containerized application. You’ve seen these practices emerge over the course of the series—not all immediately, and not all right away. Structuring the blog series in this way is a deliberate decision; many best practices are “point in time” recommendations: they are context-dependent and the recommendations for any given company, like Zephyr, may change as the company and its needs change.

Evolving Project Structure to Enhance Security and Scalability

So far, you’ve read about how Zephyr started out with a single project and a single Git repository. Adding short-lived per-developer stacks, as described in the post on best practices for developer stacks and Git branches, didn’t really impact this structure. However, as the company grew, Zephyr’s project and Git repository structure evolved into its current form:

The “zephyr-infra” project handles base infrastructure (VPC and related constructs).
The “zephyr-k8s” project automates the Kubernetes platform layer, building atop the base infrastructure components supplied by the “zephyr-infra” project.
Finally, the “zephyr-app” project handles the deployment of the online retail store application onto Kubernetes, layering on top of the platform provided by the “zephyr-k8s” project.

You can review the reasons for this structure in the post on best practices for structuring Pulumi projects. One of the reasons listed in the third Zephyr blog post was security:

…security is a factor that affects how projects and stacks should be structured. In Zephyr’s case, the ability for one team to affect another team’s resources was present when everything was a single project. With multiple projects, Zephyr can use stack permissions and role-based access control (RBAC) in Pulumi Cloud to appropriately control who can affect what.

The last part of that quote—the part about being able to “appropriately control who can affect what”—is another way of describing what’s known as the principle of least privilege. If you’re unfamiliar with this term, we recommend following the link and getting more information, because the principle of least privilege stands at the core of all the recommended practices you’ll read in this post.

Pulumi supports a number of self-managed backends, including Amazon S3 (and S3-compatible servers like Minio or Ceph), Azure Blob Storage, and Google Cloud Storage. The RBAC functionality described in this post applies only to the managed Pulumi Cloud backend.

Understanding the RBAC Building Blocks in Pulumi Cloud

To understand how to secure your Pulumi projects and stacks in Pulumi Cloud, it is important to first explain the basic building blocks you’ll use:

Organization: An organization represents a customer/company within Pulumi Cloud. Generally speaking, a single company like Zephyr is represented by a single organization.
Member: Each member represents a user account that is part of an organization. In Zephyr’s case, each Zephyr employee that needs to interact with Pulumi is a member of Zephyr’s organization in Pulumi Cloud.
Team: A team is a grouping of members, and is the primary component involved in assigning per-stack permissions in the Pulumi Cloud RBAC model. How you structure teams within your organization will depend on a great many different factors we’ll explore in this post.
Stack: A stack is a separate instance of the resources created by a Pulumi program within a project. Each stack has its own independent state and its own configuration values. With respect to RBAC, each stack is a separate entity to which one or more teams can be granted permission. In Zephyr’s case, there is a long-lived production stack for each of the separate projects, and a persistent (or long-lived) test stack for each of the separate projects. There are also the per-developer stacks, which are typically short-lived.

This diagram, also used in the post on best practices for stack references, shows the stacks and projects for Zephyr’s online store:

Now, how are these different components assembled together? At its most basic level, you would use teams to group members together, and then assign stack permissions to the team. This diagram helps illustrate the idea:

A couple of important points emerge from the above diagram:

The relationship between stacks and teams is many-to-many. That is, any given stack can have many teams assigned permissions, and any given team may be assigned permissions to many stacks.
Similarly, the relationship between teams and members is also many-to-many (any given team can—and almost always will—have multiple members, and any given member can be part of multiple teams at the same time).

Assembling Security for Stacks

The first, and perhaps the most important, best practice with regards to securing your stacks is to actually use Pulumi Cloud’s RBAC functionality. While this may seem obvious, there are practical implications to this statement that are useful to explore.

Pulumi Cloud has the ability to set a default stack permission for all members of an organization. In the screenshot below, you can see that the default permission has been set to Write:

In this configuration, you are effectively disabling Pulumi Cloud’s RBAC functionality. Permissions in Pulumi Cloud are additive; that is, permissions only state what you can do, not what you can’t do. Therefore, if the default stack permission is set to Write, then assigning a team read-only permissions to a stack has no effect—because members of that team can read from the stack (by virtue of their inclusion in a team) and can write to the stack (by virtue of the default stack permission). The team members’ read-only permission is added to the default stack permission for their effective permission.

For this reason, Pulumi recommends setting the default stack permission to Read or None. Setting it to Read means that all members of the organization can see and read from stacks that aren’t their own, but can’t change or modify the others stacks. Setting it to None means that members have permissions to their own stacks by default—gaining any form of access to stacks other than their own requires being added to a team that has permissions to those stacks.

When it comes to assigning a team access to a stack, there are three options:

Stack reader (read-only access; also called “Stack reader access” in some areas of the Pulumi Cloud UI)
Stack editor (read/write access, but can’t delete the stack; also called “Stack write access” in the Pulumi Cloud UI)
Stack admin (full access; you may also see it called “Stack admin access”)

When the “Allow organization members to create stacks and transfer stacks to this organization” is checked, like in the screenshot above, then the user (organization member) that creates a stack automatically becomes the stack admin for that stack. The user’s ability to delete the stack, however, is affected by the “Allow stack admins to delete stacks” setting.

Full details on what each of these permissions grants is detailed in the projects and stacks documentation (see the “Stack Permissions” section). In accordance with the principle of least privilege, Pulumi recommends you grant the minimum level of access necessary in order for a user (organization member) to meet their job responsibilities. You accomplish this by adding the member to a team, and then granting the team the minimum level of necessary access. You can’t assign stack permissions directly to users.

Because team membership is central to the use of stack permissions, Pulumi has several ways to make it easier to manage the relationship between teams and stacks:

You can use the Pulumi Cloud user interface to assign a team access to a stack.
You can use Pulumi Cloud’s REST API to control team access to stacks.
You can use the Pulumi Cloud provider for Pulumi to programmatically manage team access to a stack using Pulumi itself.
You can use the --teams flag to pulumi stack init to assign stack editor access to one or more teams when you create the stack.

In general, Pulumi recommends declaratively managing your Pulumi Cloud RBAC configuration with the Pulumi Cloud provider (formerly known as the Pulumi Service provider), unless you have specific requirements that would prevent it. However, be aware that the Pulumi Cloud provider doesn’t allow you to change a member’s role in an organization (every member is either a “member” or an “admin” within an organization); that would have to be done via the Pulumi Cloud user interface or REST API.

Pulumi also recommends using the --teams flag with pulumi stack init to ensure that new stacks are properly assigned team permissions upon creation. You can then go back and fine-tune those team permissions—which are set to “Stack editor” or “Stack write access” when you use the --teams flag—using a Pulumi program with the Pulumi Cloud provider. Alternately, teams can use a team access token when creating a new stack, and that will also grant the team permission to the newly-created stack.

Finally, Pulumi recommends allowing users to create their own stacks. Otherwise, only an organization admin would be allowed to create new stacks, and this is likely to cause a bottleneck in provisioning cloud infrastructure—one of the very issues that infrastructure as code tools like Pulumi are attempting to solve! (It may be necessary in some cases to restrict this functionality, such as in certain highly regulated industries or verticals.) Preventing users from creating their own stacks would also prevent the use of per-developer stacks like Zephyr uses, which as you’ve seen can be enormously helpful in accelerating development and deployment velocity.

Inspecting RBAC Implementation

Zephyr’s RBAC implementation in Pulumi Cloud is represented in part by a diagram that you also saw earlier in this post:

Zephyr set the organization default stack permission to Read. This enabled teams to read all stacks, and enabled the continued use of stack references without any additional configuration. Teams were created to grant “Stack editor” (also called “Stack write access”) to stacks based on the overall organizational structure of the company. Thus, the Platform team gained access to the non-production zephyr-infra and zephyr-k8s stacks, while the Application team was given access to the non-production zephyr-app stacks. However, only members of the Production team were given access to the production stacks in all three projects, ensuring that access to update those stacks—and thus the actual resources running Zephyr’s online store—remained relatively controlled.

Summarizing Best Practices: RBAC & Security

The post covered the following guidelines for securing your stacks in Pulumi Cloud:

Use Pulumi Cloud’s RBAC functionality by setting your organization’s default stack permissions to Read or None. This is generally the safest way to implement the principle of least privilege, unless you have a good use case for allowing all organization members full write access to all stacks.
When assigning team permissions, grant the minimum level of access necessary. If a user isn’t responsible for making updates to a stack, then give that user stack reader permission through a team membership (remember that you can’t assign stack permissions directly to organization members, you have to use a team). Keep in mind, though: if the organization level stack permission has been set to Read, then members already have the equivalent of stack reader permissions on all stacks, so creating a team to grant stack reader permission is unnecessary and superfluous.
Declaratively manage your Pulumi Cloud RBAC configuration where possible using the Pulumi Cloud provider from within a Pulumi program.
Use the --teams flag with pulumi stack init to ensure that teams have stack permissions upon stack creation. You can also use a team access token to accomplish the same result.
Allow users to create their own stacks. Generally, turning this functionality off (found in the Settings > Access Management screen of Pulumi Cloud) will end up creating a bottleneck, as only organization admins would be allowed to create new stacks.

In the next IaC Best Practices post, the focus is on Automation API. Stay tuned to see how Zephyr uses Automation API to further streamline and automate the deployment of their cloud resources!

Access Control for Pods on Amazon EKS

Mike Metral — Tue, 02 Jun 2020 00:00:00 +0000

Amazon EKS clusters can use IAM roles and policies for Pods to assign fine-grained access control of AWS services. The AWS IAM entities map into Kubernetes RBAC to configure the permissions of Pods that work with AWS services.

Together, AWS IAM and Kubernetes RBAC enable least-privileged access for your apps, scoped to the appropriate policies and user requirements.

Overview

In <100 lines of code we’ll demonstrate how EKS Pods can use AWS IAM to create fine-grained permissions for apps that integrate with other AWS services.

Pod Access Control
Create an OIDC provider
Create IAM for a S3 app
Deploy a S3 app
Wrap-Up
Next Steps

Pod Access Control

AWS EKS supports using IAM entities in a Pod Service Account by leveraging an OIDC provider connected to the Kubernetes cluster.

Continuing with the example from the AWS blog post, when an S3 app written in Go pushes an object to a bucket with the AWS SDK, it will need write access to S3.

When a Pod is launched with a particular Service Account, the OIDC provider works with Kubernetes to verify the Pod’s identity, and in turn collaborates with the AWS Secure Token Service (STS) to grant the Pod temporary credentials to use with the IAM role.

Create an OIDC provider

Creating an OIDC provider is as simple as toggling the createOidcProvider option in the definition of your EKS cluster.

When enabled, the OIDC provider will be created and associated with the cluster’s OIDC provider URL.

import * as eks from '@pulumi/eks'

// Create an EKS cluster with default settings.
// Create and attach an OIDC provider to the cluster.
const cluster = new eks.Cluster('myCluster', {
 createOidcProvider: true,
});

Create IAM for a S3 app

We’ll use the OIDC provider URL and Amazon Resource Name (ARN) to compose the AssumeRoleWithWebIdentity, and S3 IAM policies that will be attached to a new S3 IAM role.

After the role is configured, a Service Account for the S3 Pod will be created, and annotated with the ARN of the S3 role to bind the two together.

import * as aws from '@pulumi/aws'
import * as k8s from '@pulumi/kubernetes'
import * as pulumi from '@pulumi/pulumi'

// Create a pulumi Kubernetes provider using the cluster's kubeconfig.
const k8sProvider = new k8s.Provider('k8s', {
 kubeconfig: cluster.kubeconfig.apply(JSON.stringify),
});

// Create a k8s namespace in the cluster.
const namespace = new k8s.core.v1.Namespace('apps', undefined, { k8sProvider });

// Get the OIDC provider's URL for the cluster.
const clusterOidcProvider = cluster.core.oidcProvider.url;

// Create the new IAM policy for the Service Account using the AssumeRoleWebWebIdentity action.
const saName = 's3'
const saAssumeRolePolicy = pulumi
 .all([clusterOidcProviderUrl, clusterOidcProvider.arn, appsNamespaceName])
 .apply(([url, arn, namespace]) =>
 aws.iam.getPolicyDocument({
 statements: [
 {
 actions: ['sts:AssumeRoleWithWebIdentity'],
 conditions: [
 {
 test: 'StringEquals',
 values: [`system:serviceaccount:${namespace.metadata.name}:${saName}`],
 variable: `${url.replace('https://', '')}:sub`,
 },
 ],
 effect: 'Allow',
 principals: [{identifiers: [arn], type: 'Federated'}],
 },
 ],
 })
 );

// Create a new IAM role that assumes the AssumeRoleWebWebIdentity policy.
const saRole = new aws.iam.Role(saName, {
 assumeRolePolicy: saAssumeRolePolicy.json,
});

// Attach the IAM role to an AWS S3 access policy.
const saS3Rpa = new aws.iam.RolePolicyAttachment(saName, {
 policyArn: 'arn:aws:iam::aws:policy/AmazonS3FullAccess',
 role: saRole,
});

// Create a Service Account with the IAM role annotated to use with the Pod.
const sa = new k8s.core.v1.ServiceAccount(
 saName,
 {
 metadata: {
 namespace: namespace.metadata.name,
 name: saName,
 annotations: {
 'eks.amazonaws.com/role-arn': saRole.arn,
 },
 },
 },
 { k8sProvider });

Deploy a S3 app

We’ll deploy the S3 app to use the new IAM-backed Service Account.

Once the Pod is running, the Service Account annotation will be automatically managed by a Kubernetes dynamic admission controller run by EKS on your behalf.

The AWS EKS webhook manages Pod identity, and injects STS credentials into the Pod to use with the S3 role.

With the credentials, the app can successfully upload data to S3.

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

const bucket = new aws.s3.Bucket("pod-irsa-job-bucket");
const bucketName = bucket.id;
const regionName = pulumi.output(aws.getRegion({}, {async: true})).name;
const s3Pod = new k8s.core.v1.Pod(podName,
 {
 metadata: {labels: labels, namespace: appsNamespaceName},
 spec: {
 serviceAccountName: sa.metadata.name,
 containers: [
 {
 name: podName,
 image: "amazonlinux:2018.03",
 command: ["sh", "-c",
 pulumi.interpolate`curl -sL -o /s3-echoer https://git.io/JfnGX && chmod +x /s3-echoer && echo This is an in-cluster test | /s3-echoer ${bucketName} && sleep 3600`,
 ],
 env: [
 {name: "AWS_DEFAULT_REGION", value: regionName},
 {name: "ENABLE_IRP", value: "true"},
 ],
 },
 ],
 },
 }, { provider: provider },
);

Wrap-Up

Leveraging AWS IAM for Pod workloads is a secure and effective means of limiting privileged execution, and provides a native experience for users.

Pod IAM can be extended further by also using the Kubernetes RBAC system. This allows configuring permissions for Kubernetes API resources, and handle scenarios such as limiting the namespace an IAM role can use, and what resources can be managed in the namespace.

Next Steps

Learn more about how Pulumi works with Kubernetes, and get started if you’re new.

Check out code examples for the S3 app referenced in this post, along with other access control scenarios for EKS.

Watch the video below for more details on how OIDC and Kubernetes RBAC works in EKS. We demonstrate how to deploy fluentd-cloudwatch with IAM to forward Pod logs to AWS CloudWatch.

You can also follow us on Twitter, subscribe to PulumiTV on YouTube, or join our Community Slack channel if you have any questions.