AWS bedrock-agentcore documentation change
Summary
Added role-based access control patterns and expanded documentation to cover both OAuth and IAM authentication methods with specific examples for each
Security assessment
This change adds comprehensive documentation about implementing role-based access control (RBAC) patterns using Cedar policies, which is a security feature. It provides specific examples for both OAuth (using role tags) and IAM (using role ARNs) authentication methods, enabling better access control implementation. However, there is no evidence this addresses a specific security vulnerability or incident - it appears to be routine documentation enhancement for security features.
Diff
diff --git a/bedrock-agentcore/latest/devguide/policy-common-patterns.md b/bedrock-agentcore/latest/devguide/policy-common-patterns.md index 7a1e18a77..5a42fbe2d 100644 --- a//bedrock-agentcore/latest/devguide/policy-common-patterns.md +++ b//bedrock-agentcore/latest/devguide/policy-common-patterns.md @@ -5 +5 @@ -Emergency shutdownDisable specific toolBlock user accessData type operations +Emergency shutdownDisable specific toolBlock user accessRole-based access controlData type operations @@ -9 +9,3 @@ Emergency shutdownDisable specific toolBlock user accessData type operations -These examples demonstrate frequently used Cedar policy patterns for common authorization scenarios in Amazon Bedrock AgentCore Gateway. +These examples demonstrate frequently used Cedar policy patterns. The patterns work with both OAuth and IAM authentication—select the appropriate principal type for your AgentCore Gateway configuration. For details on principal attributes, see [Principal attributes](./policy-conditions.html#policy-principal-attributes). + +These patterns apply regardless of authentication type. @@ -41 +43,5 @@ Disable a specific tool while keeping others operational: -Prevent a specific user from performing any actions: +Prevent specific users or accounts from performing any actions: + +### OAuth: Block specific user + +Block a user by matching their username tag: @@ -55,0 +62,62 @@ Prevent a specific user from performing any actions: +### IAM: Block specific account + +Block callers from a specific AWS account: + + + forbid( + principal is AgentCore::IamEntity, + action, + resource + ) + when { + principal.id like "*:444455556666:*" + }; + +**Use case:** Block test or unauthorized accounts from accessing production tools. + +## Role-based access control + +Restrict access based on roles. OAuth uses role tags; IAM uses role ARN patterns. + +### OAuth: Using role tags + +Permit access only to users with specific roles: + + + permit( + principal is AgentCore::OAuthUser, + action == AgentCore::Action::"AdminAPI__delete_resource", + resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/admin" + ) + when { + principal.hasTag("role") && + (principal.getTag("role") == "admin" || principal.getTag("role") == "manager") + }; + +**Use case:** Allow administrative operations only for users with admin or manager roles. + +### IAM: Using IAM role ARNs + +Permit access only to callers using specific IAM roles: + + + permit( + principal is AgentCore::IamEntity, + action == AgentCore::Action::"AdminAPI__delete_resource", + resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/admin" + ) + when { + principal.id like "arn:aws:iam::*:role/AdminRole" + }; + +**Use case:** Allow administrative operations only for callers using the AdminRole IAM role. + +**Variations:** + + + // Match assumed role sessions + principal.id like "arn:aws:sts::*:assumed-role/AdminRole/*" + + // Match any role in a specific account + principal.id like "arn:aws:iam::123456789012:role/*" + @@ -58 +126 @@ Prevent a specific user from performing any actions: -Cedar supports various data types in conditions. Here are examples showing how to work with them: +Cedar supports various data types in conditions. These examples use OAuth principals (`AgentCore::OAuthUser`). For IAM-authenticated gateways, use `AgentCore::IamEntity` instead - the input validation logic remains identical.