IAM Policies

• Let’s imagine we have an IAM user group of developers with the users: Alice, Bob and Charles. Now we attach a policy at the group level
• In that case, the policy will get applied to every single member of the group i.e. Alice, Bob, and Charles will get all get access and inherit the group developer policy (see the image below)

• Now, let’s say if we have a 2nd group with operations with a different policy than the group of developers’ policy.
• Then David and Edward will have a different policy than the group of developers. (See Image Below)
  
• Now if Fred is a user and does not belong to a user group. Can we attach IAM policy only to specific users? Yes we can do that
• So for Fred, we have the possibility to create an inline policy meaning that the policy is only attached to a user only. (See image below)
• And finally Charles and David, both belong to Audit Team. You will attach IAM policy to the Audit Team as well. Charles & David will also inherit that policy from the audit team.
• So in this case now, Charles has a policy from developers and a policy from the audit team.
• David has a policy from audit team and a policy from the operations team.

Note: These examples will get to know better when we work on Hands On

IAM Policy Structure (V.V Imp)

In terms of the IAM policy structure (Note: we just need to know the high level overview of how it works and named)

• It is a JSON document (as discussed before)
• It consists of version number eg: 2012-10-17 (this is basically a policy language version)
• Then we have ID : which is how to identify that policy. This is optional

Then we come to Statements section of IAM:

• Statements can be one or multiple ones
• In this, Sid is a statement ID, which is an identifier for the statement. (This is optional). In the image example, ”Sid”: “1”,
• The effect of the policy itself: it means that it is whether or not the statement allows or denies access to certain API. In the image example, it says ”Allow”, you can use Deny as well

• The principle consists of which accounts/users/role to which the policy will be applied to. In the image example:
  
  In this, the principle is applied to the root accounts of your AWS accounts.

• Action is the list of API calls that will be either denied or allowed based on the effect.

  

• The Resource is a list of resources, to which the actions will be applied to. In the image example, it is a S3 Bucket, but for this there could be many possibilities as well.

  

• Finally, the condition: (this is optional)

It allows you to add extra rules to control access based on things like:

• IP address (e.g., allow access only from the office)
• Time of day or date
• Whether Multi-Factor Authentication (MFA) is used
• Tags on the resource

– Example: Allow access to an S3 bucket only from a specific IP range

– You don’t need to remember the syntax for the exam — just remember that `Condition` helps apply rules like IP restriction or MFA enforcement to make access more secure.