Shoin | Let's Share!

AWS Identity and Access Management - IAM Part 1

Abdullah Caliskan -

Terminology

Before to talk about the IAM service, first we should learn the terminology that gives us the ability to communicate in same context.

Resource: It's an creatable, deletable objects of services. such as the EC2 instance, S3 bucket.
Action: Doing something on a resource. Listing buckets, changing user password...
Authentication: Process of checking the credentials are or aren't correct.
Authorization: Process of checking the user has or hasn't permissions to do an action

Principal: Person or application
The principals can make an authenticated or anonymous request to perform action
Identity: User or Role
Objects that require authentication and authorization to access resources

We can re-describe the authentication and authorization after the learning principal and identity.
Authentication: Process of checking the credentials of a principal against an identity.
Authorization: Process of checking to allow or deny access to a resource for an identity.

IAM Entities

IAM has entities inside such as users, groups, roles, policies and identity providers.

Policy

Policies can be attached to an identity and resource. That means there are two kind of type policies which are identity policy and resource policy. In addition to that policies, IAM has permission boundaries and access control lists.

Identity policy is a json document. It consists a list of statements. IAM uses those statements to allow or deny the request.
Let's assume we have a user. then we attached the AmazonS3ReadOnlyAccess to the user. The attached policy allows the user to get objects and list buckets. But if the user tries to put a new object to a S3 bucket, it gets an error. Because the user (identity) doesn't have permission to put an object.

Identity policies can be in two form, managed and inline policies.

  • Inline Policy: You can add that kind of policies to a single user, group and role. There is a one-to-one relationship between policy and identity. That means when you delete the identity, the policy will be deleted.
  • Managed Policy: It's great for reusability. You can create the policy, then you can attach to multiple identities. If you delete the identity, the policy doesn't be deleted.
    There are two kind of managed policy;
    AWS Managed: Created by AWS
    Customer Managed: Created by you

AWS Managed policies are low overhead but lack flexibility. Customer Managed policies are flexible but requires administration. So the best usage is the combine them. Attach managed policies then, if you want to add exception use the inline policies. Use inline policies to give exceptions to an identity.

How AWS Evaluates the Policies?

If an identity doesn't have any attached policy, the identity can not do anything. Because there is the implicity deny by default. That means, if the action doesn't match with any attached policy, the request is implicitly denied.

I want to give a use case to explain that. Let's assume the developer wants to access to all of the S3 buckets with the objects. In addition to that the developer wants able to upload objects to the S3 buckets. But the developer can not delete the objects from S3 buckets. There are 2 ways to accomplish the use case.

  1. Firstly we can give full permission to user such as AmazonS3FullAccess Then we can add inline policy to deny delete actions.
  2. Or another solution is better than first one. We can give AmazonS3ReadOnlyAccess to user, then we can add inline policy to allow put actions.

Why the second option is better than first?

The principle of least privilege is the idea that at any user, program, or process should have only the bare minimum privileges necessary to perform its function.

So we should select the second way according to least privilege principle.

Firstly we should attach the AmazonS3ReadOnlyAccess policy to the user. The below lines show the content of the policy

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

Now we should attach an inline policy to allow an exception which is the put request. The below lines indicate the exception.

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

The user is able to put object and the other actions begin with PutObject Because the star (*) is a wildcard so PutObject, PutObjectAcl, PubObjectRetention actions are allowed. If you want to just upload the objects, remove the star.

If we come back to the main question that is how aws evaluates the policy? Firstly AWS gets the all policies including inline and managed. All policies are merged down into a single set of policies.
After it tries to match request action with that policies. But there is an order.

  • It tries to match Deny policies with the request, if matches then request is denied. It's known as Explicit Deny
  • If Deny policies doesn't match, it tries to match Allow policies with the request, if matches then request is allowed. It's known as Explicit Allow
  • If any policy doesn't match with the request, then the request is denied. It's known as Implicit Deny

Explicit Deny -> Explicit Allow -> Implicit Deny