Understanding IAM with Grandpa's Corvette
AWS Identity and Access Management (IAM) is a powerful tool for managing access to AWS resources. In this blog post, we‘ll explore the basics of IAM, starting with same account permissions and then delving into cross-account access. We‘ll do it from the perspective of a grandpa trying to let his grandson drive his corvette.
Same Account Permissions
When working within a single AWS account, IAM allows you to create users, groups, and roles to manage access to resources. Grandpa (account root) wants to Allow his grandson, Billy, (IAM User) to Drive (Action) his Red Corvette (Resource). To do this, Grandpa just gives gives Billy a note (attaches a identity-based policy) that says he can drive the corvette (policy statement).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "Drive",
"Resource": "RedCorvette"
}
]
}
The US Government does not appreciate Grandpa letting Billy drive his Red Corvette, primarily because Billy is eight years old. That‘s okay! Grandpa gives Billy a fake mustache and sunglasses, now in the government‘s eyes he looks like a responsible teen. IN AWS terms, this is known as assuming a role.
Grandpa creates the Responsible Teen Role and gives Billy permissions to assume it. He attaches a policy to the new role that allows driving the red corvette. This step becomes necessary when granting cross-account permissions which are explored in the next section.
Cross-Account Permissions
IAM enables you to grant access to resources in one AWS account to users in another AWS account. This is known as cross-account access. Let‘s see what this means for little Billy.
Uh oh! Now Billy has to go back to his house. Mom (account root user) is in charge. A common misconception for new AWS Architects is that a trusting account can allow a trusted account‘s identities to access its resources. This is not entirely true. Grandpa can tell Billy that he can drive the Red Corvette, but if Billy tries, then Mom will ground him.
When a trusting AWS account grants access to a trusted AWS account, they are actually giving the trusted AWS account‘s root user the ability to grant access to the trusting account‘s resources.
The only thing Grandpa can do is tell Mom that Billy is allowed to drive the Red Corvette. If she Denys Billy from driving, then there is nothing Billy or his Grandpa can do... calling her a helicopter parent probably does not help.
This is where things get tricky. Little Billy buys Mom flowers, does extra chores, and even takes her dancing. After eight years of this, she finally agrees to let him drive the Red Corvette! It‘s been awhile, so lets recap the hoops he needs to jump through to drive. To drive the Red Corvette, Billy needs to put on the fake mustache and sunglasses at Grandpa‘s house. Grandpa must tell Mom that Billy can put on the mustache and sunglasses. Mom must also allow Billy to put on the fake mustache and sunglasses. With both Mom and Grandpa‘s permissions to assume the role, Billy can do anything the role allows after assuming it.
First, in Grandpa‘s account create an IAM policy that allows driving the Corvette.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"Drive"
],
"Resource": [
"RedCorvette"
]
}
]
}
Next, create the Responsible Teen role in Grandpa‘s account and attach the policy to the role. Then give Mom access to let Billy assume this role.
{
"Version": "2012-10-17",
"Statement": [
{
Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::GRANDSON-HOME-ID:root"
},
"Action": "sts:AssumeRole"
}
]
}
In Mom‘s account, create an IAM policy that allows Billy to assume the responsible teen role.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::GRANDPA-HOME-ID:role/ResponsibleRole"
}
]
}
Attach this policy to the Billy‘s execution role (assuming he is a Lambda). Billy can finally drive the Red Corvette!
Resource-Based Policies
AWS has some features to simplify this. Many AWS Services including S3, API Gateway, and now even DynamoDB support resource-based-policies. So rather than attaching the policy to a proxy role, the policy is attached to a resource. In our previous examples, the policy that gave access to drive the car was granted to the responsible teen role. With a resource-based policy, Grandpa can just put a note in the car that grants Billy access. No more silly mustaches! This can greatly simplify cross-account access. Grandpa can delete the Responsible Teen Role and Mom can grant access to drive the red corvette, and does not need to be concerned about roles at Grandpa‘s house.
Conclusion
AWS Identity and Access Management (IAM) is a powerful tool for managing access to AWS resources, both within a single account and across multiple accounts. By understanding the concepts of same account permissions, cross-account access, and resource-based policies, you can effectively control and manage access to your AWS resources.
Just like Grandpa giving Billy permission to drive his Red Corvette, IAM allows you to grant specific permissions to users, roles, and resources. Same account permissions are straightforward, where you can attach identity-based policies directly to users or roles. Cross-account access requires a bit more coordination, similar to Billy needing permission from both Grandpa and Mom to drive the car. Resource-based policies simplify cross-account access by attaching policies directly to resources, eliminating the need for proxy roles.
By mastering IAM, you can ensure that your AWS resources are secure and accessible only to authorized entities. Whether you‘re a seasoned AWS architect or just starting your cloud journey, understanding IAM is crucial for building secure and well-managed applications in the AWS ecosystem. So, put on your fake mustache, buckle up, and take control of your AWS resources with IAM!