This page is under regular updates. Please check back later for more content.

Policies

AWS Policy Types

There are mainly two categories of policies -

Permission Policy

These are the policies taht actually grant permission to perform to be working within AWS.

  • Identity-based policies
  • Resources-based policies
  • Session policies

Permission Boundary

It defines the maximum permission a perticular resource can have.

  • IAM permission boundaries
  • AWS Organization Service Control Policies (SCPs)

Policy overlap

  • Within AWS we can have Identity-based Policy or Resource-based policy applied to the same action.

Policy Format

  • An IAM policy is written in JSON format that follow JSON syntax. Example -
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:TerminateInstances"],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": ["ec2:TerminateInstances"],
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": ["192.0.1.0/24", "204.110.0.0/24"]
        }
      }
    }
  ]
}

version

  • Version is the API version for parsing policies.
  • It a static value so it's same for every policy.
  • The value used as version is 2012-10-17

Statement

A single Statement or array. An array can have multiple objects where multiple permission logic is defined. Within an individual Statement we have an Effect, Action, Condition, etc.

Effect

  • The effect determines whether the principal is allowed or denied access to the resource based on the specified actions.
  • Can be Allow (Explicit Allow) or Deny (Explicit Deny).

Actions

  • An action represents the specific operation that the principal is trying to perform on the resource. It can be a read, write, delete, or any other permitted operation.
  • Actions are requests issued to service API endpoints. It can be array of actions wihtin a single service or even multiple action across multiple service.

Resource

  • It can defined as AWS asset that the principal want to access and limit the scope of the action.
  • It may represent all the resources or an individual resource using ARN for a single resource.

In the above example we have two Statement one with Allow and Deny effect. In Deny effect it is one type of condition that can restrict request to speciifc resource if CIDR ranges.

It says if the sourcve IP didn't match do not allow the action.

Identity-based Policies

Wre have differnet types of Identity-based Policies -

Managed Policies

  • These are standalone resource or atmoic resource.
  • They are created and not associated with anything.
  • The Administrator choose these managed policy to associate with one or more resource such as IAM User, Group or Roles.
  • These can be versioned upto 5 revision. And we can choose which revision will act as a default version.

In addiiton there are two typs of managed policies -

  • Customer managed policies can be edited because it is created by customer
  • AWS managed policies cannot be edited. Example - DynamoDBFullAccess policy Both managed policy types can be associated with an IAM Group and then associate permission with user through group membership

Inline Policy

  • These are not standalone resources.
  • They are actually embedded as a configuration object within other resources, IAM users, IAM groups, or IAM roles.
  • They have no versioning available.
  • They can also only be associated with one object.

Inline policies are a parameter of the User or Group, not a separate resource.

Resource-based Policies

The Inline-based Policies and Resource-based Policies are almost same but we have a new policy element that don't exist in Identity-based Policies that is Principal.

  • Principal values vary by resource.
  • Many resource policies are optional and some are required.

    A principal refers to the entity that is attempting to access a resource. It can be a user, a group, or a role.

For example -

  • When we create a S3 bucket has a resource based policy which is empty by default because it's optional.
  • But when we utilize a KMS service, we need to configure it as a customer for users and administrator. Because this policy is required to function the service.

Session based Policy

  • It is a parameter passes during creation of temporary session
  • Use with IAM Role
  • Use with federated users