Common scenarios for using roles

We now have a clearer idea of what IAM Roles are and what they can be used for, but let’s cement our understanding with real-world examples of common scenarios.

Enable cross-account access

For our first scenario, let’s say that you work for an IT consulting company. Another company is migrating to the cloud from on-prem and has hired your services to help them architect and secure their deployments for 3 months.

You will only require a certain level of access to a handful of services including:

• Amazon’s Elastic Kubernetes Service, or EKS
• Specific Amazon S3 buckets
• and AWS Lambda

Instead of going in and creating an IAM User for you, the organization can create an IAM Role in the AWS account that has those resources, and you can assume that cross-account role to perform your job functions.

Using trust policies that we’ll explain in greater detail in another lesson, you can set up roles to be assumable by identities from other AWS accounts into your AWS account, and you can not only implement very tight permissions, but you can also set up monitoring & alerting to keep a very close eye on those roles.

Also, the organization hiring you doesn’t have to worry about creating or managing passwords or access keys for you. All they have to do is create the role, assign permissions to that role, and that’s it. Then they can delete the role or revoke your access whenever they want.

Access workloads within AWS

Roles aren’t just useful for users, though. As another scenario, roles can be assumed by AWS services running your workloads.

For example, if you are running an EC2 instance with an application hosted on it, and that application needs to access files in Amazon S3, you can provide a role for the EC2 instance to assume through an instance profile, and the application on the EC2 instance will receive access to the S3 data through that role.

Zero need for hardcoded credentials, and no need to manage any credentials for your AWS workloads.

These roles that can be assumed by AWS services are called service roles.

Access workloads running outside of AWS

Now, you can even use roles *outside* of AWS to provide workloads running outside of AWS access to your AWS resources without requiring hardcoded credentials! This is a relatively new feature at the time of writing, and it’s a very important one. It’s called IAM Roles Anywhere, and it makes use of certificates and certificate authorities to grant resources outside of AWS access to AWS resources using roles.

This is great for on-prem workloads, or even for deployment pipelines. Like if you are using GitLab for your repositories and deployments, you can use IAM Roles Anywhere while the application is in GitLab and before it gets deployed to AWS, and avoid hardcoding credentials which can be leveraged by attackers if they get access to your GitLab.

Grant access to AWS services

We talked about how roles can be used by your AWS workloads when running in AWS to access other AWS services. Sometimes, though, there are AWS services that need to perform actions in your account behind the scenes, and that requires providing them with something called a service-linked role (not to be confused with service roles we talked about above…I know…I didn’t come up with this…!).

Examples of this include services like:

• AWS Config
• Security Hub
• Inspector
• Etc…

Those services need roles that they can assume to do their job without your interaction, and those are service-linked roles. We’ll talk more about that a little bit later on in the course, but I wanted to introduce that as another scenario where roles are commonly used.

Conclusion

Of course, there are more scenarios of when roles make sense, but I just wanted to provide a few concrete examples before we move on. If you have any questions about these let me know in the comments below! Otherwise, I’ll see you in the next lesson.