IAM - Identity Access Management

IAM - Allows you to manage users, groups and roles and their access to the aws ecosystem

Users: for end users

Groups:

Roles: we create for aws services , i.e if we want an ec2 to be able to access an s3 we create a role

· Cross account Roles - grant access to aws resources to third parties

· We can create a role that includes permissions for several roles

Polices: all the above get their permissions from Polices which is in json

Trust Relationship

LinkedServiceRole

Assumerrole

· See STS

·

PassRole

STS

Aws key ID & secret keys are granted once at user creation and these are for programatic access only

region Global

IAM Access Management

· IAM Access Management is all about Permissions and Policies

· Permission allows you to define who has access and what actions can they perform

· IAM Policy helps to fine tune the permissions granted to the policy owner

· IAM Policy is a document that formally states one or more permissions.

· Most restrictive Policy always wins

· IAM Policy is defined in the JSON (JavaScript Object Notation) format

· IAM policy basically states “Principal A is allowed or denied (effect) to perform Action B on Resource C given Conditions D are satisfied”

{
    “Version”: “2012-10-17”,
    “Statement”: {
       “Principal“: {“AWS”: [“arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root”]},
       “Action“: “s3:ListBucket”,
       “Effect“: “Allow”,
       “Resource“: “arn:aws:s3:::example_bucket”,
       “Condition“: {“StringLike”: {
           “s3:prefix”: [ “home/${aws:username}/” ]
              }
          }
    }
}

· An Entity can be associated with Multiple Policies and a Policy can have multiple statements where each statement in a policy refers to a single permission. If your policy includes multiple statements, a logical OR is applied across the statements at evaluation time. Similarly, if multiple policies are applicable to a request, a logical OR is applied across the policies at evaluation time.

· Principal can either be specified within the Policy for resource Based policies while for user bases policies the principal is the user, group or role to which the policy is attached

Permissions Boundaries

· The permissions boundary for an IAM entity (user or role) sets the maximum permissions that the entity can have.

· You can use permissions boundaries to delegate permissions management tasks, such as user creation, to IAM users in your account.

Identity-Based vs Resource-Based Permissions

· Identity-based, or IAM permissions

§ Identity-based, or IAM permissions are attached to an IAM user, group, or role and specify what the user, group or role can do

§ User, group, or role itself acts as a Principal

§ IAM permissions can be applied to almost all the AWS services

§ IAM Policies can either be inline or managed

§ IAM Policy version has to be 2012-10-17

· Resource-based permissions

§ Resource-based permissions are attached to a resource for e.g. S3, SNS 

§ Resource-based permissions specifies both who has access to the resource (Principal) and what actions they can perform on it (Actions)

§ Resource-based policies are inline only, not managed.

§ Resource-based permissions are supported only by some AWS services

§ Resource-based policies are always attached inline policy and are not managed

§ Resource-based policies can be defined with version 2012-10-17 or 2008-10-17

Managed Policies and Inline Policies

· Managed policies

§ Managed policies are Standalone policies that can be attached to multiple users, groups, and roles in an AWS account.

§ Managed policies apply only to identities (users, groups, and roles) but not to resources.

§ Managed policies allow reusability

§ Managed policy changes are implemented as versions (limited to 5), an new change to the existing policy creates a new version which is useful to compare the changes and revert back, if needed

§ Managed policies have their own ARN

§ Two types of managed policies:

o AWS managed policies

o Managed policies that are created and managed by AWS.

o AWS maintains and can upgrades these policies for e.g. if a new service is introduced, the changes automatically effects all the existing principals attached to the policy

o AWS takes care of not breaking the policies for e.g. adding an restriction of removal of permission

o Managed policies cannot be modified

o Customer managed policies

o Managed policies are standalone and custom policies created and administered by you.

o Customer managed policies allows more precise control over the policies than when using AWS managed policies.

· Inline policies

§ Inline policies are created and managed by you, and are embedded directly into a single user, group, or role.

§ Deletion of the Entity (User, Group or Role) or Resource deletes the In-Line policy as well

IAM Policy Simulator

· IAM Policy Simulator helps test and troubleshoot IAM and resource-based policies

· IAM Policy Simulator can help test the following ways :-

§ Test IAM based policies. If multiple policies attached, you can test all the policies, or select individual policies to test. You can test which actions are allowed or denied by the selected policies for specific resources.

§ Test Resource based policies. However, Resource based policies cannot be tested standalone and have to be attached with the Resource

§ Test new IAM policies that are not yet attached to a user, group, or role by typing or copying them into the simulator. These are used only in the simulation and are not saved.

§ Test the policies with selected services, actions, and resources

§ Simulate real-world scenarios by providing context keys, such as an IP address or date, that are included in Condition elements in the policies being tested.

§ Identify which specific statement in a policy results in allowing or denying access to a particular resource or action.

· IAM Policy Simulator does not make an actual AWS service request and hence does not make unwanted changes to the AWS live environment

· IAM Policy Simulator just reports the result Allowed or Denied

· IAM Policy Simulator allows to you modify the policy and test. These changes are not propogated to the actual policies attached to the entities

· Introductory Video for Policy Simulator

IAM Policy Evaluation

When determining if permission is allowed, the hierarchy is followed

1. Decision allows starts with Deny

2. IAM combines and evaluates all the policies

3. Explicit Deny

· First IAM checks for an explicit denial policy.

· Explicit Deny overrides everything and if something is explicitly deined it can never be allowed

4. Explicit Allow

· If one does not exist, it then checks for an explicit allow policy.

· For granting User any permission, the permission must be explicitly allowed

5. Implicit Deny

· If neither an explicit deny or explicit allow policy exist, it reverts to the default: implicit deny.

· All permissions are implicity denied by default

IAM Policy Variables

· Policy variables provide a feature to specify placeholders in a policy.

· When the policy is evaluated, the policy variables are replaced with values that come from the request itself

· Policy variables allow a single policy to be applied to a group of users to control access for e.g. all user having access to S3 bucket folder with their name only

· Policy variable is marked using a $ prefix followed by a pair of curly braces ({ }). Inside the ${ } characters, with the name of the value from the request that you want to use in the policy

· Policy variables work only with policies defined with Version 2012-10-17

· Policy variables can only be used in the Resource element and in string comparisons in the Condition element

· Policy variables are case sensitive and include variables like aws:username, aws:userid, aws:SourceIp, aws:CurrentTime etc.

Limits

one userr can be a member of 10 groups