Identity-based policies

The policies within IAM are JavaScript Object Notation (JSON) based documents, which are used to define permissions that are then associated to different entities, authorizing them to perform specific actions and preventing them from doing other actions within your AWS account. These policies can be associated to users, groups, and roles, and are known as identity-based policies. Establishing a solid understanding of these policies is critical to maintaining secure access to your resources.

The JSON policy itself follows a very specific syntax, and is comprised of a number of parameters; for every policy, there will be a minimum of one statement. The syntax of a typical IAM identity-based policy would contain the following:

  • Version: This is stipulated by AWS as the version of the policy language. AWS recommends that, as a best practice, you always use the latest version; at the time of writing, it is version 2012-10-17.
  • Statement: Each statement is comprised of a number of Statement IDs (Sids), which define the permissions set out for the policy; think of this as a container for all of the Sids within that policy.
  • Sid (Statement ID): Each statement must have at least one Sid. You can name your Sids, to help you identify specific permissions within the policy. Each Sid is comprised of a number of attributes and parameters, which define the permissions set out for the statement of the policy. The following attributes are present within each Sid in a statement:
    • Effect: Here, you can select to either Allow or Deny access. This determines the effect of the permissions outlined within the rest of the statement. It's important to remember that any Deny effect will always overrule an Allow effect.
    • Action: This attribute dictates what actions are to be allowed or denied (depending on the Effect entry), and it relates to API calls. If more than one action is required, then multiple actions can be listed. For example, the following EC2 actions could be listed under one statement:
"Action": [
"ec2:AttachVolume",
"ec2:DeleteVolume"
]

Within this section, you can also include wildcards to cover a wide range of actions. If you wanted to include all of the actions for EC2 (effectively, all EC2 APIs), you could simply add the Action of the following:

"Action": [
"ec2:*"
]
    • Resource: This defines the resource that the Effect and Action apply to. All entries are supplied using the Amazon Resource Name (ARN).
For more information on the AWS ARN syntax and format, please refer to https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns.

Again, resources can be used with wildcards; an example is as follows:

"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*"
]
    • Condition: This is an optional attribute that, as the name implies, allows you to apply the permissions specified within the statement, based on a specific condition. Again, as an example (sticking with EC2), you could add the following condition:
"Condition": {
"IpAddress": {
"aws:SourceIp": "10.1.0.0/24"
}
}

This condition would ensure that the permissions within the statement would only be applied if the source IP address of the identity was within the network range of 10.1.0.0/24. If the request came from a source IP within this range, the permissions would be applied; if it didn’t, then the permissions would not be applied.

So, using the examples covered in the preceding section, the IAM policy would look as follows:

This policy can be attached to a user, group, or role, and the identities that are associated to this policy will be able to attach and delete volumes for any EC2 instances and volumes within your AWS account, on the condition that their source IP, when making the request, was in the 10.1.0.0/24 subnet range.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.217.107.229