Policy creation is at the very center of Identity and Access Management in AWS. We will use these policies to enable permissions for users, groups, and roles. We are going to cover AWS managed policies and custom policies in this post.

The anatomy of an IAM policy is pretty simple:

The IAM policy is a JSON formatted permission documents that will be used to grant or deny access to IAM users. We will see the following JSON tokens when working with IAM policies:

• { }
• [ ]
• “
• ,
• :

The policy document will be made up of elements that consist of an optional policy-wide informational statement (usually located at the top of the policy document) and one or more statements. Individual statement will include a single permission and AWS will apply a logical OR if there are multiple statements during the policy evaluation process. Information presented in a policy will include a series of elements:

• Version: Specifies JSON language syntax rules that will used during policy processing. AWS best practice is to use 2012-10-17 which is the latest version. If no version is specified the default value of 2008-10-17 will used which will result in newer features like policy variables not working with our policy.
• Statement: The main element of a policy that is used as a container for the for the remaining policy elements. This element will consist of one or more individual statements (“Statement”: [{…},{…},{…}]) that will contain the following elements:
  • SID: An optional statement ID (“Sid”: “1”) that can be used when there are multiple policy statements. An SID will not be exposed in the IAM API.
  • Effect: Either Allow or Deny (“Effect”:”Allow”). This element is required to allow access to a resource because by default access to resources will be denied.
  • Principal: This is only required when we create resource-based policies with are embedded directly into an IAM resource. It will indicate the account, user, role, or federated user that the policy will allow or deny access. The Principal element will not be used in an identity-based policy. Any of the following Principal elements can be specified:
    • AWS account
    • Root user
    • Federated users
    • IAM roles
    • Assumed-role sessions
    • AWS services
    • Anonymous services
  • Action: A list of actions that a policy will either allow or deny.
  • Resource:This will be required if we create an IAM permissions policy. It will specify the list of resources that we want our actions to be applied to.
  • Condition: This will specify the circumstances where our policy will grant permissions.

The example below contains three statements folded into a single Statement element:

We will dig deeper into each of these elements over the next series of posts and then begin to look at the logic used by AWS when evaluating policies.

Thank you for taking the time to visit cloudsecurityessentials.org. If these posts are beneficial to you then we ask that you consider sharing them with your friends and colleagues.