irsa-anywhere

README

IRSA (IAM role for service accounts ) anywhere

• Working
• Production Checklist
• Changes from the aws pod identity webhook
• References
• Pre requisites
• Deploying
• Validating
• Disabling the sampleapp

This project aims to demonstrate the use of AWS (Amazon Web Services) IRSA to associate a AWS IAM role with a kubernetes service account so that pods running in any kubernetes cluster, whether it be a local KIND cluster or a cluster on Azure/AWS/Bare-Metal can securely talk to AWS services without using static AWS IAM user credentials. (in case of nodes running on AWS, without having full access to a wide set of AWS service).

The project uses Pulumi to spin up a local KIND cluster using the pulumi-kind-provider.

| NB: The KIND provider currently needs to be built manually and installed by following the instructions here.

The project includes an optional sampleapp that can be deployed which validates that we can talk to AWS securely using a AWS IAM role.

The sampleapp deploys an AWS S3 bucket, an S3 object and IAM role that allows the kubernetes service account named irsa-test to allow access to the previously created S3 object. The irsa-test kubernetes service account is annotated with the name of the AWS IAM role, so pods using the service account can talk to S3.

Working

This setup leverages the AWS pod identity webhook project. The code creates an AWS S3 bucket to hold the OIDC discovery and public keys document and an AWS IAM OIDC provider that an AWS IAM role can trust to allow the kubernetes service account to authenticate with AWS IAM. The following features of kubernetes are leveraged for this to work:

• Service Account Token Volume Projection
• Service Account Issuer Discovery

For this example using a local KIND cluster, the default service account signing keys generated by the KIND cluster bootstrap process (done by kubeadm) is leveraged.

Production Checklist

• Use a separate service account signing key. Refer to the kube-apiserver and kube-controller-manager documentation on setting up separate service account signing keys.
• Use a project like cert-manager to automate the renewal of certs used for the pod-identity-webhook deployments, so that certs are automatically renewed close to their expiry.

Changes from the aws pod identity webhook

• The kubernetes RBAC ClusterRole permissions on certificatesigningrequests.certificates.k8s.io and the Role permissions to create/modify secrets were removed. Manually created TLS certificates are used. Follow this GitHub PR for more details.
• The MutatingWebhookConfiguration is created at v1 version with admissionReviewVersions set as v1beta1. Follow this GitHub PR for more details.

References

• AWS Pod Identity webhook self hosted docs
• OpenShift docs on using manual mode for STS

Pre requisites

Follow the Pulumi getting started docs

• pulumi cli configured
• aws credentials configured
• local docker daemon running to create a KIND cluster

Deploying

Once the pre-requisites are successfully completed, clone this repository and run:

pulumi up

follow any prompts to create a stack

this should show an output similar to this

select yes to confirm and wait for all resources to be created.

Validating

Once everything is complete you can check the logs of the sampleapp to verify that you can indeed talk to AWS.

Check the sampleapp pod

kubectl --namespace irsa-test -l "app.kubernetes.io/name=sampleapp" get pods

Check the sampleapp logs

kubectl --namespace irsa-test -l "app.kubernetes.io/name=sampleapp" logs -f

Disabling the sampleapp

Run the following

pulumi config set createSampleApp false