B2. AWS IAM Policies | Everything You Need To Know
This is the second blog of a AWS solutions architect blog series where I will be covering topics that are needed to become a AWS-SAA. (B2 = Blog 2)
[ PART 1 ]
Before I start : ⚪
Welcome back to my 2nd blog on AWS Solutions Architect Exam prep series where I share all the things that are required to become a AWS Solutions Architect ( AWS - SAA). This AWS series also covers things that that are not specific to the exam but you need to know as a AWS Solutions Architect. As I am also preparing for the exam, I am blogging all my learnings via this AWS - SAA exam series.
Let's Start 👇
Topics Covered In This Blog
Access Management & How Do Policies Define Permissions within IAM
How Policies Work, Including The Policy Evaluation Logic
Types of Policies Available
Definition/Explanation of Policy Types
How To Create a Policy Using The Console ( Part 2 )
Access Management & How Do Policies Define Permissions within IAM
So IAM securely controls access to your AWS resources and the below diagram represents how it works under the wood. And Below the photo the diagram is explained.
1 . When a principal(1) makes a request(2) in AWS, IAM first checks wheather the principal is authenticated ( signed in ) and then checks if authorized ( has permission to make any action ) or not.
a principal can be a user, a role , a federated user ( google, FB, netflix ) or an application
- The Authorization part(3) where the policies come into play.
2 . To manage access in AWS, we need to create policies and attach them to IAM identities or AWS resources.
In the above diagram we have Identity Based Policies and Resource Based Policies and then the Other Types of Policies in the middle. ( I will discuss other policies later in this blog ).
These Identity Based Policies and Resourse Based Policies are attached to Resources(5). Below is the Resources Diagram.
3 . Now lets unnderstand what Policies are actually.
- Policies are JSON documents in AWS. We can attach policies to an Identity or Resources to define the permission for that identity or resource.
Understanding How Policies Work.
To understand the flow behind policies we need to look at the 1st portion of the diagram again.
During authorization, IAM uses values from the request context to check for matching policies and then determines wheather to allow or deny the request.
IAM also checks each policy that applies to the context of the request
If any policy denies the request, IAM denies the whole request and stops evaluating policies any further. This types cases are also known as explicit deny since all the request are denied by default.
That means IAM authorizes a request only if every part of the request is allowed by the applicable policies. So if there are several policies, all policies must have to be allowed and then only IAM will only authorize the request any further.
Now I'll discuss further about Policy Evaluation Logic in depth. If you dont want to read this part, please skip to next section (Types of Policies).
- A) The evaluation logic for a request within a single account follows below rules.
i . The default rule is : It sets, all requests are implicitly denied except the root account who has the full access . ( But generally the best practice is to not to use root account always, instead creat an IAM user and add it to adminstrative role )
ii . An explicit allow in an identity-based or resource-based policy overrides the default deny. ( As I said above, I will come to these two policies later in this blog )
iii . If a permissions boundary, Organizations SCP or Service Control Policy, Or a session policy is present ( explained below ), It may override the allow with an implicit deny.
iv . An explicit deny in any policy overrides any allows
B) After a request has been authenticated and authorized, IAM approves the request
C) And for a request in a different account, a policy in the other account must allow access to the resource, plus the IAM entity used to make the request must have an identity-based policy that allows the request
Types of Policies
So there are six types of policies, but mainly two of them are prevalently used ⤵️
1️⃣ . Identity Based Policy
2️⃣ . Resource Based Policy
The other 4 types of policies are 👇
3️⃣ . Permissions Bounderies
4️⃣ . Organizations SCPs
5️⃣ . Access Control Lists ( ACLs )
6️⃣ . Session Policies
Explanation of Above Policy Types
1️⃣ Identity Based Policy
Within Identity Based Policy we can attach managed and inline policies to IAM indentitites such as users, groups or roles. And identity based policies grant permissions to an identity. Below diagram represent the structure of the prevalent policies.
With Identity Based Policies we have
i. managed policies
ii . inline policies
And in Managed Policies there are two other policies
i . AWS managed policies
ii. Customer managed policies
2️⃣ Resource Based Policy
In Resource based policies we can attach inline policies to resources. This type of policies grant permission to the principal that is specifies in the policy, where principals can be in the same account as the resource or in the other accounts.
3️⃣ Permissions Boundaries
This type of policies are not used often but required to know. But these other 4 types of policies that is mentioned here are used as a distractor answers in the exam . Most of the time question relates to the main two policies described above.
So permission boundaries uses a managed policy as the permissions boundary for IAM entity which defines the maximum permissions that the identity based policy can grant to an IAM entity, but does not grant permissions
4️⃣ Organizations SCPs
Organizations Service Control Policy is used to define the maximum permissions for account members of an organization or organizational unit ( OU ), SCPs limit permissions that identity based policies or resource based policies to grant to entitites within the account, but dont grant-permissions.
5️⃣ Access control list (ACL)
Amazon S3 access control lists (ACLs) enable you to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access. When a request is received against a resource, Amazon S3 checks the corresponding ACL to verify that the requester has the necessary access permissions. ACL cannot grant permissions to entities within same account.
{
"version":"03-07-2021",
"statement":[{
"sid":"statement1",
"effect":"allow",
"action":["s3:GetBucket", "s3:GetObject"],
"resources":["arn:aws:s3:::NewHireOrientation", "arn:aws:s3:::NewHireOrientation/*"
}]
}
6️⃣ Session Policies
We use this policies when we use CLI or API to aussume a role or a federated user to pass advanced session policies. Session Policy can limit permissions for a created session but can not grant a new permission to a new session. And so when the session is over the policy is dissappears.
Conclusion
In the part 2 of this blog I have shown how to create policy in detail. To keep this blog concise and not boring I am ending this blog here. Please refer to part 2 of this blog for explained demo of policy creation.
Keep Learning
If you liked the blog please drop me a feedback on my linkedin , It will help me make better blogs.
And if you wanna support me keep doing this you can buy me a book or coffe .