Bedrock access with workload identity

This guide configures the Agent Router data plane on AWS Elastic Kubernetes Service (EKS) to call AWS Bedrock with the pod's IAM identity — IRSA or EKS Pod Identity — instead of static access keys.

---

Overview

Two steps take an installed EKS data plane to serving Bedrock with no static AWS keys:

1. Bind the identity — tare dataplane identity bind attaches an AWS IAM role to the data plane's egress workload through the cluster (IRSA or EKS Pod Identity).
2. Register a credential-less provider — create the AWS Bedrock provider in the Admin Dashboard with no access keys; the data plane signs Bedrock requests with the pod's role.

Binding places the IAM role in the AWS SDK default credential chain of the data plane's egress pod. A Bedrock provider registered without keys is then reconciled to a region-only authentication policy on the data plane, and every Bedrock request is signed (SigV4) with the identity the cluster provides. No AWS keys are stored in the cluster, and none are stored in the management plane.

Plan for 10--15 minutes, assuming the data plane is already installed.

Choose a mechanism

Both mechanisms end in the same place — the egress pod holds an IAM role that is allowed to invoke Bedrock. They differ in how the role is trusted and bound:

	IRSA	EKS Pod Identity
Role trust	Cluster OIDC provider, scoped to the ServiceAccount	pods.eks.amazonaws.com
Binding	ServiceAccount annotation (eks.amazonaws.com/role-arn)	Pod-identity association (no annotation)
Cluster prerequisite	IAM OIDC provider registered	eks-pod-identity-agent addon installed
One role, many clusters	No	Yes
Injected marker	AWS_ROLE_ARN / AWS_WEB_IDENTITY_TOKEN_FILE	AWS_CONTAINER_CREDENTIALS_FULL_URI
--cluster / --region flags	Only with --create-iam	Always

IRSA is the default (--type irsa). Prefer EKS Pod Identity when one role should serve several clusters, or when the cluster already runs the pod-identity agent.

Prerequisites

• Data plane installed and connected to its management plane — see the AWS installation guide. The same guide covers installing the tare CLI.

• kubectl context pointing at the EKS cluster.

• A live AWS session for the target account when using --create-iam — via aws sso login, aws configure, or AWS_* environment variables. Confirm with:

  aws sts get-caller-identity

  The session needs permission to create IAM roles and policies (and, for Pod Identity, to manage EKS pod-identity associations).

• Per-mechanism cluster prerequisite — bind detects a missing prerequisite and prints the exact fix command, but you can prepare it up front:

  • IRSA: the cluster's IAM OIDC provider is registered:

    eksctl utils associate-iam-oidc-provider --cluster <cluster-name> --approve

  • EKS Pod Identity: the eks-pod-identity-agent addon is installed:

    aws eks create-addon --cluster-name <cluster-name> --addon-name eks-pod-identity-agent --region <region>

Step 1: Bind the data plane identity

tare dataplane identity bind creates the IAM role, its trust relationship, and a bedrock:InvokeModel policy (with --create-iam), binds the data plane's signing ServiceAccount, waits for the rollout, and confirms credentials were injected into the egress pod.

Before applying anything, a read-only preflight confirms the ServiceAccount exists and the current kubectl context is allowed to patch the resources the bind touches.

IRSA

# Create the role + trust + Bedrock policy, then bind:
tare dataplane identity bind --type irsa --create-iam --cluster <cluster-name> --region <region>

# Or bind an IAM role you already created:
tare dataplane identity bind --type irsa --role-arn arn:aws:iam::<account-id>:role/<role-name>

EKS Pod Identity

The pod-identity association is cluster-scoped, so --cluster and --region are always required:

tare dataplane identity bind --type eks-pod-identity --create-iam --cluster <cluster-name> --region <region>

Preview and verify

Both commands are read-only and make no changes:

# Preview the planned actions:
tare dataplane identity bind --type <irsa|eks-pod-identity> --create-iam --cluster <cluster-name> --region <region> --dry-run

# Verify an existing binding:
tare dataplane identity bind --check --type <irsa|eks-pod-identity>

Defaults

Flag	Default
--type	irsa
--service-account	egress
--namespace	tars-dataplane
--role-name (with --create-iam)	<cluster>-bedrock-dp
--wait	on

Run tare dataplane identity bind --help for the full flag reference. In non-interactive contexts (CI), add --yes to skip the confirmation prompt.

Step 2: Register a credential-less Bedrock provider

In the Admin Dashboard, create an AWS Bedrock provider with no access keys: on the provider create form, turn on Use IRSA / EKS Pod Identity (no static keys). The AWS key fields disappear and the provider is created without a secret; the identity bound in Step 1 signs its requests.

Follow the Provision AWS Bedrock models guide for the full provider-registration walkthrough. Two fields matter especially here:

• Region must be the region the IAM role can reach Bedrock in — the same <region> used in Step 1.
• API base URL is pre-filled as https://bedrock-runtime.<region>.amazonaws.com from the region and must not be left empty.

Step 3: Verify end-to-end

1. Confirm the binding and credential injection:

   tare dataplane identity bind --check --type <irsa|eks-pod-identity>

2. Send a normal chat request through the gateway to a Bedrock model. A completion means the data plane signed the request with the pod's IAM role — zero static keys involved.

Troubleshooting

• A cluster prerequisite is missing. bind reports the missing prerequisite together with the exact command that fixes it (see Prerequisites); run the command and re-run bind.

• The rollout stalls. With --wait (the default), bind reports the first not-ready pod and its reason instead of timing out silently.

• Checking the injected credentials by hand. The signing container image is distroless, so kubectl exec … -- env cannot work. Read the pod spec instead — expect the injected marker on the egress pod's containers (AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE for IRSA; AWS_CONTAINER_CREDENTIALS_FULL_URI for Pod Identity):

  kubectl get pods -n tars-dataplane -l gateway.envoyproxy.io/owning-gateway-name=egress -o yaml | grep -A2 AWS_

  tare dataplane identity bind --check performs this check for you.

• A "secret NotFound" warning appears in the data plane logs. For a credential-less provider, a warning mentioning AISECRET_<PROVIDER> and "secret NotFound" is expected — there is intentionally no secret, and processing proceeds with the pod identity.

• Requests to Bedrock fail with authentication errors. Verify the provider's API base URL is https://bedrock-runtime.<region>.amazonaws.com and its Region matches both the URL and the region the IAM role was created for.

---

Where to go next

Provision AWS Bedrock models

The full provider-registration walkthrough, including the credential-less pod-identity mode.

Data plane installation for AWS

Install the data plane on EKS, from cluster prerequisites to a connected gateway.