IAM Actions
Another important thing to understand about IAM is that aren’t just thinking in terms of humans can do. AWS Services themselves need to expose what they offer. IAM actions are the way to define the extent and granularity of permissions.
I think of it as follows:
- Each service will have their own actions table, defining the extent of access that a service will allow.
- One row in the action table is a distinct action that can be granted/denied in an IAM policy.
- It’s up to the policy administrator to work with these to grant the appropriate level of access to a given instance of a service within a given policy
So there’s a relationship between the action table and IAM policies that we need to understand. Let’s prime ourselves with the following questions beforehand:
What is the role of the actions table? What are its key components or building blocks?
What is the relationship between the actions table and IAM policies?
Describe the impedance mismatch of API operation and IAM actions.
What is the access level in the actions table?
What is the resource types column in the actions table? What does its presence or absence signify?
When would we have dependent actions?
What are condition keys in the actions table?
Where is the information about the type of API operation found?
What is the Resource Type table in IAM?
In the case of S3, how would an actions table entry look for AbortPartMultiLoad?
What does a condition key work within the actions table?
Review the Overview
Read the page on the actions IAM actions starting with those questions in mind, and see if you can come up with some of your own. If you’d like, you can look at the S3 action table for a specific example to check the theory with.
Hands on Tutorial
If you haven’t already, I’d recommend you attempt the tutorial that combines IAM and S3.
- See if you can pick out the role of the action table in this.
- How do resources work?
- Can you lock the resource down any more?
Next, we’ll wrap up with some smaller topics – how Access Control Lists work for S3, and look at how to keep access restricted with temporary access and service-linked roles.