Check out this introductory primer on what AWS STS Assuming is and why you should be using it. Feedback welcome, and please come check us out at iampulse.com for other great content and best practice IAM policies and strategies.
Let's elevate IAM
Assuming an AWS IAM Role
Hey all! Welcome back! I hope you’re doing great today, and ready to learn some very cool AWS stuff. I have a cat gently snoring in the background here, so I feel very calm and ready to talk about AWS’s concept of IAM roles, and how they can be assumed using the STS service.My name is Kyler Middleton, and I’m a Cloud IAM Advocate here at IAM Pulse, which means I am doing my best to educate practitioners and elevate IAM knowledge everywhere I can. Thanks so much for listening now - let’s help each other.
Let’s do a quick overview on what the concepts of STS mean before we dig into why we’d want to assume an IAM role and how powerful it can be.
An IAM role is a bucket for permissions, and can be assigned to a human or machine principal. These permissions are represented as a number of policies that can be attached to the principal.
IAM roles have what’s called a Trust Policy that controls what services, like ECS or EC2 are permitted to assume them, and conditions can lock them down even further. Assuming a role means swapping my existing role for the target IAM role’s permissions set. We’ll talk about some reasons why we might do that in a minute.
IAM policies are a global resource in an AWS account. There are some provided by AWS, called Managed Policies. These are a great starting point, but are generally pretty broad in terms of what they grant. To level up your skills in IAM, you should be building your own IAM policies.
STS, or Secure Token Service, is the AWS IAM service that issues tokens used for authentication, and also permits assuming another role when it’s configured for it.
A great first questions to ask is - why? If an IAM role needed a permission, couldn’t we just assigned it to it directly? And that’s sometimes true, but there are a few situations where assuming is really useful, or just downright required.
Most Orgs that use AWS don’t just have a single account, they have LOTS of accounts managed in at least one Org. The permissions boundaries in AWS are pretty firm when it comes to cross-account actions (especially compared to Azure), so we’ll need to explicitly assign permissions for cross-account actions.
Imagine this - we have AccountA where our Builder role lives. It runs CI/CD jobs, so it needs a lot of access. We want it to update services in AccountB. We have two options.
Option 1: Update every service we want the Builder role to update in AccountB - this might take a while! And as new services come online, we’ll need to keep updating them. That sounds like a lot of work!
Option 2: We create a role in AccountB that has permissions to do what we need. Since the role is local to AccountB, most services will permit it to update them. Updating one role in AccountB to have the right permissions sounds much easier. Much more time for naps and mimosas.
Another great use case is just-in-time access. Say we have an ec2 instance that needs to have a lot of access for some jobs it runs overnight. We could absolutely grant that ec2 instance the permissions directly, but then it’d have those broad rights all the time. What if someone accidentally runs a job that uses those permissions? Or that machine is compromised?
A better method is to assign the EC2 instance no rights at all, and tell it to assume a higher permissions set using STS only when it needs it, like right before it runs a job. Then when the job is done, it can release the permissions. That means those broad scary access rights are only live when they are required, and no other time. Sounds way safer to me.
I have lots more to share, but I want to keep these videos short. Next up we’ll cover how to use STS to assume a role, and what safeguards we can put in place to make sure it’s not abused. Till next time!