This is our fourth and final blog post celebrating AWS Identity and Access Management (IAM) ‘s 10th anniversary, where we give you top recommendations on IAM from AWS Heroes and AWS Partner Network (APN) Ambassadors .
AWS Identity and Access Management (IAM)‘s 10th anniversary, where we give you top recommendations on IAM from AWS Heroes and AWS Partner Network (APN) Ambassadors.
In Part 1 of the series , Rowan Udell covered how to balance developer innovation with the principle of least privilege and elaborated on IAM resource IDs. In Part 2, Ben Bridts showed how the IAM visual editor makes policy creation easier and explained the benefits of using federation over IAM users.
Part 1 of the series, Rowan Udell covered how to balance developer innovation with the principle of least privilege and elaborated on IAM resource IDs. In
Part 2, Ben Bridts showed how the IAM visual editor makes policy creation easier and explained the benefits of using federation over IAM users.
In Part 3 of the series, Ian Mckay highlighted how permissions boundaries and conditions help you limit access to Amazon Web Services (AWS).
For this final post, I’d like to talk about the permissions that are available and how to find out who did what in your AWS account.
Part 3 of the series, Ian Mckay highlighted how permissions boundaries and conditions help you limit access to Amazon Web Services (AWS). For this final post, I’d like to talk about the permissions that are available and how to find out who did what in your AWS account.
I am a Distinguished Cloud Strategist at Lacework, an AWS Security Competency Partner and managed platform that automates cloud security, empowering IT to continuously keep cloud environments secure and compliant.
I work with teams to modernize their security practices and to get the most out of the cloud. With a strong focus on automation, I enjoying bridging the gap between DevOps and traditional security through coaching, writing, speaking, and engaging with the AWS community.
Understanding What Permissions Are Available
When it debuted 10 years ago , IAM supported a strong list of 15 services. Today, it’s woven into the core of everything in the AWS Cloud. This has opened up new security and access scenarios that aren’t realistic in other environments.
When it debuted 10 years ago, IAM supported a strong list of 15 services. Today, it’s woven into the core of everything in the AWS Cloud. This has opened up new security and access scenarios that aren’t realistic in other environments.
As Ben points out in Part 2 of this series, the permissions available can be overwhelming.
While he provides a fantastic method to find the needed permissions, I’d like to call your attention to the Service Authorization Reference .
Part 2 of this series, the permissions available can be overwhelming. While he provides a fantastic method to find the needed permissions, I’d like to call your attention to the Service Authorization Reference.
Most would refer to this as simply “the documentation,” but I think the sheer scope of what’s available in the Reference justifies its name. The Reference lists out all of the actions, resources, and condition keys available in the IAM system.
This is not only a one-stop shop for builders looking to properly build policies, but—and perhaps more importantly—it’s a complete reference for security and compliance teams who are looking to understand what permissions to grant within the environment.
The Service Authorization Reference is organized by AWS service. Simply select the service you’re interested in, and you’ll see the following:
- A link to the user guide for the service (labeled often as “learn how to configure this service”).
- Links to the API reference documentation for the service.
- A table that lists all IAM actions for the service.
- An explanation of resource type structures for the service.
- Service-specific conditions to help scope permissions.
If it seems odd to call out the documentation in a post about recommendations for getting the most out of IAM, let me explain a key challenge that faces security and audit teams.
These teams might not be building actively in the AWS Cloud all of the time. It’s not uncommon for their responsibilities to span the entire organization and all IT systems within it. It’s challenging enough (in a good way!) for those of us immersed in AWS to keep up with all of the excellent new features; can you imagine if your focus was elsewhere?
The Service Authorization Reference addresses this challenge by providing a comprehensive list of all the permissions within the AWS Cloud. This type of reference is indispensable for any team that is working on AWS, and doubly so for security and compliance teams.
There’s a reason that “Reading the Friendly Manual” has lasted for decades as a key troubleshooting step. It often provides a solution and is definitely easier when the M is a well-structured, comprehensive reference!
Who Did That?
Although IAM is integrated with all of the other AWS services, one of its best—and often unsung—features only shows up in another service.
Builders know that AWS CloudTrail logs most of the activities that occur in your AWS account. The activities are stored by CloudTrail as records in JSON format.
AWS CloudTrail logs most of the activities that occur in your AWS account. The activities are stored by CloudTrail as records in JSON format.
But did you know that every CloudTrail entry also contains a userIdentity element?
This part of the JSON structure contains a treasure trove of who took a specific action in your account. This is a critical feature for forensics, audit and compliance, and troubleshooting.
who took a specific action in your account. This is a critical feature for forensics, audit and compliance, and troubleshooting.
The feature is now even more powerful with the new SourceIdentity element , which shows the original identity of who made the request even across multiple AssumeRole actions.
Each userIdentity element contains the following information, as seen in the CloudTrail documentation.
The block provides the Amazon Resource Name (ARN) of the entity that made the API call. The type attribute shows us that, in this case, it was an IAM user, and the userName attribute tells us that it was Alice.
Amazon Resource Name (ARN) of the entity that made the API call. The type attribute shows us that, in this case, it was an IAM user, and the userName attribute tells us that it was Alice.
If the call was made while using temporary credentials—and we know from Ben’s tip that most requests should be—the userIdentity element contains additional information, shown following. Again, this is taken from the CloudTrail documentation.
Now, you have the session information for the temporary credentials that are managed by the AWS Security Token Service , the service behind the IAM role system.
AWS Security Token Service, the service behind the IAM role system.
This information is useful for troubleshooting and helping to build policies that adhere to the principle of least privilege. In fact, this data is the foundation for the new policy generator feature in the IAM Access Analyzer.
For security and compliance teams, this information is invaluable during incident response or forensic activities. Despite everyone’s best efforts to create policies and roles that have least privilege, most incidents still result from misconfiguration.
The role might grant only the permissions that are required to accomplish a task, but is the role sufficiently restricted to make sure that only the correct entity can assume that role?
Mistakes happen. The userIdentity element in AWS CloudTrail will help you verify who made a specific API call and identify if anything is out of place.
The element is added automatically to every CloudTrail entry, so no additional work is required by your team. If you never have to use it, you’ve lost nothing. In the cases where you need to know who took a specific action, this element can be a lifesaver.
Summary
In this four-part blog series, we gave you our top recommendations for working with AWS Identity and Access Management (IAM). In the first part, we learned from Rowan how to balance developer innovation with security for builders across their environments and visited IAM’s unique IDs.
Next, Ben covered how the IAM visual editor helps you craft IAM policies and why federation is a better option than using users. Ian then illustrated how to limit IAM actions through permissions boundaries and showcased the fine-grained access possible through IAM conditions.
Finally, I shared in this post about the Service Authorization Reference , which is a comprehensive list of all the permissions in AWS, and pointed you to the AWS CloudTrail userIdentity element that keeps track of who did what.
Service Authorization Reference, which is a comprehensive list of all the permissions in AWS, and pointed you to the AWS CloudTrail userIdentity element that keeps track of who did what.
We hope our suggestions help you to better understand and secure your footprint in AWS. Thank you for celebrating IAM’s 10th anniversary with us!
Be sure to check out the other posts in our IAM 10th anniversary series on the APN Blog:
- Part 1 – Rowan Udell shares why less is more when it comes to privileges
- Part 2 – Ben Bridts discusses IAM’s visual editor and federation
- Part 3 – Ian Mckay explores permissions boundaries and conditions
The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.
