A global e-commerce company uses AWS Lambda functions to process sensitive customer order data. The Lambda functions need to retrieve order details from an Amazon DynamoDB table located in a different AWS account (Account B) than where the Lambda functions are deployed (Account A). The security team requires that access to DynamoDB must be tightly controlled using the principle of least privilege and should not expose the Lambda functions to the public internet. Which is the MOST secure and efficient way to grant the Lambda function access to the DynamoDB table?
- AEstablish a VPC Peering connection between a VPC in Account A and a VPC in Account B. Configure route tables to allow traffic between the VPCs. Then, grant the Lambda function's execution role direct access to the DynamoDB table in Account B.
- BCreate a VPC endpoint for DynamoDB in Account A. Configure the Lambda function to use this endpoint. Grant public read-only access to the DynamoDB table in Account B, but restrict it via a DynamoDB resource policy to only allow access from the VPC endpoint's IP range.
- CCreate an IAM user in Account B with read-only access to the DynamoDB table, generate access keys, and store them in AWS Secrets Manager in Account A. Configure the Lambda function to retrieve these credentials and use them to access DynamoDB.
- DCreate an IAM role in Account B with read-only access to the DynamoDB table. In Account A, modify the Lambda function's execution role to assume the IAM role in Account B, granting temporary credentials for DynamoDB access.
Show answer & explanationAnswer & explanation
Correct answer: D. Create an IAM role in Account B with read-only access to the DynamoDB table. In Account A, modify the Lambda function's execution role to assume the IAM role in Account B, granting temporary credentials for DynamoDB access.
Using cross-account IAM role assumption is the most secure and recommended method for granting permissions between AWS accounts. It adheres to the principle of least privilege by providing temporary credentials and avoids credential management challenges associated with access keys or exposing resources via public endpoints.
Why the other options are wrong
- A. VPC peering allows network connectivity but doesn't inherently grant cross-account IAM permissions. While it could be part of a solution for private connectivity, the primary mechanism for cross-account *authorization* is IAM roles. Granting direct access to the Lambda role might be too broad without specific role assumption.
- B. DynamoDB VPC endpoints are for private access within a single account or peered VPCs, not directly for cross-account access to a table with a public endpoint. Granting public read-only access is a security risk, even with IP restrictions.
- C. Storing and managing static access keys, even in Secrets Manager, is less secure than temporary credentials from role assumption and adds operational overhead.
Cross-Account Access with IAM Roles
AWS Identity and Access Management (IAM) roles can be used to securely delegate access to AWS resources between different AWS accounts. This involves one account defining a role that can be assumed by an entity (like an IAM role or user) in another account, providing temporary credentials.
- Eliminates the need to share long-term credentials (access keys).
- Adheres to the principle of least privilege by granting temporary, specific permissions.
- Requires a trust policy on the role in the resource account and a permissions policy on the assuming entity in the calling account.
Memory trick: IAM Roles are like 'Guest Passes' for different accounts.