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.
AWS IAM Roles vs Policies
Let’s dive right in and start with the building blocks of AWS IAM (Amazon Web Services Identity and Access Management):
First, you’ve got IAM roles. AWS defines this as ‘an IAM entity that defines a set of permissions for making AWS service requests.’ These roles allow you to define access and permissions to these entities without the risk involved of using access keys. Now a question we get a lot is what are IAM roles vs policies.
Well, IAM policies refer to the defined permissions for an action regardless of the method that you use to perform the operation. Policies define the permissions of roles in AWS. We’ve got the foundation, so let’s continue.
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 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 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. A few points I want to call attention to:
- 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 AWS access policies, you need to specify which IAM principal can 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.
Part 2 on common mistakes here.
Now a little bit about Sonrai Security.
Identity and data access complexity are exploding in your public cloud. This is causing security holes you don’t even know exist. First-generation CSPM tools miss this as evidenced by so many breaches. Sonrai’s platform finds these holes, helps you plug them, and makes sure they won’t reappear. Let us know if you would like to see the platform for yourself.
Read the latest news and insights
12.17.2021
Clouds, while revolutionizing business, have exponentially...
11.20.2019
Explore the past and learn the future history of identity...
