From 81b1e862f9fa9fa6d4fdd839c7f21949098eb348 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 11:48:00 -0400 Subject: [PATCH 01/13] Added agentcore Signed-off-by: Kristin Brown --- .../pages/agentgateway/agent/agentcore.md | 119 ++++++++++++++++++ .../docs/kubernetes/main/agent/agentcore.md | 8 ++ 2 files changed, 127 insertions(+) create mode 100644 assets/agw-docs/pages/agentgateway/agent/agentcore.md create mode 100644 content/docs/kubernetes/main/agent/agentcore.md diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md new file mode 100644 index 000000000..f86227789 --- /dev/null +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -0,0 +1,119 @@ +With {{< reuse "agw-docs/snippets/agentgateway.md" >}}, you can route requests directly to an [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) agent runtime by using an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource. You do not need a separate proxy, custom code, or the AWS SDK. + +## About AWS Bedrock AgentCore {#about} + +Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its own invocation endpoint. To reach an AgentCore runtime, you supply its Amazon Resource Name (ARN) to an `{{< reuse "agw-docs/snippets/backend.md" >}}` of type `aws`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the connection details from the ARN: requests are sent over TLS to the `bedrock-agentcore` endpoint in the runtime's AWS region, with the path set to the runtime's invocation endpoint. + +{{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with AWS Signature Version 4 (SigV4) by using the standard [AWS credential lookup](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) from the proxy's environment. This way, you do not store long-lived credentials in the gateway configuration. + + + +This integration does not use the A2A protocol. Because AgentCore is configured as an AWS backend, you do not set the `appProtocol: kgateway.dev/a2a` field or use the `a2a` backend type. + +## Before you begin {#before-you-begin} + +{{< reuse "agw-docs/snippets/prereq-agentgateway.md" >}} + +Additionally, make sure that you have the following: + +* An Amazon Bedrock AgentCore agent runtime that is deployed in your AWS account, and its ARN in the format `arn:aws:bedrock-agentcore:::runtime/`. +* AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy so that it can sign requests with SigV4. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role that is allowed to invoke the AgentCore runtime with the proxy's Kubernetes service account. Unlike a static token, IRSA credentials rotate automatically. + +## Step 1: Create a backend for the AgentCore runtime {#backend} + +Create an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource that represents the AgentCore runtime. The `aws.agentCore` settings point {{< reuse "agw-docs/snippets/agentgateway.md" >}} to the runtime that you want to invoke. + +```yaml +kubectl apply -f- <}} +kind: {{< reuse "agw-docs/snippets/backend.md" >}} +metadata: + name: agentcore-backend + namespace: {{< reuse "agw-docs/snippets/namespace.md" >}} +spec: + aws: + agentCore: + agentRuntimeArn: arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/my-agent-runtime + # qualifier: production +EOF +``` + +| Setting | Description | +| -- | -- | +| `aws.agentCore.agentRuntimeArn` | The ARN of the AgentCore agent runtime to invoke, in the format `arn:aws:bedrock-agentcore:::runtime/`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the endpoint, region, and invocation path from this value. | +| `aws.agentCore.qualifier` | Optional. The runtime version or endpoint qualifier to invoke. If you omit this setting, the default endpoint is used. | + +## Step 2: Route to the AgentCore backend {#route} + +Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} rewrites the request to the runtime's invocation endpoint and signs it before it is sent upstream. + +```yaml +kubectl apply -f- <}} +spec: + parentRefs: + - name: agentgateway-proxy + namespace: {{< reuse "agw-docs/snippets/namespace.md" >}} + rules: + - matches: + - path: + type: PathPrefix + value: /agentcore + backendRefs: + - name: agentcore-backend + group: {{< reuse "agw-docs/snippets/group.md" >}} + kind: {{< reuse "agw-docs/snippets/backend.md" >}} +EOF +``` + +Optionally, add a `RequestHeaderModifier` filter to the route rule to identify the calling user to the AgentCore runtime. AgentCore uses the `X-Amzn-Bedrock-AgentCore-Runtime-User-Id` header to associate requests with a user session. + +```yaml + filters: + - type: RequestHeaderModifier + requestHeaderModifier: + set: + - name: X-Amzn-Bedrock-AgentCore-Runtime-User-Id + value: user-123 +``` + +## Step 3: Verify the connection {#verify} + +1. Get the {{< reuse "agw-docs/snippets/agentgateway.md" >}} address. + + {{< tabs >}} + {{% tab name="Cloud Provider LoadBalancer" %}} + ```sh + export INGRESS_GW_ADDRESS=$(kubectl get gateway agentgateway-proxy -n {{< reuse "agw-docs/snippets/namespace.md" >}} -o=jsonpath="{.status.addresses[0].value}") + echo $INGRESS_GW_ADDRESS + ``` + {{% /tab %}} + {{% tab name="Port-forward for local testing" %}} + ```sh + kubectl port-forward deployment/agentgateway-proxy -n {{< reuse "agw-docs/snippets/namespace.md" >}} 8080:80 + ``` + {{% /tab %}} + {{< /tabs >}} + +2. Send a request to the AgentCore runtime through the gateway. The request body depends on the agent that you deployed to the runtime. The following example sends a simple prompt. + + ```sh + curl -X POST http://$INGRESS_GW_ADDRESS/agentcore \ + -H "Content-Type: application/json" \ + -d '{"prompt": "Hello from agentgateway!"}' + ``` + + If the request is signed successfully and the runtime is reachable, you get a response from your agent. If you get a `403` error, verify that the proxy's AWS credentials are allowed to invoke the AgentCore runtime. + +## Cleanup + +{{< reuse "agw-docs/snippets/cleanup.md" >}} + +```sh +kubectl delete HTTPRoute agentcore -n {{< reuse "agw-docs/snippets/namespace.md" >}} --ignore-not-found +kubectl delete {{< reuse "agw-docs/snippets/backend.md" >}} agentcore-backend -n {{< reuse "agw-docs/snippets/namespace.md" >}} --ignore-not-found +``` diff --git a/content/docs/kubernetes/main/agent/agentcore.md b/content/docs/kubernetes/main/agent/agentcore.md new file mode 100644 index 000000000..1c9d266a4 --- /dev/null +++ b/content/docs/kubernetes/main/agent/agentcore.md @@ -0,0 +1,8 @@ +--- +title: Connect to AWS Bedrock AgentCore +weight: 50 +description: Route requests to an Amazon Bedrock AgentCore agent runtime through agentgateway. +# Requires AWS account to add tests +--- + +{{< reuse "agw-docs/pages/agentgateway/agent/agentcore.md" >}} From bdc7f2c9c1c115371566b01cded6362104f149a8 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 11:57:32 -0400 Subject: [PATCH 02/13] Added auth Signed-off-by: Kristin Brown --- .../pages/agentgateway/agent/agentcore.md | 57 ++++++++++++++++--- 1 file changed, 50 insertions(+), 7 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index f86227789..3075f50ce 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -2,11 +2,14 @@ With {{< reuse "agw-docs/snippets/agentgateway.md" >}}, you can route requests d ## About AWS Bedrock AgentCore {#about} -Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its own invocation endpoint. To reach an AgentCore runtime, you supply its Amazon Resource Name (ARN) to an `{{< reuse "agw-docs/snippets/backend.md" >}}` of type `aws`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the connection details from the ARN: requests are sent over TLS to the `bedrock-agentcore` endpoint in the runtime's AWS region, with the path set to the runtime's invocation endpoint. +Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its own invocation endpoint. To reach an AgentCore runtime, you supply its Amazon Resource Name (ARN) to an `{{< reuse "agw-docs/snippets/backend.md" >}}` of type `aws`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the connection details from the ARN: requests are sent over TLS to the `bedrock-agentcore` endpoint in the runtime's AWS region, with the path rewritten to the runtime's invocation endpoint. You do not construct the endpoint or encode the ARN yourself. -{{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with AWS Signature Version 4 (SigV4) by using the standard [AWS credential lookup](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) from the proxy's environment. This way, you do not store long-lived credentials in the gateway configuration. +### Authentication {#authentication} - +AgentCore runtimes support two authentication modes, which you choose when you deploy the runtime in AWS. The `aws.agentCore` backend supports both: + +* **IAM (SigV4)**: The default. {{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with AWS Signature Version 4 (SigV4) by using the standard [AWS credential lookup](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) from the proxy's environment, such as [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) on Amazon EKS. You do not store long-lived credentials in the gateway configuration, and IRSA credentials rotate automatically. +* **JWT authorizer** (for example, Amazon Cognito): The runtime validates an OIDC bearer token on each request. To use this mode, attach a backend authentication policy that sends the token in the `Authorization` header. This overrides the default SigV4 signing. Unlike SigV4 credentials, a JWT expires, so you must refresh the token in the backing Kubernetes Secret before it expires. This integration does not use the A2A protocol. Because AgentCore is configured as an AWS backend, you do not set the `appProtocol: kgateway.dev/a2a` field or use the `a2a` backend type. @@ -17,11 +20,17 @@ This integration does not use the A2A protocol. Because AgentCore is configured Additionally, make sure that you have the following: * An Amazon Bedrock AgentCore agent runtime that is deployed in your AWS account, and its ARN in the format `arn:aws:bedrock-agentcore:::runtime/`. -* AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy so that it can sign requests with SigV4. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role that is allowed to invoke the AgentCore runtime with the proxy's Kubernetes service account. Unlike a static token, IRSA credentials rotate automatically. +* Credentials for the runtime's authentication mode: + * For **IAM (SigV4)**, AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy and that are allowed to invoke the runtime. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role with the proxy's Kubernetes service account. + * For a **JWT authorizer**, a valid OIDC bearer token that the runtime's authorizer accepts, such as an Amazon Cognito access or ID token. ## Step 1: Create a backend for the AgentCore runtime {#backend} -Create an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource that represents the AgentCore runtime. The `aws.agentCore` settings point {{< reuse "agw-docs/snippets/agentgateway.md" >}} to the runtime that you want to invoke. +Create an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource that represents the AgentCore runtime. The `aws.agentCore` settings point {{< reuse "agw-docs/snippets/agentgateway.md" >}} to the runtime that you want to invoke. The configuration depends on the runtime's [authentication mode](#authentication). + +{{< tabs >}} +{{% tab name="IAM (SigV4)" %}} +Create the backend with only the `aws.agentCore` settings. {{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with SigV4 by using the proxy's environment credentials. You do not add an authentication policy. ```yaml kubectl apply -f- <}} \ + --from-literal=Authorization="$AGENTCORE_JWT" + ``` + +2. Create the backend and reference the Secret with a `policies.auth.secretRef` setting. {{< reuse "agw-docs/snippets/agentgateway.md" >}} sends the token in the `Authorization` header with a `Bearer` prefix, which overrides the default SigV4 signing. The endpoint, region, and invocation path are still derived from the ARN. + + ```yaml + kubectl apply -f- <}} + kind: {{< reuse "agw-docs/snippets/backend.md" >}} + metadata: + name: agentcore-backend + namespace: {{< reuse "agw-docs/snippets/namespace.md" >}} + spec: + aws: + agentCore: + agentRuntimeArn: arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/my-agent-runtime + # qualifier: production + policies: + auth: + secretRef: + name: agentcore-jwt + EOF + ``` +{{% /tab %}} +{{< /tabs >}} | Setting | Description | | -- | -- | | `aws.agentCore.agentRuntimeArn` | The ARN of the AgentCore agent runtime to invoke, in the format `arn:aws:bedrock-agentcore:::runtime/`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the endpoint, region, and invocation path from this value. | | `aws.agentCore.qualifier` | Optional. The runtime version or endpoint qualifier to invoke. If you omit this setting, the default endpoint is used. | +| `policies.auth` | Optional. Overrides the default authentication for the backend. Omit this setting to sign requests with SigV4 (IAM). To authenticate to a runtime that uses a JWT authorizer, set `policies.auth.secretRef` (or `policies.auth.key`) to a bearer token. By default, the token is sent in the `Authorization` header with a `Bearer` prefix. When you use `secretRef` with the default resolver, store the token under the Secret's `Authorization` key. | ## Step 2: Route to the AgentCore backend {#route} -Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} rewrites the request to the runtime's invocation endpoint and signs it before it is sent upstream. +Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} rewrites the request to the runtime's invocation endpoint before it is sent upstream. ```yaml kubectl apply -f- <}} --ignore-not-found kubectl delete {{< reuse "agw-docs/snippets/backend.md" >}} agentcore-backend -n {{< reuse "agw-docs/snippets/namespace.md" >}} --ignore-not-found +kubectl delete secret agentcore-jwt -n {{< reuse "agw-docs/snippets/namespace.md" >}} --ignore-not-found ``` From cba8f4f222f324810d85c49e15e8352a0b8bbc40 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 12:25:53 -0400 Subject: [PATCH 03/13] Added links Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 5 ++++- .../agw-docs/pages/agentgateway/llm/providers/bedrock.md | 7 ++++--- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 3075f50ce..3a2ddcb64 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -1,5 +1,8 @@ With {{< reuse "agw-docs/snippets/agentgateway.md" >}}, you can route requests directly to an [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) agent runtime by using an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource. You do not need a separate proxy, custom code, or the AWS SDK. +> [!NOTE] +> This page routes to a deployed AgentCore agent runtime. To use Amazon Bedrock for direct LLM model invocation instead, see [Amazon Bedrock]({{< link-hextra path="/llm/providers/bedrock/" >}}). + ## About AWS Bedrock AgentCore {#about} Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its own invocation endpoint. To reach an AgentCore runtime, you supply its Amazon Resource Name (ARN) to an `{{< reuse "agw-docs/snippets/backend.md" >}}` of type `aws`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the connection details from the ARN: requests are sent over TLS to the `bedrock-agentcore` endpoint in the runtime's AWS region, with the path rewritten to the runtime's invocation endpoint. You do not construct the endpoint or encode the ARN yourself. @@ -87,7 +90,7 @@ EOF ## Step 2: Route to the AgentCore backend {#route} -Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} rewrites the request to the runtime's invocation endpoint before it is sent upstream. +Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} replaces the entire request path with the runtime's invocation endpoint before the request is sent upstream. As a result, any subpath that a client appends after `/agentcore` is not forwarded to the runtime. ```yaml kubectl apply -f- <}} -Agentgateway accepts OpenAI-formatted requests (such as the `/v1/chat/completions` request body shape) and returns OpenAI-formatted responses, regardless of the route path that you configure. Agentgateway translates between OpenAI and Bedrock formats internally. Bedrock-native APIs such as the [Converse API](https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html) request and response shapes are not supported. Usage fields in responses follow the OpenAI shape (`prompt_tokens`, `completion_tokens`, `total_tokens`), not the Bedrock shape (`inputTokens`, `outputTokens`, `totalTokens`). -{{< /callout >}} +> [!NOTE] +> This page configures Bedrock as an LLM provider for direct model invocation. To route to a deployed Amazon Bedrock AgentCore agent runtime instead, which is a separate service with its own invocation endpoint, see [Connect to AWS Bedrock AgentCore]({{< link-hextra path="/agent/agentcore/" >}}). +> +> Agentgateway accepts OpenAI-formatted requests (such as the `/v1/chat/completions` request body shape) and returns OpenAI-formatted responses, regardless of the route path that you configure. Agentgateway translates between OpenAI and Bedrock formats internally. Bedrock-native APIs such as the [Converse API](https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html) request and response shapes are not supported. Usage fields in responses follow the OpenAI shape (`prompt_tokens`, `completion_tokens`, `total_tokens`), not the Bedrock shape (`inputTokens`, `outputTokens`, `totalTokens`). ## Before you begin From 2ca9902b66ffb9887d97a8b99d1c0860f0b6ad95 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 14:11:36 -0400 Subject: [PATCH 04/13] Removed link Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/llm/providers/bedrock.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/llm/providers/bedrock.md b/assets/agw-docs/pages/agentgateway/llm/providers/bedrock.md index 00c2e7623..0108614b9 100644 --- a/assets/agw-docs/pages/agentgateway/llm/providers/bedrock.md +++ b/assets/agw-docs/pages/agentgateway/llm/providers/bedrock.md @@ -1,8 +1,6 @@ Configure [Amazon Bedrock](https://aws.amazon.com/bedrock/) as an LLM provider in agentgateway. > [!NOTE] -> This page configures Bedrock as an LLM provider for direct model invocation. To route to a deployed Amazon Bedrock AgentCore agent runtime instead, which is a separate service with its own invocation endpoint, see [Connect to AWS Bedrock AgentCore]({{< link-hextra path="/agent/agentcore/" >}}). -> > Agentgateway accepts OpenAI-formatted requests (such as the `/v1/chat/completions` request body shape) and returns OpenAI-formatted responses, regardless of the route path that you configure. Agentgateway translates between OpenAI and Bedrock formats internally. Bedrock-native APIs such as the [Converse API](https://docs.aws.amazon.com/bedrock/latest/userguide/conversation-inference.html) request and response shapes are not supported. Usage fields in responses follow the OpenAI shape (`prompt_tokens`, `completion_tokens`, `total_tokens`), not the Bedrock shape (`inputTokens`, `outputTokens`, `totalTokens`). ## Before you begin From c8e304cfe3af7b3a9135e2da56dc70cbe6b5f7ac Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 14:11:43 -0400 Subject: [PATCH 05/13] Wording tweaks Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 3a2ddcb64..5a97edffc 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -1,11 +1,11 @@ With {{< reuse "agw-docs/snippets/agentgateway.md" >}}, you can route requests directly to an [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) agent runtime by using an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource. You do not need a separate proxy, custom code, or the AWS SDK. > [!NOTE] -> This page routes to a deployed AgentCore agent runtime. To use Amazon Bedrock for direct LLM model invocation instead, see [Amazon Bedrock]({{< link-hextra path="/llm/providers/bedrock/" >}}). +> Unlike connecting to [agent-to-agent (A2A) servers]({{< link-hextra path="/agent/a2a/" >}}), this integration does not use the A2A protocol. AgentCore is configured as an AWS backend, so you do not set the `appProtocol: kgateway.dev/a2a` field or use the `a2a` backend type. ## About AWS Bedrock AgentCore {#about} -Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its own invocation endpoint. To reach an AgentCore runtime, you supply its Amazon Resource Name (ARN) to an `{{< reuse "agw-docs/snippets/backend.md" >}}` of type `aws`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} derives the connection details from the ARN: requests are sent over TLS to the `bedrock-agentcore` endpoint in the runtime's AWS region, with the path rewritten to the runtime's invocation endpoint. You do not construct the endpoint or encode the ARN yourself. +Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its own invocation endpoint. To reach an AgentCore runtime, you supply its Amazon Resource Name (ARN) to an `{{< reuse "agw-docs/snippets/backend.md" >}}` of type `aws`. {{< reuse "agw-docs/snippets/agentgateway.md" >}} uses the ARN to determine where to send each request. It connects over TLS to the `bedrock-agentcore` endpoint in the runtime's AWS region, then rewrites the request path to target the specific runtime. You do not construct the endpoint or encode the ARN yourself. ### Authentication {#authentication} @@ -14,7 +14,6 @@ AgentCore runtimes support two authentication modes, which you choose when you d * **IAM (SigV4)**: The default. {{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with AWS Signature Version 4 (SigV4) by using the standard [AWS credential lookup](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) from the proxy's environment, such as [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) on Amazon EKS. You do not store long-lived credentials in the gateway configuration, and IRSA credentials rotate automatically. * **JWT authorizer** (for example, Amazon Cognito): The runtime validates an OIDC bearer token on each request. To use this mode, attach a backend authentication policy that sends the token in the `Authorization` header. This overrides the default SigV4 signing. Unlike SigV4 credentials, a JWT expires, so you must refresh the token in the backing Kubernetes Secret before it expires. -This integration does not use the A2A protocol. Because AgentCore is configured as an AWS backend, you do not set the `appProtocol: kgateway.dev/a2a` field or use the `a2a` backend type. ## Before you begin {#before-you-begin} From 4f19f862e69affad500f001a94d796d483f03b93 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 14:22:19 -0400 Subject: [PATCH 06/13] Wording tweaks Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 5a97edffc..e73ff4060 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -21,8 +21,8 @@ AgentCore runtimes support two authentication modes, which you choose when you d Additionally, make sure that you have the following: -* An Amazon Bedrock AgentCore agent runtime that is deployed in your AWS account, and its ARN in the format `arn:aws:bedrock-agentcore:::runtime/`. -* Credentials for the runtime's authentication mode: +1. An Amazon Bedrock AgentCore agent runtime that is deployed in your AWS account. For steps to build and deploy a runtime, see the [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/). You also need the runtime's ARN, in the format `arn:aws:bedrock-agentcore:::runtime/`. +2. Credentials for the runtime's authentication mode: * For **IAM (SigV4)**, AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy and that are allowed to invoke the runtime. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role with the proxy's Kubernetes service account. * For a **JWT authorizer**, a valid OIDC bearer token that the runtime's authorizer accepts, such as an Amazon Cognito access or ID token. @@ -89,7 +89,7 @@ EOF ## Step 2: Route to the AgentCore backend {#route} -Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} replaces the entire request path with the runtime's invocation endpoint before the request is sent upstream. As a result, any subpath that a client appends after `/agentcore` is not forwarded to the runtime. +1. Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} replaces the entire request path with the runtime's invocation endpoint before the request is sent upstream. As a result, any subpath that a client appends after `/agentcore` is not forwarded to the runtime. ```yaml kubectl apply -f- < Date: Tue, 14 Jul 2026 14:29:45 -0400 Subject: [PATCH 07/13] Added space Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index e73ff4060..6525c7d54 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -23,8 +23,8 @@ Additionally, make sure that you have the following: 1. An Amazon Bedrock AgentCore agent runtime that is deployed in your AWS account. For steps to build and deploy a runtime, see the [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/). You also need the runtime's ARN, in the format `arn:aws:bedrock-agentcore:::runtime/`. 2. Credentials for the runtime's authentication mode: - * For **IAM (SigV4)**, AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy and that are allowed to invoke the runtime. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role with the proxy's Kubernetes service account. - * For a **JWT authorizer**, a valid OIDC bearer token that the runtime's authorizer accepts, such as an Amazon Cognito access or ID token. + * For **IAM (SigV4)**, AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy and that are allowed to invoke the runtime. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role with the proxy's Kubernetes service account. + * For a **JWT authorizer**, a valid OIDC bearer token that the runtime's authorizer accepts, such as an Amazon Cognito access or ID token. ## Step 1: Create a backend for the AgentCore runtime {#backend} From d4718a21ad00361f770130593f6d046634ed3f35 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Tue, 14 Jul 2026 14:31:08 -0400 Subject: [PATCH 08/13] Added indent Signed-off-by: Kristin Brown --- .../pages/agentgateway/agent/agentcore.md | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 6525c7d54..ec1e71f60 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -91,39 +91,39 @@ EOF 1. Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} replaces the entire request path with the runtime's invocation endpoint before the request is sent upstream. As a result, any subpath that a client appends after `/agentcore` is not forwarded to the runtime. -```yaml -kubectl apply -f- <}} -spec: - parentRefs: - - name: agentgateway-proxy - namespace: {{< reuse "agw-docs/snippets/namespace.md" >}} - rules: - - matches: - - path: - type: PathPrefix - value: /agentcore - backendRefs: - - name: agentcore-backend - group: {{< reuse "agw-docs/snippets/group.md" >}} - kind: {{< reuse "agw-docs/snippets/backend.md" >}} -EOF -``` + ```yaml + kubectl apply -f- <}} + spec: + parentRefs: + - name: agentgateway-proxy + namespace: {{< reuse "agw-docs/snippets/namespace.md" >}} + rules: + - matches: + - path: + type: PathPrefix + value: /agentcore + backendRefs: + - name: agentcore-backend + group: {{< reuse "agw-docs/snippets/group.md" >}} + kind: {{< reuse "agw-docs/snippets/backend.md" >}} + EOF + ``` 2. Optional: Add a `RequestHeaderModifier` filter to the route rule to identify the calling user to the AgentCore runtime. AgentCore uses the `X-Amzn-Bedrock-AgentCore-Runtime-User-Id` header to associate requests with a user session. -```yaml - filters: - - type: RequestHeaderModifier - requestHeaderModifier: - set: - - name: X-Amzn-Bedrock-AgentCore-Runtime-User-Id - value: user-123 -``` + ```yaml + filters: + - type: RequestHeaderModifier + requestHeaderModifier: + set: + - name: X-Amzn-Bedrock-AgentCore-Runtime-User-Id + value: user-123 + ``` ## Step 3: Verify the connection {#verify} From bae5fa9d8698cfecb7b2dce8f7be6e043a81a4d4 Mon Sep 17 00:00:00 2001 From: Kristin Brown Date: Wed, 15 Jul 2026 11:30:38 -0400 Subject: [PATCH 09/13] Added note Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index ec1e71f60..f52288c5f 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -91,6 +91,9 @@ EOF 1. Create an HTTPRoute that routes incoming traffic to the `{{< reuse "agw-docs/snippets/backend.md" >}}`. The following route matches the `/agentcore` path so that the runtime has a unique address on the gateway. You do not need to rewrite the path, because {{< reuse "agw-docs/snippets/agentgateway.md" >}} replaces the entire request path with the runtime's invocation endpoint before the request is sent upstream. As a result, any subpath that a client appends after `/agentcore` is not forwarded to the runtime. + > [!NOTE] + > AgentCore identifies a runtime entirely by its ARN, not by a URL subpath, so a path such as `/agentcore/my-agent` does not select a different agent. The `my-agent` subpath is dropped, and the request still reaches the ARN in the backend. To route to more than one runtime, create a separate `{{< reuse "agw-docs/snippets/backend.md" >}}` (each with its own `agentRuntimeArn`) and a separate route for each one. To target a different version or endpoint of the same runtime, set `aws.agentCore.qualifier` instead. + ```yaml kubectl apply -f- < Date: Thu, 16 Jul 2026 08:16:56 -0400 Subject: [PATCH 10/13] Update assets/agw-docs/pages/agentgateway/agent/agentcore.md Co-authored-by: Art Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index f52288c5f..699ecb82c 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -32,7 +32,7 @@ Create an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource that represent {{< tabs >}} {{% tab name="IAM (SigV4)" %}} -Create the backend with only the `aws.agentCore` settings. {{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with SigV4 by using the proxy's environment credentials. You do not add an authentication policy. +Create the backend with only the `aws.agentCore` settings. {{< reuse "agw-docs/snippets/agentgateway-capital.md" >}} signs each request with SigV4 by using the proxy's environment credentials. You do not add an authentication policy. ```yaml kubectl apply -f- < Date: Thu, 16 Jul 2026 08:17:06 -0400 Subject: [PATCH 11/13] Update assets/agw-docs/pages/agentgateway/agent/agentcore.md Co-authored-by: Art Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 699ecb82c..01cadc83d 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -58,7 +58,7 @@ EOF --from-literal=Authorization="$AGENTCORE_JWT" ``` -2. Create the backend and reference the Secret with a `policies.auth.secretRef` setting. {{< reuse "agw-docs/snippets/agentgateway.md" >}} sends the token in the `Authorization` header with a `Bearer` prefix, which overrides the default SigV4 signing. The endpoint, region, and invocation path are still derived from the ARN. +2. Create the backend and reference the Secret with a `policies.auth.secretRef` setting. {{< reuse "agw-docs/snippets/agentgateway-capital.md" >}} sends the token in the `Authorization` header with a `Bearer` prefix, which overrides the default SigV4 signing. The endpoint, region, and invocation path are still derived from the ARN. ```yaml kubectl apply -f- < Date: Thu, 16 Jul 2026 08:18:10 -0400 Subject: [PATCH 12/13] Removed note. Signed-off-by: Kristin Brown --- assets/agw-docs/pages/agentgateway/agent/agentcore.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 01cadc83d..0f5c37c44 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -1,7 +1,5 @@ With {{< reuse "agw-docs/snippets/agentgateway.md" >}}, you can route requests directly to an [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) agent runtime by using an `{{< reuse "agw-docs/snippets/backend.md" >}}` resource. You do not need a separate proxy, custom code, or the AWS SDK. -> [!NOTE] -> Unlike connecting to [agent-to-agent (A2A) servers]({{< link-hextra path="/agent/a2a/" >}}), this integration does not use the A2A protocol. AgentCore is configured as an AWS backend, so you do not set the `appProtocol: kgateway.dev/a2a` field or use the `a2a` backend type. ## About AWS Bedrock AgentCore {#about} From d9797f007031032372e70e3f6a0a78368f25eb31 Mon Sep 17 00:00:00 2001 From: Art Berger Date: Fri, 17 Jul 2026 17:26:08 -0400 Subject: [PATCH 13/13] more auth details and output from testing Signed-off-by: Art Berger --- .../pages/agentgateway/agent/agentcore.md | 77 ++++++++++++++++--- 1 file changed, 68 insertions(+), 9 deletions(-) diff --git a/assets/agw-docs/pages/agentgateway/agent/agentcore.md b/assets/agw-docs/pages/agentgateway/agent/agentcore.md index 0f5c37c44..c110dc038 100644 --- a/assets/agw-docs/pages/agentgateway/agent/agentcore.md +++ b/assets/agw-docs/pages/agentgateway/agent/agentcore.md @@ -7,11 +7,18 @@ Amazon Bedrock AgentCore is a runtime that hosts deployed agents, each with its ### Authentication {#authentication} -AgentCore runtimes support two authentication modes, which you choose when you deploy the runtime in AWS. The `aws.agentCore` backend supports both: +AgentCore runtimes support two authentication modes, which you choose when you deploy the runtime in AWS. The `aws.agentCore` backend supports both IAM (SigV4) or JWT authorization. -* **IAM (SigV4)**: The default. {{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with AWS Signature Version 4 (SigV4) by using the standard [AWS credential lookup](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) from the proxy's environment, such as [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) on Amazon EKS. You do not store long-lived credentials in the gateway configuration, and IRSA credentials rotate automatically. -* **JWT authorizer** (for example, Amazon Cognito): The runtime validates an OIDC bearer token on each request. To use this mode, attach a backend authentication policy that sends the token in the `Authorization` header. This overrides the default SigV4 signing. Unlike SigV4 credentials, a JWT expires, so you must refresh the token in the backing Kubernetes Secret before it expires. +{{< tabs >}} +{{% tab name="IAM (SigV4)" %}} +IAM (SigV4) is the default. {{< reuse "agw-docs/snippets/agentgateway.md" >}} signs each request with AWS Signature Version 4 (SigV4) by using the standard [AWS credential lookup](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) from the proxy's environment, such as [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) on Amazon EKS. You do not store long-lived credentials in the gateway configuration, and IRSA credentials rotate automatically. +{{% /tab %}} +{{% tab name="JWT authorization" %}} +JWT authorization, such as with Amazon Cognito. The AgentCore runtime validates an OIDC bearer token on each request. To use this mode, attach a backend authentication policy that sends the token in the `Authorization` header. This overrides the default SigV4 signing. Unlike SigV4 credentials, a JWT expires, so you must refresh the token in the backing Kubernetes Secret before it expires. +This mode works only if the AgentCore runtime was deployed with **Inbound Auth** configured to accept JSON Web Tokens (a `customJWTAuthorizer`). The authorizer's `discoveryUrl` and `allowedClients` list must match the token you send: the token's issuer (`iss`) must match the discovery URL's user pool, and the token's client ID must be in `allowedClients`. If the runtime uses the default IAM authorization instead, it rejects bearer tokens with an authorization-method mismatch. You configure Inbound Auth when you deploy the runtime in AWS, not on the gateway. For more information, see the [AgentCore Identity documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-inbound-auth.html). +{{% /tab %}} +{{< /tabs >}} ## Before you begin {#before-you-begin} @@ -20,9 +27,15 @@ AgentCore runtimes support two authentication modes, which you choose when you d Additionally, make sure that you have the following: 1. An Amazon Bedrock AgentCore agent runtime that is deployed in your AWS account. For steps to build and deploy a runtime, see the [Amazon Bedrock AgentCore documentation](https://docs.aws.amazon.com/bedrock-agentcore/). You also need the runtime's ARN, in the format `arn:aws:bedrock-agentcore:::runtime/`. -2. Credentials for the runtime's authentication mode: - * For **IAM (SigV4)**, AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy and that are allowed to invoke the runtime. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role with the proxy's Kubernetes service account. - * For a **JWT authorizer**, a valid OIDC bearer token that the runtime's authorizer accepts, such as an Amazon Cognito access or ID token. +2. Credentials for the runtime's authentication mode. + {{< tabs >}} +{{% tab name="IAM (SigV4)" %}} +For **IAM (SigV4)**, AWS credentials that are available to the {{< reuse "agw-docs/snippets/agentgateway.md" >}} proxy and that are allowed to invoke the runtime. The proxy uses the standard AWS credential chain, such as an IAM role, environment variables, or an instance profile. On Amazon EKS, the recommended approach is [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html): associate an IAM role with the proxy's Kubernetes service account. +{{% /tab %}} +{{% tab name="JWT authorization" %}} +For a **JWT authorizer** such as Amazon Cognito, the AgentCore runtime must be deployed with Inbound Auth configured to accept JSON Web Tokens, including the correct discovery URL and allowed client ID for the identity provider that issues your tokens. You also need a valid OIDC bearer token that the runtime's authorizer accepts, such as an Amazon Cognito access token. AgentCore validates the token's `client_id` claim, which is present in Cognito access tokens but not ID tokens, so use the access token. +{{% /tab %}} + {{< /tabs >}} ## Step 1: Create a backend for the AgentCore runtime {#backend} @@ -48,7 +61,45 @@ EOF ``` {{% /tab %}} {{% tab name="JWT authorizer" %}} -1. Store the bearer token that the runtime's authorizer accepts in a Kubernetes Secret. When you use the default Secret resolver, the token must be stored under the `Authorization` key. +1. Get a bearer token that the runtime's authorizer accepts. The following example authenticates a user against an Amazon Cognito user pool and captures the resulting access token. The app client must have the `USER_PASSWORD_AUTH` flow enabled. For browser-based sign-in or machine-to-machine access, use the [Cognito Hosted UI or an OAuth flow](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-integration.html) instead. Which command you run depends on whether the app client has a client secret. + + > [!IMPORTANT] + > Capture the **access token** (`AuthenticationResult.AccessToken`), not the ID token. AgentCore validates the token's `client_id` claim against the runtime's `allowedClients`. Cognito puts the client ID in the `client_id` claim of access tokens, but in the `aud` claim of ID tokens, so an ID token fails with a `client_id` mismatch. The user pool that issues the token must also be the one in the runtime's discovery URL, or the token fails with an `iss` mismatch. + + * **No client secret**: Replace the app client ID, username, password, and region with your own values. + + ```sh + export AGENTCORE_JWT=$(aws cognito-idp initiate-auth \ + --auth-flow USER_PASSWORD_AUTH \ + --client-id \ + --auth-parameters USERNAME=,PASSWORD= \ + --region \ + --query 'AuthenticationResult.AccessToken' --output text) + ``` + + * **With client secret**: If the app client has a secret, Cognito requires a `SECRET_HASH` parameter, which is a Base64-encoded HMAC-SHA256 of the username and client ID keyed by the client secret. Replace the placeholder values with your own. The `USERNAME` value must be identical in both the hash and the `initiate-auth` call. To find the client secret, run `aws cognito-idp describe-user-pool-client --user-pool-id --client-id --query 'UserPoolClient.ClientSecret' --output text`. A client secret is set when the app client is created and cannot be removed afterward. + + ```sh + CLIENT_ID= + CLIENT_SECRET= + USERNAME= + + SECRET_HASH=$(printf "%s" "${USERNAME}${CLIENT_ID}" \ + | openssl dgst -sha256 -hmac "$CLIENT_SECRET" -binary \ + | openssl base64) + + export AGENTCORE_JWT=$(aws cognito-idp initiate-auth \ + --auth-flow USER_PASSWORD_AUTH \ + --client-id "$CLIENT_ID" \ + --auth-parameters USERNAME="$USERNAME",PASSWORD='',SECRET_HASH="$SECRET_HASH" \ + --region \ + --query 'AuthenticationResult.AccessToken' --output text) + ``` + + > [!NOTE] + > Cognito tokens expire (one hour by default). When the token expires, get a new one and update the Secret. You can use the refresh token from the initial response with the `REFRESH_TOKEN_AUTH` flow to avoid re-entering credentials. + +2. Store the bearer token that the runtime's authorizer accepts in a Kubernetes Secret. When you use the default Secret resolver, the token must be stored under the `Authorization` key. ```sh kubectl create secret generic agentcore-jwt \ @@ -56,7 +107,7 @@ EOF --from-literal=Authorization="$AGENTCORE_JWT" ``` -2. Create the backend and reference the Secret with a `policies.auth.secretRef` setting. {{< reuse "agw-docs/snippets/agentgateway-capital.md" >}} sends the token in the `Authorization` header with a `Bearer` prefix, which overrides the default SigV4 signing. The endpoint, region, and invocation path are still derived from the ARN. +3. Create the backend and reference the Secret with a `policies.auth.secretRef` setting. {{< reuse "agw-docs/snippets/agentgateway-capital.md" >}} sends the token in the `Authorization` header with a `Bearer` prefix, which overrides the default SigV4 signing. The endpoint, region, and invocation path are still derived from the ARN. ```yaml kubectl apply -f- <