IAM policy mishaps: Intro to IAM

This post is based on the introduction of the talk IAM policy mishaps: A cautionary tale of cloud misconfigurations that we presented on Saturday, January 27th, at Sh3llCON (Reinosa). It is going to be the first in a series about IAM misconfigurations (yes, unfortunately, it's a topic that provides enough material for a series).

Poco a poco vamos llegando al final de las ponencias. Es el turno de Samuel y Andoni #IAM #sh3llcon2024 pic.twitter.com/azSbJVYCAp

— Sh3llCON (@Sh3llCON) January 27, 2024

But first of all, it's good manners to be grateful, so we have to thank the Sh3llCON organization for having us, and also s4ur0n and Quasar for acting as a "bridge" for it. It was a great weekend, and we'll try to repeat it.

Now, let's talk about the Cloud .

POLP

We all know the principle of least privilege, POLP (Principle Of Least Privilege) for its acronym in English:

It is the concept by which a user should only have access to what is strictly necessary to perform their responsibilities, and nothing more.

After some time in the cloud, it seems to me that it's easier said than done...

When we started studying, I remember that to deploy a WordPress, the architecture was something like this:

Source: Wikipedia

It's quite easy to identify all the components, right? The HTTP server, the DNS server, the different networks, the router...

Now, if we check the AWS reference architecture for WordPress:

Source: AWS Docs

I'm not saying it's inherently more complicated (or worse), but at the very least, we can say it has more components: Cloudfront, S3, ALB, EC2, ElastiCache, Aurora, EFS, Internet and NAT Gateways, VPC...

By the way, in that diagram, IAM is not included, which is exactly what we're going to talk about today. However, I guess adding more arrows wasn't possible.

IAM

IAM (Identity and Access Management) is an AWS service that allows you to manage who has access to resources in AWS. The typical: users, groups, access policies, etc.

IAM Policies

If you're not familiar with IAM policies, here's a bit of context. This is a simple example that provides ReadOnly access to the IAM console:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow", // (1)!
        "Action": [ // (2)!
            "iam:Get*",
            "iam:List*",
            "iam:Generate*"
        ],
        "Resource": "*" // (3)!
    }
}

1. Effect: Determine whether we are allowing or denying access.
2. Action: Actions on the AWS API that we allow or deny.
3. Resource: Resources to which these conditions apply.

If you've used the AWS console, you've probably noticed that different services have UIs that only resemble each other by the color scheme, right? Well, now imagine that with JSON files

Let's talk a bit more about the Actions... While preparing the talk, we decided to find out how many different Actions existed:

6 years ago, 3852 actions.

3 years ago, 8191 actions.

Sorry about that, but we can't show files that are this big right now.

January 2024, 16293 actions.

By the way, 50% are write access. (Source: aws.permissions.cloud)

But we haven't come just to complain; we also bring recommendations.

Like Monitor AWS Managed IAM Policies (MAMIP), to which you can subscribe directly or as part of the AWS Weekly Digest to receive updates on IAM changes.

To fully understand how IAM works, we need to introduce a few more concepts.

Resource Policies

The first of them is Resource Policies. These policies can be applied to certain resources, such as S3 or SNS, and allow us to grant permissions to these resources when they are not associated with an AWS identity. These are services to which, for example, you cannot associate an IAM role.

In case of identity control, effective permissions will be the sum of both.

AWS Organizations & SCPs

Next up is the AWS Organization (AWS Organizations).

AWS Organizations is a service where you can centralize the management of your accounts and the configuration of certain services like billing, security events, backup policies, etc.

But it also allows us to apply IAM policies, known as Service Control Policies (SCPs), our beloved SCPs...

The SCPs can be applied at the following levels:

• Organization Applies to all accounts except the management account.
• Organizational Unit (OU) Applies to all accounts beneath it.
• Account Applies only to a specific account.

These policies act with identity policies in the same way as resource policies. However, in this case, the resulting permissions are the intersection of the policies.

This is because SCPs do not grant permissions on their own, so there must always be an identity or resource policy.

Policy evaluation logic

And finally, in what order do we evaluate all of this? This is the diagram provided by AWS, and as indicated in their documentation, it is not complete.

Source: AWS Docs

To avoid over complication, we have made a more summarized version including only the conditions that we will see throughout this series:

With this, we have completed the quick IAM 101 course.

If you're wondering after all this, what is left to know about IAM? Well, at least: Boundaries, Service Roles, PassRole, AssumeRole, Federated Users... but we'll leave that for another day.

To conclude, we leave you with the link to the repository where we have uploaded the slides from the talk, and where we will be sharing the code for the practical cases.

In the next episode? Misconfigurations in S3.

Saludos, and may the force be with you.