A policy is an object in AWS that, when associated with an identity or resource, defines their permissions.

Identity-based and resource-based policy

When you create a permissions policy to restrict access to a resource, you can choose an identity-based policy or a resource-based policy.

Identity-based policy

Identity-based policies are attached to an IAM user, group, or role.

Resource-based policy

Resource-based policies are attached to a resource.

The IAM service supports only one type of resource-based policy called a role trust policy, which is attached to an IAM role. [An IAM role is both an identity and a resource that supports resource-based policies].
For that reason, you must attach both a trust policy and an identity-based policy to an IAM role.

Managed Policies and Inline Policies

When you need to set the permissions for an identity in IAM, you must decide whether to use an AWS managed policy, a customer managed policy, or an inline policy.

AWS Managed Policies

An AWS managed policy is a standalone policy that is created and administered by AWS. Standalone policy means that the policy has its own Amazon Resource Name (ARN) that includes the policy name.

AWS managed policies are designed to provide permissions for many common use cases.

You cannot change the permissions defined in AWS managed policies. AWS occasionally updates the permissions defined in an AWS managed policy. When AWS does this, the update affects all principal entities (users, groups, and roles) that the policy is attached to.

Customer Managed Policies

You can create standalone policies that you administer in your own AWS account, which we refer to as customer managed policies. You can then attach the policies to multiple principal entities in your AWS account. When you attach a policy to a principal entity, you give the entity the permissions that are defined in the policy. Each policy also have its own ARN.

A great way to create a customer managed policy is to start by copying an existing AWS managed policy. That way you know that the policy is correct at the beginning and all you need to do is customize it to your environment.

Inline Policies

  • For Identity-based policy:

    • An inline policy is a policy that’s embedded in an IAM identity (a user, group, or role).
    • The policy is an inherent part of the identity. You can create a policy and embed it in a identity, either when you create the identity or later.

  • For Resource-based policy:

    • Resource-based policies are inline only, not managed.

What a policy looks like

A policy defines what actions are allowed or denied for specific AWS resources. This policy is granting permission to List and Describe information about EC2, Elastic Load Balancing, CloudWatch and Auto Scaling. This ability to view resources, but not modify them, is ideal for assigning to a Support role.

The basic structure of the statements in an IAM Policy is:

  • Effect says whether to Allow or Deny the permissions.
  • Action specifies the API calls that can be made against an AWS Service (eg cloudwatch:ListMetrics).
  • Resource defines the scope of entities covered by the policy rule (eg a specific Amazon S3 bucket or Amazon EC2 instance, or which means any resource*).

AmazonEC2ReadOnlyAccess:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
{
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "ec2:Describe*",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "elasticloadbalancing:Describe*",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": [
           "cloudwatch:ListMetrics",
           "cloudwatch:GetMetricStatistics",
           "cloudwatch:Describe*"
         ],
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "autoscaling:Describe*",
         "Resource": "*"
       }
     ]
   }