3 mins to read
Let me just start with this statement… EVERYTHING in AWS (Amazon Web Services) is related to an AWS Identity and Access Management (IAM) account.
That being said, we really need to understand the components that construct permissions and then talk about some common mistakes that we might make when diving into public cloud. I would also like to point out that there is a lot to cover with this topic, so this will be broken into a series of posts.
Let’s dive right in and start with the building blocks of AWS IAM (Amazon Web Services Identity and Access Management):
- At the organization level, you have AWS Service Control Policies (SCPs). These are “guardrails” within the AWS organization to disable service access on the principals in the account.
- AWS IAM is where you configure “permission policies” and “permission boundaries.” These are used to grant more granular permissions on IAM principals, including controlling the maximum they can set. A little more information on this that I find interesting is that:
- I is for Authentication and supports the human and application elements
- AM is for Authorization which gives you the ability to control access to cloud resources.
- AWS Security Token Service (STS) is available so you can “scope-down” policies. When using AWS STS, you can reduce the general shared permissions even further from an IAM policy for a limited time frame or to assume a role.
- Specific AWS services and resource-based policies are typically used for cross-account access and to control access from the resource.
- Virtual Private Cloud (VPC) endpoints and endpoint policies are where you control access to services with a VPC endpoint.
Whew … that’s a lot to take in, oohh wait, there is more!
Above, I mentioned “permissions boundaries.” So, what exactly are those? They are a way for you to scale and delegate permission management to devs or other groups and gives you (as an administrator) the ability to control the maximum permissions that others can grant.
Now that we have some of the fundamentals out of the way, let’s talk about how these all work together within a single account:
- You should have an SCP (remember guardrails) and you should have an IAM policy OR a resource-based policy.
- If you have an IAM Policy, you will need a permission boundary AND permission policy AND a scope-down policy. Again, this is per account so please keep that in mind.
- Cloud admins can create exceptions so you can still do what you need to.
I would also like to point out that the default access permission is …. DENY… if a policy does not explicitly give access (or ALLOW), the default will take precedence. And if there is an explicit DENY… well, you can guess what the effective permissions will be.
Now let’s put all of this together. When you define an AWS examples, access policies, you need to specify which IAM principals are allowed to perform which action on a specific AWS resource and under which conditions.
I would like to add a little more flavor to this, with an AWS IAM policy structure. Whether you’re in the console at the command line, you will need to understand the PARC model
{
“Statement”:[{
“Effect”:”allow or deny”,
“Principal”:”principal”, (This is the entity that is either allowed or denied access*)
“Action”:”action”, (The type of action that is allowed or denied)
“Resource”:”arn”, (The AWS arn for the resource)
“Condition”:”condition”, (And what conditions need to be met i.e. tags)
“Key”:”value”}
}
}
]
}
Please note: You normally don’t need to assign a principal when you are assigning a permission to a user, but it is needed when assigning policies to a resource.
If you just take that section and put it on a post-it note (good luck fitting it all in) at your desk, you will rock your AWS IAM policy definitions.
Now, keeping track of all of them and not making common mistakes, well that’s another story and will be discussed in a later post.
