DEV Community: Eric Johnson

Using AWS Outbound Identity Federation for Azure Resources

Eric Johnson — Fri, 19 Dec 2025 17:30:20 +0000

AWS re:Invent 2025 saw several new security capabilities added for security teams to use in their AWS architecture designs. One of these new capabilities, IAM Outbound Identity Federation, addresses a missing piece in our open source Nymeria cross-cloud workload identity project design. This blog explores the AWS IAM Outbound Identity Federation configuration and the changes we've made to Nymeria, allowing a virtual machine running in AWS to access external cloud resources using an AWS-signed OpenID Connect identity token.

AWS Identity Federation Limitations

Unlike Google Cloud's workload identity pool AWS provider, Azure managed identity does not support IAM authentication with pre-signed URLs. Azure managed identity only supports external OpenID Connect (OIDC) providers, which means that workloads running in AWS could not federate into an Azure environment without using another service that can convert OIDC tokens (e.g., AWS EKS or Cognito).

Up until now, the Puma Security Nymeria cross-cloud workload identity project had examples for federating from AWS Lambda functions and EKS pods into both Azure and Google Cloud storage resources. With the 2025 pre:Invent release of IAM Outbound Identity Federation, we've now added support for an AWS EC2 instance to federate into an Azure storage resource.

The following diagram illustrates the architecture design for an AWS EC2 instance using AWS Outbound Identity Federation to access an Azure Blob storage container. The EC2 instance can now request a signed OIDC token from AWS IAM using the sts:GetWebIdentityToken API. The AWS-signed OIDC token can then be used to log in to the Azure tenant's user-assigned managed identity. Finally, the EC2 instance can use the Azure access token to access the storage container and blob objects.

AWS Outbound Identity Federation Setup

Before you can use the AWS IAM Outbound Identity Federation feature, you must enable the Outbound Identity Federation capability in your AWS account. This can be done using the AWS Management Console or the AWS Terraform provider's (v6.26.0 or later) new aws_iam_outbound_web_identity_federation resource.

# enables account level web identity federation
resource "aws_iam_outbound_web_identity_federation" "this" {}

After applying the configuration, you will see that the Outbound Identity Federation feature is enabled in the AWS IAM console, and a unique Token Issuer URL is generated for your AWS account. The token issuer URL will be important later when we configure the Azure managed identity's trust relationship.

AWS Outbound Identity Federation Permissions

To use the Outbound Identity Federation feature, create an AWS IAM role and an instance profile to attach to the EC2 instance. The role's permissions need to include the sts:GetWebIdentityToken permission to request an outbound identity token from AWS IAM.

The following Terraform configuration shows how to create an IAM policy document that includes the sts:GetWebIdentityToken permission.

data "aws_iam_policy_document" "cross_cloud" {
  statement {
    sid    = "AllowTokenVending"
    effect = "Allow"
    actions = [
      "sts:GetWebIdentityToken",
    ]
    resources = [
      "*",
    ]
  }
}

resource "aws_iam_policy" "cross_cloud" {
  name        = "nymeria-cross-cloud-token-${random_string.unique_id.result}"
  path        = "/"
  description = "IAM policy for Nymeria VM"
  policy      = data.aws_iam_policy_document.cross_cloud.json

  tags = {
    Product = "Nymeria"
  }
}

With the EC2 instance running, connect to the instance using the SSM session manager or using SSH. Once connected, use the AWS CLI to request an outbound federated identity token with the following attributes:

audience: Use the default Azure federation audience api://AzureADTokenExchange
signing algorithm: Use RS256 for RSA with SHA-256 signatures
duration seconds: Set the token validity period to 300 seconds (5 minutes)

aws sts get-web-identity-token --audience api://AzureADTokenExchange --signing-algorithm RS256 --duration-seconds 300

The output will show the signed OIDC token in the WebIdentityToken attribute and the token's expiration time in the Expiration attribute.

{
    "WebIdentityToken": "eyJraWQiOiJSU0FfMCIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0...",
    "Expiration": "2025-12-19T04:06:07.577000+00:00"
}

Azure Managed Identity Configuration

Now that we know how to request an AWS outbound identity token, we can configure the Azure managed identity to trust the AWS outbound identity provider. This involves extracting the necessary claims from the AWS identity token and using those claims to configure the Azure managed identity's federated credentials.

AWS Outbound Identity Token Claims

Start by decoding the AWS identity token using jq. We will need to extract the token's iss (issuer) and sub (subject) claims to configure the Azure managed identity's trust relationship.

JWT=$(aws sts get-web-identity-token --audience api://AzureADTokenExchange --signing-algorithm RS256 --duration-seconds 300 | jq -r '.WebIdentityToken')

jq -R 'split(".") | .[1] | @base64d | fromjson' <<< $JWT

The decoded token payload will look similar to the following example. The subject (sub) claim uniquely identifies the AWS IAM Role that the token was create for, the issuer (iss) points to the AWS account's outbound federated identity provider, and audience (aud) points to the service that will be consuming the token (in this case Azure). The AWS outbound federation token also includes additional AWS metadata in the https://sts.amazonaws.com/ claim, including the AWS VPC ID, Organization Id AWS account ID, OU Path, source region, source instance, and principal tags. These additional claims can be used to create advanced claim filters when configuring trust relationships with other cloud providers.

Note: Azure's managed identity federation does not support advanced claim filters, such as those found in the https://sts.amazonaws.com/ claim. Only the iss, aud, sub claims will be needed when configuring Azure managed identity's trust configuration below.

{
  "aud": "api://AzureADTokenExchange",
  "sub": "arn:aws:iam::123456789012:role/nymeria-cross-cloud-9zo9h8c5",
  "https://sts.amazonaws.com/": {
    "ec2_instance_source_vpc": "vpc-1234567890123456",
    "ec2_role_delivery": "2.0",
    "org_id": "o-abcd1234",
    "aws_account": "123456789012",
    "ou_path": [
      "o-abcd1234/r-abc/ou-abc-def/"
    ],
    "original_session_exp": "2025-12-19T10:21:06Z",
    "source_region": "us-east-2",
    "ec2_source_instance_arn": "arn:aws:ec2:us-east-2:123456789012:instance/i-12345678901234567",
    "principal_id": "arn:aws:iam::123456789012:role/nymeria-cross-cloud-9zo9h8c5",
    "principal_tags": {
      "Product": "Nymeria"
    },
    "ec2_instance_source_private_ipv4": "10.142.128.107"
  },
  "iss": "https://53e20c38-5c03-41f7-8baa-a67e81974de0.tokens.sts.global.api.aws",
  "exp": 1766118898,
  "iat": 1766118598,
  "jti": "1640bab7-b35b-4410-b4ee-04d219abbf33"
}

Azure Managed Identity Trust Configuration

To establish trust in the Azure tenant, start by creating a user assigned managed identity in a resource group with permissions to read data from the cross cloud storage account.

The following Terraform configuration uses the azurerm_user_assigned_identity resource to create the user assigned managed identity. Then, the azurerm_role_assignment resource grants the Storage Blob Data Reader role to the managed identity to read data from the cross cloud storage account.

resource "azurerm_user_assigned_identity" "cross_cloud" {
  name                = "cross-cloud-vm-${random_string.unique_id.result}"
  location            = var.location
  resource_group_name = azurerm_resource_group.federated_identity.name
}

resource "azurerm_role_assignment" "cross_cloud_blob_reader" {
  principal_id         = azurerm_user_assigned_identity.cross_cloud.principal_id
  scope                = azurerm_storage_account.cross_cloud.id
  role_definition_name = "Storage Blob Data Reader"
}

Finally, configure the user assigned managed identity's federated credentials to trust the AWS outbound identity provider. The var.aws_account_issuer variable is set to the AWS accounts issuer https://53e20c38-5c03-41f7-8baa-a67e81974de0.tokens.sts.global.api.aws. The var.aws_iam_role_arn variable is set to the AWS IAM role ARN arn:aws:iam::123456789012:role/nymeria-cross-cloud-9zo9h8c5.

resource "azurerm_federated_identity_credential" "aws" {
  name                = "nymeria-aws"
  resource_group_name = var.azure_resource_group_name
  parent_id           = var.azure_managed_identity_id

  issuer   = var.aws_account_issuer
  audience = ["api://AzureADTokenExchange"]
  subject  = var.aws_iam_role_arn
}

Accessing Azure Blob Storage from AWS EC2

With the AWS outbound identity federation and Azure managed identity trust relationship configured, the EC2 instance can now access the Azure Blob storage container. To test the access to the storage instance, start by requesting a new AWS outbound identity token and storing the value in an environment variable called JWT.

JWT=$(aws sts get-web-identity-token --audience api://AzureADTokenExchange --signing-algorithm RS256 --duration-seconds 300 | jq -r '.WebIdentityToken')

Then, set the following environment variables to your Azure tenant id, user assigned managed identity client id, and the name of the storage account.

export AZURE_TENANT_ID="your-azure-tenant-id"
export AZURE_MANAGED_IDENTITY_CLIENT_ID="your-managed-identity-client-id"
export AZURE_STORAGE_ACCOUNT="your-cross-cloud-storage-account"

Finally, run the az login command to authenticate to the Azure tenant using the AWS outbound identity token. After successfully logging in, use the az storage blob list command to list the blobs in the storage container.

az login --service-principal --tenant $AZURE_TENANT_ID --username $AZURE_MANAGED_IDENTITY_CLIENT_ID --federated-token $JWT

The output will confirm that you have successfully authenticated into the Azure tenant using the AWS outbound identity token.

[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "your-azure-tenant-id",
    "id": "your-azure-subscription-id",
    "isDefault": true,
    "managedByTenants": [],
    "name": "your-azure-subscription-name",
    "state": "Enabled",
    "tenantId": "your-azure-tenant-id",
    "user": {
      "name": "your-managed-identity-client-id",
      "type": "servicePrincipal"
    }
  }
]

Finally, list the blobs in the Azure storage account container to confirm that access to the storage account is working as expected.

az storage blob list --auth-mode login --account-name $AZURE_STORAGE_ACCOUNT --container-name assets | jq '.[].name'

Conclusion

AWS IAM Outbound Identity Federation provides a new way for workloads running in AWS to securely access external cloud resources using short-lived, signed OIDC tokens. With the addition of this new feature, the Puma Security Nymeria cross-cloud workload identity project now supports federating from AWS EC2 instances into both Azure and Google cloud storage resources.

References

About The Author

Eric Johnson's experience includes performing cloud security architecture and design, cloud native and Kubernetes assessments, infrastructure as code automation, application security automation, web and mobile application penetration testing, secure development lifecycle consulting, and secure code review assessments.

Auditing AWS EKS Pod Permissions

Eric Johnson — Thu, 29 Feb 2024 20:50:47 +0000

Applications running in EKS often require access to AWS resources, including S3 buckets, DynamoDB tables, Secrets Manager secrets, KMS keys, SQS queues, and other resources. As a security auditor, mapping EKS pods in a cluster to assigned IAM policy permissions can be challenging. In this post, we will review three different ways to audit EKS pod permissions.

EKS Node IAM Role Permissions

EKS avoids provisioning long-lived access keys to the cluster’s nodes by using an instance profile to pass IAM role credentials to the EC2 instance. Services running on the EKS node can request the role’s temporary access keys using the EC2 Instance Metadata Service (IMDS). By default, all pods running on the node can also communicate with the IMDS. This allows pods to request temporary access keys for the node's IAM role and access AWS resources.

Consider the EKS node in the diagram below. The node’s kubelet makes AWS API calls for the Kubernetes control plane to function, which typically requires the AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly, and CloudWatchAgentServerPolicy managed policies. Knowing the web pod needs access to an S3 bucket and a Secrets Manager secret, the appropriate permissions are attached to the node’s IAM Role as well.

The web pod's path to accessing the AWS APIs is as follows:

The development team deploys the web pod in the dm namespace on the EKS node.
The process running in the web container requests the IAM role's temporary credentials from the instance metadata service (http://169.254.169.254/latest/meta-data/iam/security-credentials/dm-eks-node-role). The response includes a temporary AWS Access Key Id, Secret Access Key, and Session Token for authenticating to AWS APIs using the EKS node's IAM Role.
The process running in the web container invokes the S3 and Secrets Manager API using the temporary credentials.

So, what’s the problem? Mixing the kubelet’s control plane permissions with permissions for other workloads can create privilege escalation issues. To start, the EKS node has a number of AWS managed policies, including the AmazonEKS_CNI_Policy managed policy, which could allow the web pod to create, delete, and attach network interfaces from the nodes in the cluster. These permissions are unlikely to be required for the web pod to operate.

Now, let's consider a scenario where a new pod, evil, is deployed into a different namespace called sabre. The next diagram shows the evil pod requesting temporary credentials from the node's instance metadata service. The temporary credentials will also include the web pod's permission to the S3 and Secrets Manager!

Blocking Pod IMDS Access

Given the privilege escalation issues granting pod permissions at the node level, ensure your EKS administrators disable pod access to the node’s IMDS endpoint. This will avoid mixing node and pod level permissions, and make it much easier for auditors to understand an individual pod’s permissions. This can be done using either of the following methods:

IMDSv2 Hop Limit

Enforce IMDS version (IMDSv2) on the cluster nodes and set the response hop limit to one (1). This ensures that IMDS responses cannot be received by the pod’s network interface. The following Terraform configuration sets the appropriate IMDSv2 configuration on the node’s aws_launch_template resource.

# IMDSv2 w/ hop limit set to 1 disables pod access to the IMDS
metadata_options {
  http_endpoint               = "enabled"
  http_tokens                 = "required"
  http_put_response_hop_limit = 1
  instance_metadata_tags      = "enabled"
}

Network Policy

Blocking IMDS access cluster-wide could cause problems if pods running in the cluster actually need access to the IMDS. Applying a NetworkPolicy to namespaces in the cluster that should not have access to the IMDS can provide a more flexible alternative. The following Calico NetworkPolicy allows the evil pod outbound access to networks outside the cluster, but explicitly blocks access to the IMDS endpoint:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
 name: egress-all
 namespace: sabre
spec:
 types:
   - Egress
 egress:
   - action: Deny
     destination:
       nets:
         - "169.254.169.254/32"
   - action: Allow
     destination:
       nets:
         - "0.0.0.0/0"

IAM Roles for Service Accounts (IRSA)

Now that the pods cannot inherit permissions from the EKS node, workloads will need an IAM Role assigned directly to the pod. In AWS EKS, the first option for granting pod-level access to the AWS APIs is called IAM Roles for Service Accounts (IRSA). IRSA uses the EKS cluster’s OpenID Connect (OIDC) identity provider to federate into an AWS identity provider and assume a role. The updated diagram below shows the new authentication flow:

The web pod's path to accessing the AWS APIs is now:

The development team deploys a new Kubernetes ServiceAccount web-sa in the dm namespace. A special annotation eks.amazonaws.com/role-arn is set on the service account mapping the Kubernetes service account to an IAM Role ARN.
The development team adjusts the web deployment to assign the new web-sa service account to the web pods.
As EKS creates the web pod, a mutating web hook automatically injects two new environment variables: AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE. The process running in the web container uses the new environment variables to call the sts:AssumeRoleWithWebIdentity API using the service account identity token (JWT) and obtain temporary access keys.

Auditing IRSA Pod Permissions

All EKS service accounts using IRSA will contain the eks.amazonaws.com/role-arn annotation.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: 
    "arn:aws:iam::123456789012:role/dm-web-eks-pod-role"
  name: "web-sa"
  namespace: "dm"

Auditing IAM policies assigned to pods using IRSA can be done by enumerating all of the EKS cluster’s service accounts with the eks.amazonaws.com/role-arn annotation, parsing the IAM Role ARN, and then enumerating the IAM Role’s policy attachments. The aws-eks-audit-irsa-pods script uses the kubectl and aws command line interfaces to discover IRSA pod permissions:

#!/bin/bash

while IFS= read -r sa_metadata; do
  service_account=$(jq -r .name <<<"${sa_metadata}")
  namespace=$(jq -r .namespace <<<"${sa_metadata}")
  role_arn=$(jq -r .rolearn <<<"${sa_metadata}")
  role_name=$(jq -r '.rolearn | split("/") | .[1]' <<<"${sa_metadata}")

  echo "Service Account: system:serviceaccount:${namespace}:${service_account}"
  echo "Role ARN: ${role_arn}"
  echo "Policy Attachments:"
  aws iam list-attached-role-policies --role-name ${role_name} | jq -r .'AttachedPolicies[].PolicyArn'

  echo ""
done < <(kubectl get serviceaccounts -A -o json | 
  jq -c '.items[] | select(.metadata.annotations."eks.amazonaws.com/role-arn" != null) | 
  {name: .metadata.name, namespace: .metadata.namespace, rolearn: .metadata.annotations."eks.amazonaws.com/role-arn"}'
)

The output shows the Kubernetes service account, IAM Role ARN, and the IAM policy attachments:

Service Account: system:serviceaccount:dm:web-sa
Role ARN: arn:aws:iam::123456789012:role/dm-web-eks-pod-role
Policy Attachments:
arn:aws:iam::123456789012:policy/dm-web-eks-pod-policy

Service Account: system:serviceaccount:kube-system:aws-load-balancer-controller
Role ARN: arn:aws:iam::123456789012:role/dm-eks-alb-controller-role
Policy Attachments:
arn:aws:iam::123456789012:policy/dm-eks-alb-controller-policy

Service Account: system:serviceaccount:kube-system:ebs-csi-controller-sa
Role ARN: arn:aws:iam::123456789012:role/dm-eks-ebs-csi-role
Policy Attachments:
arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy

EKS Pod Identity

Launched in late 2023, EKS Pod Identity offers an additional option for assigning permissions to pods. EKS Pod Identity is specific to EKS, and does not translate into other managed Kubernetes offerings (e.g., AKS, GKE). After installing the EKS Pod Identity Agent cluster add on, IAM Role to Kubernetes service associations are defined on the EKS cluster instead of the Kubernetes service account resource. For more details, see Christophe Tafani-Dereeper’s post titled Deep dive into the new Amazon EKS Pod Identity feature.

The following Terraform configuration sets an EKS pod identity association using the aws_eks_pod_identity_association resource. The resource creates an association between the sabre namespace’s web-sa service account and the dm_web_eks_pod IAM Role. As the pod is being created, the EKS Pod Identity mutating webhook will automatically inject the AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE environment variables. Processes running in the container can use the AWS_CONTAINER_CREDENTIALS_FULL_URI, which will have a value similar to http://169.254.170.23/v1/credentials, to request temporary credentials for the IAM Role. Invoking the endpoint requires the Authorization header to have the identity token found in the AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE volume mount (/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token).

resource "aws_eks_pod_identity_association" "dm_web_pod_identity" {
  cluster_name    = aws_eks_cluster.dm.name
  namespace       = "sabre"
  service_account = "web-sa"
  role_arn        = aws_iam_role.dm_web_eks_pod.arn
}

Auditing Pod Identity Permissions

Auditing IAM policies assigned using EKS Pod Identity can be done by enumerating all of the EKS cluster’s associations, finding the IAM Role, and then enumerating the IAM Role’s policy attachments. The aws-eks-audit-pod-identity-pods script uses only the aws command line interfaces to discover pod permissions. The kubectl command line interface is not needed because the associations live at the cluster level, not at the Kubernetes service account level.

#!/bin/bash

CLUSTER_NAME="$1"

while IFS= read -r pod_identity_assn; do
  association_id=$(jq -r .associationId <<<"${pod_identity_assn}")
  service_account=$(jq -r .serviceAccount <<<"${pod_identity_assn}")
  namespace=$(jq -r .namespace <<<"${pod_identity_assn}")
  association=$(aws eks describe-pod-identity-association --cluster "${CLUSTER_NAME}" --association-id "${association_id}")
  role_arn=$(jq -r '.association.roleArn' <<<"${association}")
  role_name=$(jq -r '.association.roleArn | split("/") | .[1]' <<<"${association}")

  echo "Kubernetes Service Account: system:serviceaccount:${namespace}:${service_account}"
  echo "Role ARN: ${role_arn}"
  echo "Policy Attachments:"
  aws iam list-attached-role-policies --role-name "${role_name}" | jq -r .'AttachedPolicies[].PolicyArn'

  echo ""
done < <(aws eks list-pod-identity-associations --cluster-name "${CLUSTER_NAME}" | jq -c '.associations[]')

The output shows the Kubernetes service account, IAM Role ARN, and the IAM policy attachments:

Kubernetes Service Account: system:serviceaccount:sabre:web-sa
Role ARN: arn:aws:iam::192792859965:role/dm-web-eks-pod-identity-role
Policy Attachments:
arn:aws:iam::192792859965:policy/dm-web-eks-pod-policy

Conclusions

Auditing permissions assigned directly to EKS pods can be challenging and confusing with multiple options for creating associations between IAM Roles and Kubernetes service accounts. The audit scripts above are two helper scripts that live in my local bin directory for easily enumerating Kubernetes service accounts with access to the AWS APIs.

Datadog also maintains the Managed Kubernetes Auditing Toolkit (MKAT), which can be installed to perform similar permission checks.

References

About the Author

Eric Johnson is a Co-founder and Principal Security Engineer at Puma Security and a Senior Instructor with the SANS Institute. His experience includes cloud security assessments, cloud infrastructure automation, cloud architecture, static source code analysis, web and mobile application penetration testing, secure development lifecycle consulting, and secure code review assessments. Eric is the lead author and an instructor for SEC540: Cloud Security and DevSecOps Automation and a co-author and instructor for both SEC549: Cloud Security Architecture, and SEC510: Cloud Security Controls and Mitigations.