Restricting access to AWS resources for certain users

A Brief Intro and Confusion Around Policies

Most of the confusion arises from interchangeably using Service and Resource. For example, S3 is a service, but a bucket is the actual resource.

Why is this important?

When you define policies, you get to pick a SERVICE to work with. And within that service, you get to pick a RESOURCE (or multiple resources).

For example, you will pick the S3 service and need the ARN to specify a resource.

Say users in Dept A. have their own resources, as do users in Dept. B.  They each want to restrict access to their own resources (the ideal solution would have been to use their own AWS accounts, but this post assumes both sets of users in the same AWS account)

Start by defining two groups of users in IAM – DeptA and DeptB.

Now, when we define the correct DENY policies, we simply attach those policies to the appropriate GROUP and we are done.

Policies – to DENY Access to AWS Resources (Note – Use AWS Policy Generator, where you can)

First of all, let us say DeptA wants to DENY access to certain S3 buckets (to users from Dept. B). The DENY policy may look something like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                        "s3:GetBucketLocation",
                        "s3:ListAllMyBuckets"
                      ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::YOUR-BUCKET",
                "arn:aws:s3:::YOUR-BUCKET/*"
            ]
        }
    ]
}

Another Example - Simple Policy to DENY access to a SPECIFIC S3 BUCKET

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt12232322444",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": "arn:aws:s3:::my-storage-bucket"
        }
    ]
}

What about the actual POLICIES? Can Dept. B see or delete the actual policies?

Now here’s the part most AWS Admins overlook. Why can’t admin users from Dept B – just go into IAM –> Policies  and –> DELETE this policy? That way, they can work around their DENY!

The answer is – yes – if they are admin users, they CAN do just that. So, the next thing we have to do is attach ANOTHER POLICY, one that DOESN’T ALLOW Dept. B to muck with existing policies.

Here is a sample DENY Policy (this DENIES a user from creating policies, editing policies, listing (viewing) policies…)

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": [
      "iam:CreatePolicy",
      "iam:CreatePolicyVersion",
      "iam:DeletePolicy",
      "iam:DeletePolicyVersion",
      "iam:GetPolicy",
      "iam:GetPolicyVersion",
      "iam:ListPolicies",
      "iam:ListPolicyVersions",
      "iam:SetDefaultPolicyVersion"
    ],
    "Resource": "*"
  }
}

Final Set of Policies

A custom IAM policy combined with another IAM policy (that disallows creating/editing/listing of existing policies), is the final solution to our original use case.

Summary

Try and use the AWS Policy Generator, when you can for generating the JSON for ALLOWING or DENYING access to resources. It simplifies things. Also, ensure that you have considered the actual policy access – i.e. – if the user can go in and tweak or delete the policy altogether (DENY CreatePolicy or DeletePolicy).