You can associate an IAM role with an OpenShift service account. This OpenShift service account can then be used to run a pod providing AWS permissions to the containers. With this feature, pods on OpenShift can call AWS APIs.
Pod applications must sign their AWS API requests with AWS Security Token Service (AWS STS) as a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM). This feature provides a strategy for managing credentials for your applications. The applications in the pod’s containers can then use an AWS SDK or the AWS CLI to make API requests to authorized AWS services.
The IAM roles for service accounts feature provides the following benefits:
- Least privilege — By using the IAM roles for service accounts feature, you no longer need to provide extended permissions to the node IAM role so that pods on that node can call AWS APIs. You can scope IAM permissions to a service account, and only pods that use that service account have access to those permissions.
- Credential isolation — A container can only retrieve credentials for the IAM role that is associated with the OpenShift service account and namespace to which it belongs. A container never has access to credentials that are intended for another container that belongs to another pod or namespace.
- Auditability — Access and event logging is available through AWS tools to help provide retrospective auditing.
To enable the use of IAM Roles for OpenShift service accounts, you should configure an AWS cluster in manual mode to use Amazon Web Services Secure Token Service (AWS STS). With this configuration, the CCO uses temporary credentials for different components.
To deploy a cluster with CCO in manual mode with STS, you can check the documentation. This blog does not show how to do that. We will focus on how to use the feature to run pods with temporary, limited-privilege credentials provided by AWS STS.
ROSA Clusters
To install a ROSA cluster with STS follow the documentation.
NOTE: For ROSA Clusters already configured with STS, using the Option 2.
Prepare IAM roles and link with OpenShift service accounts
Option 1: using ccoctl tool
This is an example of a CredentialsRequest resource to create any role to use for an OpenShift service account.
apiVersion: cloudcredential.openshift.io/v1 |
It is very important to create the role with the ccoctl tool. This step is to create the IAM role and link internally to the OpenShift service account and namespace. Once it is created, the IAM role can be modified by adding or removing permissions in AWS IAM Console, running AWS IAM commands, or using an automation tool like Ansible or Terraform.
The ccoctl tool can create one or more CredentialsRequest. The tool receives a folder as parameter and processes all the CredentialsRequest yaml files in the folder. In this case, we save the file in the credrequests folder.
[root@bastion ~]# ccoctl aws create-iam-roles \ |
The command above will create a file or files with an OpenShift secret being applied in the namespace. The identity provider is the value in the pre-installation tasks, or you can get in the amazon console IAM -> Identity providers.
outputs/manual-sts-manual-sts-credentials.yaml.
apiVersion: v1 |
Also, we need to create the service(s) account(s) in the namespace
[root@bastion ~]# oc create sa sa-manual-sts
How to assume the role
Below is an example of a POD running the aws-cli to test aws sts assume-role-with-web-identity,
The pod is placing the credentials in the file /root/.aws/config and setting 2 environment variables AWS_ROLE_SESSION_NAME and AWS_REGION.
This example is not mounting directly the volume with the config file, because the path /root/.aws must be writable to let the aws-cli create the folder /root/.aws/cli/cache and store the temporary credentials if you are running aws-cli commands directly.
The pod has three requirements:
- Run with the service account in the CredentialsRequest
- Mount a volume with the secret generated after creating the CredentialsRequest
- Mount the service account token with the audience openshift
apiVersion: v1 |
With the /root/.aws/config in the pod file, we can run any AWS command, The client will request the assume role in the background and will create the temporary credentials in the directory /root/.aws/cli/cache
[root@bastion ~]# ls -l /root/.aws/ |
{ |
What happened here? The aws-cli in the background tried 3 tasks:
- Try to find the ~/.aws./credentials file if is not possible
- Try to get the role from the metadata from http://169.254.169.254/latest/meta-data/ if is not possible
- At the end, based on the file in ~/.aws/config (see below), aws-cli try to assume the role provided in combination with the environment variables that we set in the pod; AWS_REGION and AWS_ROLE_SESSION_NAME
[root@bastion ~]# cat /root/.aws/config |
Another option is run the command aws iam assume-role-with-web-identity. It is the similar behavior when you use any language SDK, like boto3 in Python.
[root@bastion]# TOKEN=$(cat /var/run/secrets/openshift/serviceaccount/token) |
{ |
Option 2: using aws-pod-identity-webhook
The ccoctl tool, as you can see, helps to create the AWS IAM Roles one or multiples with only one line of code. In cases where another area is responsible to manage the AWS IAM Roles, we can split the process.
- Other area: create AWS IAM Roles
- OpenShift: create service accounts and pods
On the side of AWS, we create the role and modify the “trust policy” to allow the pod service account to use it and attach the policy role to grant the desired permissions to the role.
{ } |
Create the service account
The service account requires some annotations, as you can see below, which is necessary for the webhook to set some environment variables inside the pod in an automatic way.
apiVersion: v1 # the minimum time is 15 minutes "900" |
Creating the pod
apiVersion: v1 |
After deploying the pod, the annotations in the service account with the aws-pod-identity-webhook, will inject the following env: variables merging with the existing ones and the volume and volumeMounts necessary to AssumeRoleWithWebIdentity.
env: |
As you can see from the two examples above, it is very easy and transparent to use the IAM roles to call AWS services from a pod using the CCO in manual mode with STS.
About the author
More like this
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit