The use case

In my previous post I looked at how to configure an OIDC provider for an existing EKS cluster using a single CloudFormation template.

The next step is to use the OIDC URL output of the template to configure IAM roles so that pods are able to assume them. Importantly, those roles should be restricted so they can only be assumed by pods in the intended namespace, and only by the named service account. There are guides available showing how to do this using eksctl, the AWS console or the aws-cli, but what if we aren't using CDK and wanted to keep our code as config, declarative, and entirely in YAML/JSON?

The problem is in the AssumeRolePolicyDocument section. We need to supply a Condition where the key needs to be templated with the name of the cluster. CloudFormation doesn't permit templating keys natively. Fortunately, there is a workaround.

This post will allow you to configure your EKS clusters and create pod IAM roles, all without leaving CloudFormation. It also demonstrates how to create roles that are bound to a set namespace and service account.

The repository for the example resources can be found here: https://github.com/bambooengineering/example-eks-oidc-iam-cloudformation.

Rock and role

The trick is to know that the AssumeRolePolicyDocument value in a template is specified as json. As such, we can perform a !Sub on any value we pass to it, as long as the result is a valid json string. This allows us to template the "key" part of the Condition.

The value part of the Condition applies the Principal of Least Privilege. It states that the pod must be in the namespace test-namespace, and must have the service account named test-service-account.

If a pod attempts to assume this role from another namespace or with any other service account, it will fail.

Here is how to apply the desired constraints to an IAM role using CloudFormation:

The same technique is possible with JSON templates, though much harder to read as the JSON needs to be escaped. Here is the Role part of a JSON template:

Role your own

We can now demonstrate the cluster will configure service accounts correctly by performing a test. Clone the example repo and change to that directory.

You now have access to the two test files:

• oidc-test-cloudformation.yaml. A CloudFormation template that creates a test SNS topic and IAM role that is allowed to describe that topic.
• oidc-test-kubernetes.yaml. A Kubernetes template that creates a service account, and a pod that uses that account.

Now use the CloudFormation file to set up a test role, and prove the json templating system described above:

We now have the test IAM role, preconfigured to be assumable by a pod in this cluster.

Using the second file we use kubectl to launch a pod in the cluster, and execute a command in it to describe the test SNS topic (as permitted by the test role we have created). Note, the pod has been assigned a service account that has the role annotated with eks.amazonaws.com/role-arn:

Your work here is done.

Little fluffy clouds

By keeping your configuration entirely in CloudFormation templates you can maintain a cleaner and simpler deploy pipeline, without sacrificing the necessary constraints on role usage by service account and namespace. Your boss will be pleased.

Good luck on your Kubernetes journey!