A company's security team wants to delegate the creation and management of IAM roles for microservices to development team leads in several member accounts within an AWS Organization. However, the security team must ensure that team leads cannot create roles or modify policies that allow access to a centralized audit Amazon S3 bucket. Which solution should the security team implement to meet these requirements?
- Configure an IAM permissions boundary that denies access to the centralized audit S3 bucket, and require the team leads to apply this boundary when creating any new IAM roles.Answer
- BShare the AWS account root user credentials of each member account with the team leads so they can perform role administration tasks securely without needing IAM policies.
- CCreate individual IAM users with long-term credentials for each team lead, and store these credentials as plaintext String parameters in Systems Manager Parameter Store for the microservices to use.
- DSet up SAML-based identity federation for team lead access, but create individual IAM users with long-term access keys in each member account for their daily role management tasks.
Answer
Configure an IAM permissions boundary that denies access to the centralized audit S3 bucket, and require the team leads to apply this boundary when creating any new IAM roles.
The correct solution uses an IAM permissions boundary. A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. When you delegate IAM role creation to a user or role, you can enforce that they can only create roles with a specific permissions boundary attached. This prevents the delegated administrator from creating roles that have more permissions than allowed, protecting resources like the central audit S3 bucket.
Step-by-Step Solution
Key Concept
IAM Permissions Boundaries
Estimated Time:1m 30s