IAM Policy Elements

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed AWS cross-account access using IAM roles.

https://cloudaffaire.com/cross-account-access-using-iam-roles/

We are nearing our end in this IAM introductory series and in this blog post, we will discuss IAM policy elements.

IAM Policy Elements:

Version:

This Version JSON policy element is used within a policy and defines the version of the policy language. The Version policy element specifies the language syntax rules that are to be used to process a policy.

IAM supports the following Version element values:

• 2012-10-17. (the current version of the policy language)
• 2008-10-17. (the earlier version of the policy language)

If you do not include a Version element, the value defaults to 2008-10-17, but newer features, such as policy variables, will not work with your policy.

Note: This Version JSON policy element is different from a policy version.

ID:

The Id element specifies an optional identifier for the policy. The ID is used differently in different services. For services that let you set an ID element, we recommend you use a UUID (GUID) for the value, or incorporate a UUID as part of the ID to ensure uniqueness.

Note: Some AWS services (for example, Amazon SQS or Amazon SNS) might require this element and have uniqueness requirements for it.

Statement:

The Statement element is the main element for a policy. This element is required. It can include multiple policy elements. The Statement element contains an array of individual statements. Each individual statement is a JSON block enclosed in braces { }.

Sid:

The Sid (statement ID) is an optional identifier that you provide for the policy statement. You can assign a Sid value to each statement in a statement array. In services that let you specify an ID element, such as SQS and SNS, the Sid value is just a sub-ID of the policy document’s ID. In IAM, the Sid value must be unique within a JSON policy.

Note: In IAM, the Sid is not exposed in the IAM API. You can’t retrieve a particular statement based on this ID. Some AWS services (for example, Amazon SQS or Amazon SNS) might require this element and have uniqueness requirements for it.

Effect:

The Effect element is required and specifies whether the statement results in an allow or an explicit deny. Valid values for Effect are Allow and Deny.

By default, access to resources is denied. To allow access to a resource, you must set the Effect element to Allow.

Note: Policies are most restrictive and follow Deny –> Allow –> Deny flow

1. DENY at start
2. First check explicit deny in policy — > action: DENY and exit
3. Next check explicit allow in policy — > action: Allow and exit
4. Else — > action: Deny and exit

Principle:

The Principle element is used to specify the IAM user, federated user, IAM role, AWS account, AWS service, or other principal entity that is allowed or denied access to a resource. You can use it in the trust policies for IAM roles and in resource-based policies.

You specify a principal using the Amazon Resource Name (ARN) of the AWS account, IAM user, IAM role, federated user, or assumed-role user. You cannot specify IAM groups and instance profiles as principals. For the root user, you can also assign the account number.

For example, given an account ID of 123456789012, you can use either of the following methods to specify that account in the Principal element:

Note: You cannot use the Principal element in an IAM identity-based policy.

NotPrinciple:

The NotPrincipal element is used to specify the IAM user, federated user, IAM role, AWS account, AWS service, or other principal entity that is not allowed or denied access to a resource. The NotPrincipal element enables you to specify an exception to a list of principals. Use this element to deny access to all principals except the one named in the NotPrincipal element. The syntax for specifying NotPrincipal is the same as for specifying.

Note: Do not use NotPrincipal in the same policy statement as “Effect”: “Allow”. Doing so allows all principals except the one named in the NotPrincipal element.

Action:

The Action element describes the specific action or actions that will be allowed or denied. Statements must include either an Action or NotAction element. Each AWS service has its own set of actions that describe tasks that you can perform with that service. You specify a value using a namespace that identifies a service (iam, ec2 sqs, sns, s3, etc.) followed by the name of the action to allow or deny. The name must match an action that is supported by the service.

Amazon EC2 action example

Note: You can use a wildcard (*) to give access to all the actions the specific AWS product offers

NotAction:

NotAction is an advanced policy element that explicitly matches everything except the specified list of actions. Using NotAction can result in a shorter policy by listing only a few actions that should not match, rather than including a long list of actions that will match. When using NotAction, you should keep in mind that actions specified in this element are the only actions in that are limited. This, in turn, means that all of the applicable actions or services that are not listed are allowed if you use the Allow effect.

The following example allows users to access every action in every AWS service except for IAM.

Resource:

The Resource element specifies the object or objects that the statement covers. Statements must include either a Resource or a NotResource element. You specify a resource using an ARN.

The following example refers to the IAM user named Debjeet in an AWS account.

Note: Some services do not let you specify actions for individual resources; instead, any actions that you list in the Action or NotAction element apply to all resources in that service. In these cases, you use the wildcard * in the Resource element.

NotResource:

NotResource is an advanced policy element that explicitly matches everything except the specified list of resources. Using NotResource can result in a shorter policy by listing only a few resources that should not match, rather than including a long list of resources that will match. When using NotResource, you should keep in mind that the resources specified in this element are the only resources that are limited. This, in turn, means that all of the resources, including the resources in all other services, that are not listed are allowed if you use the Allow effect, or are denied if you use the Deny effect.

The following example refers to the IAM user named Debjeet in an AWS account. Except Debjeet all users will have Allow or Deny depending upon Action.

Note: Be careful using the NotResource element and “Effect”: “Allow” in the same statement or in a different statement within a policy. NotResource allows all services and resources that are not explicitly listed and could result in granting users more permissions than you intended.

Condition:

The Condition element (or Condition block) lets you specify conditions for when a policy is in effect. The Condition element is optional. In the Condition element, you build expressions in which you use condition operators (equal, less than, etc.) to match the condition in the policy against values in the request. You can refer all the conditions operation in below link

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html

For example, the following condition includes the StringEquals operator to ensure that only requests made by debjeet will match.

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html

Hope you have enjoyed this article. In the next blog post, we will start with a new AWS service.

To get more details on IAM, please refer below AWS documentation.

https://docs.aws.amazon.com/iam/index.html