# Policies and Permissions ### IAM Policy Permission policy is an authorization mechanism. Hence, until the policy is attached to an AWS Identity, that identity cannot do anything. AWS Identities are authorized to perform or forbidden to perform certain actions based on these policies. This is possible a single policy can include multiple permissions or statements. Also, multiple statements in policies are evaluated in OR logic IAM Policy is a JSON-formatted document in which permissions are listed. It consists of 4 different categories such as Effect, Action, Resource and Condition where Effect can be to allow or not to allow, action can be create or delete, resource can be AWS service and condition can answer whether to perform or not based on if it is true or not. These policies itself are like template. These needs to be attached to an AWS identity like user, group or IAM Roles for them to shape up to become permissions.

{% hint style="info" %} Note, for ease of creation of an IAM policy, one can always try using the following: {% endhint %} IAM policy is written in Access Policy Language (a fancy name indeed for a JSON Document)

Note that there is a Version: 2012-10-17 statement in the above policy. It states when AWS created this version of policy writing. there was 2008 also, which was older version. Also, statement ID (SID) is optional The Action follows Noun-Verb format (example: s3(noun):Get-Object(ACL) The Condition follows Key:Value pair (example:"Condition":{"StringsEquals":{"aws:username":"Senapati"}}) and value is case sensitive by default, otherwise condition can be set to ignore case for value of Senapati. Also Policy condition types can be global condition keys or service-specific condition keys, examples of which is as follows:

Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html

Please note that for these policies to take effect, these need to be attached to an IAM Identity like User, Group or Role, thereby becoming permissions for the attached identity. ### Policy Creation Steps to create a policy are as follows:

{% hint style="info" %} Personal Interpretation, the AWS IAM policies are evaluated on every action, especially for Console Access, meaning: Let's just a user ABC is logged onto the console and has the permission in a policy attached to him/her that allows to upload a file inside S3 bucket. Now, if the admin or any user with change permissions over IAM removes the policy that allows ABC to upload files, then he/she would be unable to do so, the next time they want to perform the file upload permission (PutObject) inside the s3 bucket. {% endhint %} Note that there is a ### Summaries in IAM The policy summary have hyperlinks to Service Summary and it has hyperlinks to action summary. These summaries are an absolute gold when it comes to analysing and understanding a particular IAM policy and can be navigated as shown below:

Source: https://docs.aws.amazon.com/images/IAM/latest/UserGuide/images/policy_summaries-pol-sum.png

### NotResource, NotAction NotResource is exact opposite of Resource in an IAM policy, With NottResource, one can setup policy like Everything except the one mentioned in NotResource

NotAction matches everything except the specified action. When effect is allow, it allows all actions except the ones mentioned in NotAction. When effect is deny, it denies all actions except the ones mentioned in NotAction.

### Types of Identity-based Policies * **Managed Policies** * [x] These managed policies are independent resources with their own unique ARNs * [x] They can be attached to multiple AWS Identities * [x] It can be further categorized as **AWS managed** (cannot be edited or updated by anyone including root except AWS and used for common use cases\[also referred as **Job Functions - which are like full job role that can be assigned to a person**]) or **Customer managed** (as the name suggests, they are managed by the customer of that particular AWS account) * [x] It has version control, i.e., it is possible to have multiple versions of a particular policy. Max number of policy versions are 5. * [x] The newest version of the policy is default, so if one wants to choose another policy version to be applied, simply change that version as default. * **Inline Policies** * [x] They are embedded in a single identity. * [x] They are inline hence cannot be attached to other identity. * [x] They are also managed by the customer themselves, hence customizable at any given time ### Policy Evaluation (I) {% hint style="info" %} **An AWS identity with multiple policies also follows OR logic when evaluating the final access** {% endhint %} IAM policy works with the following precedence: Explicit Deny -> Explicit Allow -> finally Implicit Deny. Example: A new user is created and no access was given during creation time, so access to all services in AWS are implicitly denied, post that, if the user is allowed to access certain things, then that would be the case of explicitly allowing or granting them permissions to do certain task, and then if the same user is explicitly denied to access anything then takes the highest priority for denying access to certain AWS services or resources as applicable. This is particularly useful when one has to temporary ban the usage of AWS account by assigning Explicit Deny on the account that prevents the usage of the account. The evaluation logic flowchart whenever any action would be attempted to be performed is as follows:

Source: https://docs.aws.amazon.com/images/sns/latest/dg/images/AccessPolicyLanguage_Evaluation_Flow.gif

The evaluation logic can be summarized as follows: * By default all requests are denied. * An explicit allow in any permissions policy/ies override the default. * An organization's SCP, IAM permissions boundary or a session policy overrides the allow. * In short, they must all allow the request for anything to be permitted * An Explicit deny in any policy overrides any allows The decision making algorithm flowchart for policy evaluation considering all relevant policies can be as follows:

Source: https://docs.aws.amazon.com/images/IAM/latest/UserGuide/images/PolicyEvaluationHorizontal111621.png

### Policy Simulator Policy simulator allows a way to test and simulate policy changes without applying them. Testing can be done based on policies attached to AWS IAM Identities or based on services, actions and resources. It can be useful to test overlapping policies to understand that if an action is allowed or denied and which statement works and which is preceded Head over to [https://policysim.aws.amazon.com/home/index.jsp#](https://policysim.aws.amazon.com/home/index.jsp)

### Permission Boundaries It indicates maximum permissions that an IAM identity can have and can only be attached to an IAM user or role. Note that there can be one permission boundary per IAM identity. This is useful to prevent accidental application of IAM policies to an AWS IAM identity in case there are multiple people in organization that has the privileges to change or add permissions to a Identity. It works in conjunction with Permission policy as shown below:

Source: https://securityboulevard.com/2023/10/aws-permission-boundary-what-is-it-and-how-to-use-it/

One can setup a boundary as shown below:

So effectively whoever assumes the role of s3kacommander, will only have the common access which would be that of s3bucketaccess policy simply because it has less permissions and they are the only actions rather than the overly permissive policy of tests3fullaccess and therefore senapati will only be able to access based on the condition set even when senapati assumes the role of s3kacommander ### Other Policy Types The entire discussion that happened above is for Identity-based policies. Other tyes of policies are as follows: * **Resource-based Policies**: Available for certain resources such as [S3 ](https://notes.radifine.com/aws/aws-storage-services/s3#resource-based-policy)or SQS * **Organization Service Control Policies:** * [x] To understand this, it is recommended that one reads about [AWS Organizations](https://notes.radifine.com/aws/aws-identity-and-access-management/aws-organizations) first and understand OU or Organization Unit * [x] Sometimes despite privileges, a user is unable to execute commands. This is despite the fact one can have privileges. The reason for that is SCP i.e., Service Control Policies which is always set in Management Account * [x] It sets the maximum permissions for an OU and limits permission for entities in member accounts, including each AWS root Account * **Access Control Lists**: Relevant to storage and buckets and ACLs in firewall (especially for public access). It defines which principals in another account can assume a role. * **Session Policies:** * [x] When one is assuming a role, session policy can be applied to limit what all role can do. It is similar to permission boundary, but there is a difference based on applicability. Session policy is applied only when one is assuming a role. So if the organization wants to limit what a user assuming a role can and can't do, then it can be defined in session policy.

When an IAM user assumes a role to access a s3, if s3 has a resource policy, and if it mentions Resource ARN, then internally the resource policy is converted to IAM policy to provide access accordingly. If it is session ARN, then it is not converted. * [x] As per above diagram Scenario 1: A resource-based policy can specify the ARN of the user or role as a principal. In that case, the permissions from the resource-based policy are added to the role or user's identity-based policy **before the session is created**. The session policy limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session's permissions are the intersection of the session policies and the resource-based policies plus the intersection of the session policies and identity-based policies. ```json // Identity-Based Policy for DataAccessRole: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] } // Resource-Based Policy on example-bucket: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/DataAccessRole" }, "Action": "s3:*", "Resource": "arn:aws:s3:::example-bucket/specific-object" } ] } // Session Policy: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::example-bucket/specific-object" } ] } // Effective Permissions The effective permissions will be limited to: Actions: s3:GetObject, s3:PutObject on arn:aws:s3:::example-bucket/specific-object ``` * [x] As per above diagram Scenario 2: A resource-based policy can specify the ARN of the session as a principal. In that case, the permissions from the resource-based policy are **added after the session is created**. The resource-based policy permissions are not limited by the session policy. The resulting session has all the permissions of the resource-based policy *plus* the intersection of the identity-based policy and the session policy.

// Identity-Based Policy (attached to DataAccessRole):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

// Resource-Based Policy on example-bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:sts::123456789012:assumed-role/DataAccessRole/*"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

// Session Policy (applied during the session):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

// Effective Permissions
The effective permissions will be limited to:
Actions: s3:GetObject, s3:PutObject, s3:ListBucket for all objects in arn:aws:s3:::example-bucket

* [x] As per above diagram Scenario 3: A permissions boundary can set the maximum permissions for a user or role that is used to create a session. In that case, the resulting session's permissions are the intersection of the session policy, the permissions boundary, and the identity-based policy. However, a permissions boundary does not limit permissions granted by a resource-based policy that specifies the ARN of the resulting session. ```json // Identity-Based Policy for DataAccessRole: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] } // Permissions Boundary: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::example-bucket/*" } ] } // Session Policy: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::example-bucket/specific-object" } ] } //Effective Permissions: The effective permissions will be limited to: Actions: s3:GetObject, s3:PutObject on arn:aws:s3:::example-bucket/specific-object ``` {% hint style="info" %} Note that **Resource groups** and **Tag editor** are another methods to provide access via IAM {% endhint %} ### Policy Evaluation (II) The evaluation logic can be summarized as follows: * By default all requests are denied. * An explicit allow in any permissions policy/ies override the default. * An organization's SCP, IAM permissions boundary or a session policy overrides the allow. * In short, they must all allow the request for anything to be permitted * An Explicit deny in any policy overrides any allows The decision making algorithm flowchart for policy evaluation considering all relevant policies can be as follows:

###