Policies and Permissions
Last updated
Last updated
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.
Note, for ease of creation of an IAM policy, one can always try using the following:
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:
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.
Steps to create a policy are as follows:
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.
Note that there is a
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:
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.
Managed Policies
Inline Policies
An AWS identity with multiple policies also follows OR logic when evaluating the final access
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:
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:
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#
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:
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
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 or SQS
Organization Service Control Policies:
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:
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.
Note that Resource groups and Tag editor are another methods to provide access via IAM
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:
