AWS bedrock-agentcore documentation change
Summary
Updated documentation for No Authorization gateways to clarify they can be used in production with custom authentication mechanisms like interceptor Lambda functions, and added comprehensive documentation for using private (VPC-hosted) identity providers with JWT-based inbound authorization including configuration examples and security best practices.
Security assessment
The changes primarily enhance security documentation by providing clearer guidance on secure gateway configurations. The updates to No Authorization gateways clarify that they can be used in production with proper authentication mechanisms, which is a security best practice clarification rather than addressing a specific vulnerability. The addition of private identity provider documentation adds security-focused content about keeping identity providers within VPCs to avoid internet exposure, which improves security posture but doesn't indicate a specific security issue was fixed.
Diff
diff --git a/bedrock-agentcore/latest/devguide/gateway-inbound-auth.md b/bedrock-agentcore/latest/devguide/gateway-inbound-auth.md index d15a64f07..a3956e540 100644 --- a//bedrock-agentcore/latest/devguide/gateway-inbound-auth.md +++ b//bedrock-agentcore/latest/devguide/gateway-inbound-auth.md @@ -24 +24 @@ Before you create your gateway, you must set up inbound authorization. Inbound a -Do not use No Authorization gateways for production workloads. No Authorization gateways should only be used for testing and development purposes where security is not a primary concern. +Do not use No Authorization gateways for production workloads unless you have implemented your own authentication mechanism, such as an interceptor Lambda function. See No Authorization for security best practices. @@ -107,0 +108,2 @@ You can use the AgentCore CLI to set up a default JWT, or create one manually wi + * Use a private (VPC-hosted) identity provider + @@ -171,0 +174,64 @@ The `scope` value contains the space-delimited scopes configured as **Allowed sc +### Use a private (VPC-hosted) identity provider + +AgentCore Gateway supports JWT-based inbound authorization with identity providers hosted inside your VPC. You can configure a `privateEndpoint` on the `customJWTAuthorizer` to enable AgentCore to reach your private OIDC discovery, token, and JWKS endpoints without exposing them to the public internet. + +Your IAM principal must have the `iam:CreateServiceLinkedRole` permission for `identity-network.bedrock-agentcore.amazonaws.com`, so that AgentCore Identity can create the `AWSServiceRoleForBedrockAgentCoreIdentity` service-linked role on your behalf if it does not already exist. + +The `privateEndpoint` applies to the domain in the `discoveryUrl`. If your identity provider uses different domains for other endpoints (for example, the token or JWKS endpoint resolves to a different domain than the discovery URL), use `privateEndpointOverrides` to specify a separate private endpoint configuration for each additional domain. + +The following example creates a gateway with a private identity provider using managed Lattice: + + + { + "name": "my-private-idp-gateway", + "protocolType": "MCP", + "roleArn": "arn:aws:iam::123456789012:role/my-gateway-role", + "authorizerType": "CUSTOM_JWT", + "authorizerConfiguration": { + "customJWTAuthorizer": { + "allowedAudience": [ + "my-audience" + ], + "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration", + "privateEndpoint": { + "managedVpcResource": { + "vpcIdentifier": "vpc-0abc123def456", + "subnetIds": ["subnet-0abc123", "subnet-0def456"], + "endpointIpAddressType": "IPV4", + "securityGroupIds": ["sg-0abc123def"] + } + } + } + } + } + +If your token or JWKS endpoints use a different domain than the discovery URL, add a `privateEndpointOverrides` entry for each additional domain. Currently, `privateEndpointOverrides` is only supported with self-managed Lattice resources: + + + { + ... + "authorizerConfiguration": { + "customJWTAuthorizer": { + "allowedAudience": ["my-audience"], + "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration", + "privateEndpoint": { + "selfManagedLatticeResource": { + "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123" + } + }, + "privateEndpointOverrides": [ + { + "domain": "my-token-server.internal.example.com", + "privateEndpoint": { + "selfManagedLatticeResource": { + "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-def456" + } + } + } + ] + } + } + } + +For self-managed Lattice, cross-account setups, and advanced configurations, see [Connect to private resources in your VPC using VPC Lattice](./vpc-egress-private-endpoints.html). For a comprehensive guide covering both inbound and outbound private IdP scenarios, see [Connect to private identity providers](./identity-private-idp.html). + @@ -178 +244 @@ You can create a gateway that is configured with no authorization by using `auth -Do not use No Authorization gateways for production workloads unless you have implemented all the security best practices listed below. No Authorization gateways are most appropriate for testing and development purposes. +Do not use No Authorization gateways for production workloads unless you have implemented all the security best practices listed below. If you need custom authentication logic, consider using an [interceptor Lambda function](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html) to handle authentication before requests reach your targets.