• hey@aysharshad.com
  • Trondheim, Norway.
AWS
All you need to know about writing Least Privilege IAM Policies

All you need to know about writing Least Privilege IAM Policies

The system of AWS IAM Policies provides a granular structure of permission sets. The reason behind this system is Least Privilege Model.  The least privileged principle allows IAM identities to have the least required access level to complete their tasks. And this is an important unit of Well Architectured best practices.

In AWS all operations are Implicitly denied until Explicitly Allowed using these policies. However, if an operation is Explicit Denied then this rule has the highest precedence. 

Read about the Main principles of AWS Cloud Security and what role IAM plays in securing the AWS Resources.

Structure of IAM Policies

You can use the following structure to write both:

  1. Customer Managed IAM Policies
  2. In-line Policies

The only difference would be that your Customer Managed Policies can be attached to all IAM identities whereas the scope of In-line Policy remains restricted to one user. Inline POlicies come in handy when you need to customize a policy for a specific user.

JSON
{
    "Version" : "2012-10-17",
    "Statement" : 
    [
        {
            "Sid" : "Human Readable Description",
            "Effect" : "Allow/Deny",
            "Action" : 
                [
                    "Service:api/call"
                ],
            "Resource" :
                ["arn"],
            "Condition" : 
            {
                "Stringequals" : 
                    {
                        "part of string" : "value to match"
                    }
            }
        }
    ]
}
  1. Sid: Includes a Human Readable Description to the policy.
  2. Effect: Effect has two possible options that decide whether the policy is going to be either to Explicitly Allow or Explicitly Deny and operation.
  3. Action: Includes an API call to a Service.
  4. NotAction: Acts as an alternative to Action in case you want to just skip some actions but allow all others than that. 
  5. Resource: Refers to the entity on which Action will be performed. An ARN (Amazon Resource Number) that acts as a unique identifier for all AWS Resources, is used to provide reference to the resource.
  6. NotResource:  It acts as a reverse to Resource option if you want to provide access to all resources except one. 
  7. Condition: It is an optional value that helps identify conditions for access. Value in form of the string is included in this section. The string refers to any attribute of the API call.

Ways to create IAM Policies

You can use three main ways to create your desired IAM Policies:

  1. JSON Editor: You can write the policy manually using the aforementioned structure.
  2. Visual Editor: You can use the visual editor, which is found in IAM Console, to spin the policy.
  3. Import: You can import an existing policy from your account to customize it as per your requirements. You can import both AWS and Customer managed Policies
  4. AWS CLI: Use AWS CLI commands to generate IAM Policies.

Power of IAM Policies

By understanding the structure of IAM Policies one can understand that these policies are bulletproof. 

In AWS Cloud everything is Implicitly Denied until it is Explicitly Allowed.
Points to Remember

You can easily define:

  1. Who (Principal) has access to What (Resource).
  2. In case the number of operations you want to allow is bigger than the operation you want to keep implicitly denied. You have the option to use NotAction and NotResource.
  3. Deny trumps all. If there is something that with no exceptions needs to be denied you need to Explicitly Deny that using (“Effect”  :  “Deny”) policy.
  4. Permission Boundaries are also another way to deny what can’t be allowed even if explicitly allowed by a policy.
error: Content is protected. You are automatically reported to the Authorities!