IAM: Identity and Access Management is one of the most important services in AWS, it holds all of the power in how different services in AWS interact with each other, the user, the developer, the DevOps teams and the administers. Additionally, it is also the source of almost all security issues related to the infrastructure built on AWS and responsible for some of the largest data breaches in cloud computing. With great power comes great responsibility.

IAM has quite a few “footguns”, something which is designed in a way where it’s remarkably easy to shoot yourself in the foot with. In other words, “a podiatric penetration purposed pistol”. ¹ Thankfully, there’s some simple rules and principles that you can follow to help prevent causing major damage to yourself, your clients and your customers.

Star Struck

IAM Policies have a feature where you can include a wildcard value *, which can usually cause more harm than good. One of the most common errors found in policies are ones which have "Principle" : "*" in them. AWS even helpfully includes this in the SNS console as an option, without any large flashing warning lights.

Choosing this “basic” option, with the helpful “everyone” option sets, "Principle" : "*" which means ANYONE, ANY AWS account, ANY user, in the world can publish messages, or if you check the next box, read messages as well!

Other common policies areas which can be Star Struck are Actions and Resources. There are a few circumstances where you may need to use a wildcard value but, you should always try to adhere to the principle of least privilege, and be more explicit on exactly which permissions you need. Avoid using wildcard values for Actions and Resources can significantly reduce the blast radius of credential misuse or loss.

Unconstrained IAM

When creating any policy there’s always a dance between security and usability. You do want to be able to empower your users to self-service as much as possible but, you should take extra care whenever you add any credential from the IAM service. Even common types of common user actions, like creating a security key can come with serious security issues. For example, let’s say we have a user who needs to write to a S3 bucket but, you also want them to be able to rotate their own IAM keys.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ManageBucket",
            "Effect": "Allow",
            "Action": [
                        "s3:ListBucket",
                        "s3:PutObject"
                    ],
            "Resource": [
                        "arn:aws:s3:::cf-app-image-upload",
                        "arn:aws:s3:::cf-app-image-upload/*"
                    ]
        },
        {
            "Sid": "ResetKeys",
            "Effect": "Allow",
            "Action": [
                        "iam:CreateAccessKey",
                        "iam:DeleteAccessKey"
                    ],
            "Resource": "*"
        }
    ]
}

In this example policy, our first statement, ManageBucket is fairly straightforward and the second statement, ResetKeys looks like it does what we intended but, the Action iam:CreateAccessKey can work on * (any, all) resources on our AWS accounts. Without any conditions to limit this becomes a huge security issue.

This user can now run the command aws iam create-access-key --user-name root and AWS will delightfully present them with IAM Access Keys for the root account.

There’s a wide range of IAM Actions which, when granted without any Condition constraints can be extremely dangerous. These all fall into the category of being vulnerable to privilege escalation style exploitation.

For these policies you should always be looking at constraining these actions with some sort of Condition statement.

For example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListUsersForConsole",
            "Effect": "Allow",
            "Action": "iam:ListUsers",
            "Resource": "arn:aws:iam::*:*"
        },
        {
            "Sid": "ViewAndUpdateAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:UpdateAccessKey",
                "iam:CreateAccessKey",
                "iam:ListAccessKeys"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}

Protect Yourself

There’s a variety of strategies you can employ to help you defend yourself against these types of mistakes.

The AUTOGAPS Process

Available Tools

AWS provides a lot of tools for you, which can help identify issues related to IAM security issues. These do not catch everything but, they are a quick and easy way to make sure you have the basics covered. Where applicable, you should be implementing these into your development process for infrastructure

• AWS Trusted Advisor

  AWS Trusted Advisor is an automated scanning tool using AWS Best Practices to scan your current AWS environment in real time. Business and Enterprise support customers get full access to the Trusted Advisor tools but, even users with no paid support get IAM scanning, S3 bucket scanning, MFA root verification, public EBS & RDS snapshot scanning completely for free.

• S3 Block Public

  Before 2018, when S3 introduced the Block Public feature to S3, public access was only controlled via IAM Bucket Policies, IAM & S3 ACLs . Block Public provides an additional layer of protection against accidentally making a private bucket accessible to the world. You should always enable this feature, with few exceptions. If you need to make a file accessible to the public, you probably should be placing a Cloudfront Distribution in front of it. Or if you only need certain files accessible, use signed URLs. Only disable block public if you absolutely need to.

• Policy Simulator

  AWS provides a built in tool with the Policy Simulator to help you explore the policies you have in your account, as well as experiment with custom policies directly in the simulator. Not only is it a good tool you help you debug policy errors but, also allows you to test out different conditions and situations where your policy can be misused.

• Visual Editor Errors

  You shouldn’t normally be using the Visual Editor to create policies but, by referencing the Visual Editor it will call out some issues with your policies that could cause security issues. If you see a ⚠️ warning sign, it’s worth investigating that issue.

Using Deny as a Backstop

Explicit denies in IAM always override implicit or even explicit allows. If you are certain that a resource should not be accessed by a user, you can add a policy or statement which explicitly denies access. This provides you a good backstop against other policies which may allow access by accident.

Test, test, test

If you know TDD, and you know how to use the policy simulator you can apply some TDD practices to policy generation as well. You know the action that you want to grant and if you set that up in the policy simulator, you will get your red test failure. Then you can iterate on a custom policy until you go green. You can additionally then refactor that policy to restrict the scope, refactor to add conditions, etc.

Out Loud

There’s a lot of research about reading out loud and the cognitive improvements to memory and understanding which occur. Reading each line, and commenting on it’s purpose and then the statements effect is a very helpful technique to unsure you fully understand what is going on. This becomes especially helpful when dealing with scenarios involving role assumption and alternate principals who aren’t IAM users. The actors in the situation become confusing, and talking through a policy and it’s actions can aide in understanding what the impacts of policies and changes would be.

Grammar is important

Good knowledge and understanding of the IAM Grammar and policy options is crucial in creating good security. It allows you to understand the options and tools available to you, so you don’t have to resort to using wildcards, just to make it work. Can I also recommend a new book that is coming out?

Avoid Complexity

It’s very easy to create unwieldy and complex IAM documents. There are some complicated scenarios you’ll probably find when creating some of the new styles of workloads, like serverless or even some CI/CD setups. Just remember, policies can be chunked, in either separate statements or separate policies. Use these tools to create smaller building block policies, that when combined give your principals the permissions they need.

Peer Review

Just as talking out loud to yourself can help, reviewing policies and changes with a second person is even better. You can adopt peer review practices in many steps along the process: at creation, major changes, or periodic reviews. A great place to implement them is if you have already adopted IaC (like Terraform) and a git workflow like git flow with peer reviews on pull request merges. This allows you to see the proposed changes in code, and allows for multiple eyes to verify what the changes will be.

Strike stars

As mentioned previously, wildcards * in IAM policies have disastrous consequences. As a matter of policy and practice, it can be helpful to your organization if you ban them, except for by exceptions. There’s very few reasons why wildcards should be in IAM policies and being explicit never hurts.

Wrapping up

Hopefully you’ve got a better idea of the pitfalls and traps which can lie in seemingly innocent IAM policies as well as a good toolkit (AUTOGAPS) to help you and your team work better. IAM is an important and powerful tool inside of AWS, knowing it is critically important for the security of your applications.

If you want to learn more about IAM, we have a Fundamentals book on AWS: IAM coming out soon! You can sign up for updates just below!

Published by 28 Jul, 2020 in iambook and tagged aws, iam and security using 1599 words.