Skip to main content

Accessing AWS APIs and resources from your namespace

If you’ve created an AWS resource in your namespace and need to access it, you will need to use IAM roles for service accounts (IRSA) and attach the service account to your pod which runs your container image.

This provides your pod with access to the resources, either through the AWS CLI or AWS SDK in your application.


To use IAM roles for service accounts, you must use a supported version of the AWS SDK in your application or the AWS CLI.

The minimum supported AWS SDK and CLI versions are:

SDK Minimum version
AWS CLI 1.16.232
Go 1.23.13
Java (version 1) 1.11.704
Java (version 2) 2.10.11
.NET* 3.3.659.1
Node (version 2) 2.525.0
Node (version 3) 3.27.0
PHP 3.110.7
Python (boto3) 1.9.220
Python (botocore) 1.12.200
Ruby 3.58.0

*For .NET, you must also include AWSSDK.SecurityToken.

If your application is using a supported version, you can follow the guide below.

Using IRSA in your namespace

To use IRSA in your namespace, you need to:

  • set up the IRSA module, which creates a service account for you
  • configure the policy ARNs you want to attach to the service account
  • attach the service account to your pods

To do this, complete the following three steps:

  1. Raise and merge a PR that configures cloud-platform-terraform-irsa in your namespace:

    module "irsa" {
      source = ""
      # EKS configuration
      eks_cluster_name = var.eks_cluster_name
      # IRSA configuration
      service_account_name = "example-name"
      namespace            = var.namespace # this is also used as a tag
      # Attach the appropriate policies using a key => value map
      # If you're using Cloud Platform provided modules (e.g. SNS, S3), these
      # provide an output called `irsa_policy_arn` that can be used.
      role_policy_arns = {
        s3  = module.s3.irsa_policy_arn
        dms = module.dms.irsa_policy_arn
        sqs = module.sqs.irsa_policy_arn
      # Tags
      business_unit          = var.business_unit
      application            = var.application
      is_production          = var.is_production
      team_name              = var.team_name
      environment_name       = var.environment
      infrastructure_support = var.infrastructure_support

    As soon as this PR is merged, a service account will be created for you to use.

  2. Update your Kubernetes manifest to set the service account in your deployment:

    apiVersion: apps/v1
    kind: Deployment
      name: example
      replicas: 1
          app: example
            app: example
          serviceAccountName: example-name # use the service_account_name you set in step 1 here
          - name: example
  3. Redeploy your service

    Once you redeploy your service, your pods should have the service account attached.

    You can test this by describing a pod:

    $ kubectl describe pod $pod -n $namespace | grep "AWS_"
    AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/
    AWS_ROLE_ARN:                arn:aws:iam::000000000000:role/cloud-platform-irsa-000000000-live

    After you’ve confirmed these environment variables exist, you’re ready to start using IRSA and accessing AWS APIs and resources from the application running in your pod.

    If you’re using an up-to-date version of the AWS SDK, you should not need any further configuration.

    If you use a custom credential provider with the AWS SDK, you should refer to the AWS SDK guides to implement AssumeRoleWithWebIdentity as a credential provider.

This page was last reviewed on 23 February 2024. It needs to be reviewed again on 23 August 2024 by the page owner #cloud-platform .
This page was set to be reviewed before 23 August 2024 by the page owner #cloud-platform. This might mean the content is out of date.