Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Pod Identity and credentials

Pods running in a Nitro Sandbox cannot reach the parent instance’s network services directly. The sandbox provides local surrogates for instance metadata and Pod Identity credentials so that workloads behave the same as pods running on a standard node.

Instance metadata (IMDS)

The Nitro Sandbox runs an IMDSv2-only metadata service at 169.254.169.254. Workloads that use the Amazon SDKs or query IMDS directly for region and placement information work without changes. The metadata service provides only the following paths; all other paths return a 404 response:

The metadata service requires IMDSv2 session tokens. Use PUT /latest/api/token with a X-aws-ec2-metadata-token-ttl-seconds header to obtain a token, then pass it as X-aws-ec2-metadata-token on subsequent requests. IMDSv1 (tokenless) requests are rejected.

Amazon SDKs and the ec2-metadata CLI tool use IMDSv2 by default and work without changes.

Pod Identity

Pods in Nitro Sandboxes access Amazon credentials through EKS Pod Identity the same way as pods on standard nodes. The credential endpoint (169.254.170.23:80) is available inside the sandbox and returns temporary credentials for the IAM role associated with the pod’s service account.

If you attach a Cedar policy to the pod, generate it with --with-pod-identity, in both isolated and confidential mode. The EKS Pod Identity webhook injects the token volume after eks-nitro-sandbox-genpolicy reads your manifest, so the tool cannot detect it. Without the flag, the pod starts but the token file is absent, and Amazon SDK calls fail because they cannot read the file named by AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE. Isolated pods without a policy need no additional configuration.

IAM roles for service accounts (IRSA)

Pods in Nitro Sandboxes can also obtain Amazon credentials through IRSA. IRSA is an alternative to Pod Identity for your workload’s own Amazon calls. Features where the Nitro Sandbox calls Amazon on the pod’s behalf, encrypted image decryption and image signature verification, use EKS Pod Identity only.

Without the flag, the policy has no permit allowing the token to be written into the sandbox. The pod still starts, but the token file is absent and every Amazon SDK call fails with a missing credentials error:

aws: [ERROR]: [Errno 2] No such file or directory: '/var/run/secrets/eks.amazonaws.com/serviceaccount/token'

The --with-irsa flag is needed in both isolated and confidential mode. Note that --with-sa-token does not cover IRSA: that flag applies only to the standard Kubernetes service account token at /var/run/secrets/kubernetes.io/serviceaccount, which is a different token with a different audience.

Policy control for credentials

In both modes, the Cedar policy controls whether the IMDS surrogate is available inside the sandbox. The built-in profiles permit it. To deny it, pass --deny-imds or set imds: deny in a custom profile. See Run a pod in confidential mode.

The Pod Identity credential endpoint is not controlled by a Cedar action. Whether the workload receives its Pod Identity token is controlled by the --with-pod-identity flag at policy generation time. For IRSA, credential delivery is controlled the same way by the --with-irsa flag.