What is an IAM Policy?

Follow

An IAM policy is a way to allow or deny users to perform certain actions in an AWS account. When a user or a role is created, by default, the user has permissions only to login, but cannot view, modify, or create any new resources. It's a best practice to only provide users with enough access to perform their job - it's the principle of least privilege (PoLP). For instance, if a user only needs the ability to modify objects in an S3 bucket, don't allow that user to create or delete S3 buckets. IAM policies can be defined at very granular levels so it's important that you understand how to use them safely.

Multiple IAM policies can be applied to the same user or role in AWS. It's suggested to break apart your IAM for easier management across your users. For instance, if all of your users need access to create, start, stop, and delete EC2 instances in an account, you can create one policy and apply it to all of those users. Then, you can create an additional policy for any users that need more access as well like read or write access to S3.

Additionally, different types of policies in AWS often overlap. Your AWS IAM policies, AWS SCPs, and permissions boundaries all control an entity's (i.e. a user, user group, or role) effective permissions, or what they can actually do in the cloud. To learn more about this, see the What is a Permissions Boundary? article.

cloudtamer.io helps you apply these IAM policies across your organization so when you do need to apply an IAM policy to users across more than one AWS account, you don't need to apply each one manually. cloudtamer.io acts as a central repository for all of your IAM policies. You create the policy once, apply it to all the desired cloud access roles, and then when you need to make a change, you just update the single policy and cloudtamer.io will modify that policy in all of your accounts via cloud access roles.

There are a few different methods you can use when deploying IAM policies across your accounts. You'll need to decide which method will work best for your organization as you grow.

Sample IAM Policies

Here is what a full admin policy looks like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

You should try not to use the above IAM policy because it doesn't limit what a user is able to do in AWS. Also, notice the IAM policy does not have a Sid field. The Sid fields allow you to describe the purpose of the policy to other users. You can read more about the field here: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_sid.html.

Here is a good example of an IAM policy that limits a user to specific tasks:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ReadOnly",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowEC2ReadOnly",
            "Effect": "Allow",
            "Action": "ec2:Describe*",
            "Resource": "*"
        }
    ]
}

This policy is much safer in that it only provides the user with read access to S3 service and the EC2 service. You can also get more granular by specifying a Resource or Condition tag. Check out this blog article for more information on limiting permissions to specific S3 buckets: https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/

Blacklist at a High Level

Customers in highly regulated environments like to take an approach where they create an IAM policy that blacklists all services except for an approved list. This is also beneficial for those that are delegating access to create policies on child projects. Even if a policy with full administrator access to attached to the same role or user as this policy, this policy will only allow the EC2, RDS, and S3 services to be used.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BlacklistAllButThreeServices",
            "Effect": "Deny",
            "NotAction": [
                "ec2:*",
                "rds:*",
                "s3:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

An important note in the above policy is you're still not granting any access to if this is the only IAM policy attached to the user or role. You still need to attach another policy with the effect of Allow to give permissions.

In cloudtamer.io, a user is provided access to the AWS console through cloud access roles. You can think of these roles as console access roles. cloudtamer.io can federate users into the AWS console without creating individual user accounts for each one. IAM policies can be attached by:

 

Was this article helpful?
0 out of 0 found this helpful