Be secure by deafult! ๐Ÿ”’

Policy structure

๐Ÿ›ก๏ธ Principal: Attaching policy to?... Entity (users/resources)
๐Ÿ›ก๏ธ Action: Type of access allowed (Allow/Deny).
๐Ÿ›ก๏ธ Resources: Action will act on?...AWS Resources.
๐Ÿ›ก๏ธCondition: Under what condition/circumstances execute the defined actions on arn. Pro tip can make it most powerful as any of the Marvel characters.
๐Ÿ›ก๏ธ Sid: Each SID in policy is unique within a single policy.

{
    "Statement": [
    {
    "Effect": "effect",
    "Principal": "Entity",
    "Action": "Allow/Deny",
    "Resource": "arn",
    "Condition": {
        "condtion":{
        "key":"value"
        }
             }
        }
   ]
}

Policy evaluation Logic

Here is how it begins ๐Ÿ‘€
๐Ÿ›ก๏ธ Is the entity has deny permission by default?
ex: when we create an IAM user by default it has all deny permission.
Yes, it is:: Its a Deny!
Else goes next.

๐Ÿ›ก๏ธ On entity what all policies are applied, it considers all before it starts evaluating.

๐Ÿ›ก๏ธ It's quite possible to have a conflicting policy.
EX: Let's say there are two policies applied to an entity.
๐Ÿ”น One defines allow - delete, list and add s3 bucket and
๐Ÿ”น other says deny - delete s3 bucket.
๐Ÿ”น Here as we can see there is allow - to delete and deny to delete as well... It's a conflict. So while evaluating it gives the first precedence to Deny's list...hence checking explicitly Deny's list and concludes it as Deny
๐Ÿ”น Therefore, it doesn't not allow an entity to delete S3 bucket

๐Ÿ›ก๏ธ Once done with checking all deny's list, get started with allow list.
๐Ÿ”น Check if any explicit allow ... the policy will be applied.
If no allow actions, it goes back to deny.
Ex: On entity, there is one policy attached i.e. get object (for S3)
will that entity be able to delete an object? add object? put object?
No
๐Ÿ”น will that entity be able to download object? yes
Because, There is only explicitly one defined allow action...so by default rest, all actions are always denied.