Identifying policy structure and syntax

All of the policies discussed in the previous section, other than ACLs, are written in JSON format and follow a specific policy structure. Understanding this structure will enable you to quickly and easily identify what permissions are being granted or denied within a policy and for who and what service. You must be able to confidently review and interpret these policies.

An example of policy structure

The following screenshot shows an example policy. Take a note of the various parameters: 

Let's understand these parameters one by one:

• Version: The 2012-10-17 version number shows the version of the policy language being used by AWS. The latest version at the time of writing this book is 2012-10-17.
• Statement: This acts as a group for the parameters that follow, and each policy can have a number of statements within them.
• Sid: This is simply a statement identification, the value of which can be anything to make logical sense of the statement itself. In this example, we have simply added a value of SamplePolicy, allowing us to easily identify what we are using the policy for.

• Effect: This can either be a value of Allow or Deny. This simply allows or denies access to the resources within the statement using the actions listed.
• Action: Here you can list a number of different actions that you want to either allow or deny access to, depending on the value of the previous parameter (Effect). In this example, we have listed two actions: s3:PutObject and s3:GetObject. The action is first defined by its service, such as S3, and is then followed by a colon (:), which precedes the action itself within the service.
• Resource: This provides the Amazon Resource Name (ARN) that tells us which resource these permissions apply to. In our example, we have an ARN: aws:s3:::awssecuritycert/*. * is a wildcard that stipulates any object within the awssecuritycert bucket.
• Condition: The Condition element is an optional parameter and allows you to dictate under what conditions or circumstances that the policy comes into effect. In my example policy, I have a single condition, which contains condition operators that specify the values of the condition. This condition is based on the IP address of the identity. For this condition to be met, the source IP address of the identity trying to access the aws:s3:::awssecuritycert/* resource, using either s3:PutObject or s3:GetObject, must be in the network range of 10.0.0.0/16.  

It’s also possible to have multiple conditions, which are known as condition blocks (more than one condition). In a condition block, the conditions are evaluated together using a logical AND statement, meaning all conditions in the block must be met before the permissions are put into effect.

The parameters discussed in this example are similar to what you would expect to see in a resource-based policy. In the next section, we will focus on the core difference between the two.

The structure of a resource-based policy

The policy structure for resource-based policies is essentially the same; however, there is one significant difference. As mentioned previously, when working with resource-based policies, the policy itself is attached to a resource and not an identity. As a result, another parameter is needed within the policy to identify who or what the policy should be associated with. This parameter is known as Principal:

Principal is used within resource-based-policies to identify the user, role, account, or federated user that the permissions should be applied to in order to either allow or deny access. The preceding screenshot shows the same policy as the previous one but applied to an S3 bucket policy. The Principal parameter shows the ARN of the identity that these permissions should be applied to.

Understanding the difference between identity-based and resource-based policies will help you resolve access control and permission issues. If you can easily read a policy and understand what it allows or denies, and if that policy is associated with an identity or a resource, that will be of great benefit. Next, we'll learn to configure cross-account access.