Skip to content

AKS to AWS using OIDC Federation

This document outlines the procedure for configuring cross-cloud trust between an Azure Kubernetes Service (AKS) cluster and AWS Identity and Access Management (IAM). This allows workloads running within AKS pods to securely assume IAM roles and access AWS resources without needing long-lived AWS credentials stored in Kubernetes secrets.

The approach mirrors the functionality of IRSA (IAM Roles for Service Accounts) in AWS EKS but adapted for AKS. AKS provides an OIDC Issuer URL which AWS IAM can trust. An IAM Role is configured to trust identities federated through this OIDC provider, and a Kubernetes Service Account in AKS is annotated with the ARN of this IAM Role. A specific component (in this case, the amazon-eks-pod-identity webhook/agent) facilitates the exchange of Kubernetes service account tokens for temporary AWS credentials.

Now instead of using the service account annotations, we add the environment variables directly in the pod. So this will eliminate the need of external helm chart (amazon-eks-pod-identity-webhook)

Backend_helm_templates

  1. In Azure: AKS Cluster exists with OIDC Issuer enabled

AKS_OIDC_issuer_Enabled

  1. In AKS: Create a service account (SA)

  2. In Azure: Get the OIDC Issuer URL.

  3. In AWS: Create a resource (an S3 bucket) to check the access.

  4. In AWS: Create an identity provider that points to the AKS OIDC Issuer URL. These providers need to be created in all AWS accounts we need access to.

AWS_IAM_Identity_Provider

  1. In AWS: Create a role providing access to the S3 bucket created above. Add Turst relationship with the OIDC issuer url.

AWS_ROLE

  1. In AKS: Annotate the SA in AKS with the IAM Role ARN that we created above.
    Now instead of using the service account annotations, we add the environment variables directly in the pod. So this will eliminate the need of external helm chart (amazon-eks-pod-identity-webhook)

  2. In AKS: Install the amazon-eks-pod-identity helm chart. This is present in argocd app https://artifacthub.io/packages/helm/jkroepke/amazon-eks-pod-identity-webhook

Now we dont need this as we add env variables in the pod

  1. In AKS: Associate the workload(pod/deployment) that uses the SA and try accessing the AWS Service in this case S3 bucket.

Terraform and other configuration

  1. We create the service account and associate aws roles to these service account from terraform
    terraform

We no longer need to associate the role with Kubernetes service accounts. When Terraform is executed, it will automatically assume the following role:

arn:aws:iam::391008507910:role/prod-aks-cicd-role

If you need to create resources in a different AWS account (e.g., backend-prod), you'll need to establish a trust relationship in the target account. Specifically, the role in the backend-prod account (e.g., arn:aws:iam::605134451993:role/prod-opentofu-role) must trust the prod-aks-cicd-role in order to allow it to assume its identity.
TRUST_RELATIONSHIP

  1. Terraform will assume backend-prod(or backend-stage) roles by default, but if you want to create resources in aother AWS accounts, you would need to create the providers in terraform and explicitly mention while creating resources in the providers block.

Below is the screhshot from terraform implemenatation
AWS_PROVIDERS

  1. Identity Provider in aws IAM were created manually. We needed these to be pre created since we need them before running terraform/tofu