AWS bedrock-agentcore medium security documentation change
Summary
Expanded VPC interface endpoint documentation with authentication details, regional availability, and granular endpoint policy examples for different components
Security assessment
Added explicit security considerations about OAuth authentication requiring wildcard principals in endpoint policies, demonstrated secure policy configurations for different components, and explained authorization modes. These changes directly impact security posture by clarifying access control requirements and potential misconfiguration risks.
Diff
diff --git a/bedrock-agentcore/latest/devguide/vpc-interface-endpoints.md b/bedrock-agentcore/latest/devguide/vpc-interface-endpoints.md index d8dcb3538..0226fd9ba 100644 --- a//bedrock-agentcore/latest/devguide/vpc-interface-endpoints.md +++ b//bedrock-agentcore/latest/devguide/vpc-interface-endpoints.md @@ -21 +21 @@ Before you set up an interface endpoint for AgentCore, review [Considerations](h -AgentCore supports invoking gateways through the interface endpoint. +AgentCore supports the following through interface endpoints: @@ -23 +23,29 @@ AgentCore supports invoking gateways through the interface endpoint. -By default, full access to AgentCore is allowed through the interface endpoint. Alternatively, you can associate a security group with the endpoint network interfaces to control traffic to AgentCore through the interface endpoint. + * Data plane operations (runtime APIs) + + * Invoking gateways + + + + +###### Note + +Privatelink is currently not supported for Amazon Bedrock AgentCore control plane endpoints. + +AgentCore interface endpoints are available in the following AWS Regions: + + * US East (N. Virginia) + + * US West (Oregon) + + * Europe (Frankfurt) + + * Asia Pacific (Sydney) + + + + +###### Authorization considerations for data plane APIs + +The data plane APIs support both AWS Signature Version 4 (SigV4) headers for authentication and Bearer Token (OAuth) authentication. VPC endpoint policies can only restrict callers based on IAM principals and not OAuth users. For OAuth-based requests to succeed through the VPC endpoint, the principal must be set to `*` in the endpoint policy. Otherwise, only SigV4 allowlisted callers can make successful calls over the VPC endpoint. + +AWS IAM global condition context keys are supported. By default, full access to AgentCore is allowed through the interface endpoint. You can control access by attaching an endpoint policy to the interface endpoint or by associating a security group with the endpoint network interfaces. @@ -29 +57 @@ You can create an interface endpoint for AgentCore using either the Amazon VPC c -Create an interface endpoint for AgentCore using one of the following service names: +Create an interface endpoint for AgentCore using the following service name format: @@ -31 +59 @@ Create an interface endpoint for AgentCore using one of the following service na - * For AgentCore Gateway : + * Data plane operations: `com.amazonaws.`region`.bedrock-agentcore` @@ -33 +61 @@ Create an interface endpoint for AgentCore using one of the following service na - com.amazonaws.region.bedrock-agentcore.gateway + * For AgentCore Gateway : `com.amazonaws.`region`.bedrock-agentcore.gateway` @@ -59 +87 @@ For more information, see [Control access to services using endpoint policies](h -###### Example: VPC endpoint policy for AgentCore Gateway actions +###### Endpoint policies for various primitives @@ -61 +89,26 @@ For more information, see [Control access to services using endpoint policies](h -The following is an example of a custom endpoint policy. When you attach this policy to your interface endpoint, it allows all principals to invoke the gateway specified in the `Resource` field. +The following examples show endpoint policies for different AgentCore components: + +Runtime + + +The following endpoint policy allows specific IAM principals to invoke agent runtime resources. + + + { + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws::iam::ACCOUNT_ID:user/USERNAME" + }, + "Action": [ + "bedrock-agentcore:InvokeAgentRuntime" + ], + "Resource": "arn:aws::bedrock-agentcore:us-east-1:ACCOUNT_ID:runtime/RUNTIME_ID" + } + ] + } + +###### Mixed IAM and OAuth authentication + +The `InvokeAgentRuntime` API supports two modes of VPC endpoint authorization. The following example policy allows both IAM principals and OAuth callers to access different agent runtime resources. @@ -66,0 +120,11 @@ The following is an example of a custom endpoint policy. When you attach this po + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws::iam::ACCOUNT_ID:root" + }, + "Action": [ + "bedrock-agentcore:InvokeAgentRuntime" + ], + "Resource": "arn:aws::bedrock-agentcore:us-east-1:ACCOUNT_ID:runtime/customAgent1" + }, + { + "Effect": "Allow", @@ -67,0 +132,61 @@ The following is an example of a custom endpoint policy. When you attach this po + "Action": [ + "bedrock-agentcore:InvokeAgentRuntime" + ], + "Resource": "arn:aws::bedrock-agentcore:us-east-1:ACCOUNT_ID:runtime/customAgent2" + } + ] + } + +The above policy allows only the IAM principal to make `InvokeAgentRuntime` calls to `customAgent1`. It also allows both IAM principals and OAuth callers to make `InvokeAgentRuntime` calls to `customAgent2`. + +Code Interpreter + + +The following endpoint policy allows specific IAM principals to invoke Code Interpreter resources. + + + { + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws::iam::ACCOUNT_ID:root" + }, + "Action": [ + "bedrock-agentcore:InvokeCodeInterpreter" + ], + "Resource": "arn:aws::bedrock-agentcore:us-east-1:ACCOUNT_ID:code-interpreter/CODE_INTERPRETER_ID" + } + ] + } + +Browser Tool + + +The following endpoint policy allows specific IAM principals to connect to Browser Tool resources. + + + { + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws::iam::ACCOUNT_ID:root" + }, + "Action": [ + "bedrock-agentcore:ConnectBrowserAutomationStream" + ], + "Resource": "arn:aws::bedrock-agentcore:us-east-1:ACCOUNT_ID:browser/BROWSER_ID" + } + ] + } + +Gateway + + +The following is an example of a custom endpoint policy. When you attach this policy to your interface endpoint, it allows all principals to invoke the gateway specified in the `Resource` field. + + + { + "Statement": [ + { @@ -69 +194,4 @@ The following is an example of a custom endpoint policy. When you attach this po - "Action": "*", + "Principal": "*", + "Action": [ + "*" + ],