Understanding IAM Roles and Policies

Users

• Users refer to individual accounts.
• New users are not given to any AWS services, by default.
• MFA (Multifactor Authentication) should be configured for root account.
• IAM provide facility to create and customise password rotation policies in AWS.
• There are two ways to access AWS:
  • Username + Password
  • Access Key ID + Secret Access Key
• Username and Password
  • Cannot be used to interact with API
  • custom sign-in link created by IAM console for sign in

Access Key ID and Secret Access Key

• Assigned on user creation only
• Keys also enable interaction by
  • the AWS command line
  • SDKs
  • APIs.
• Keys are not Username or Password.
• User can only view them once.
• They need to be regenerated if lost
• Should be stored in a secured location

Groups

• Refer to a  collection of IAM users
• It helps to simplify assignment of permissions
• It is extensively used to denote individual departments in a company like Sales, HR, etc,
• Maximum of 10 groups can be assigned to a user
• Groups cannot have sub-groups as no nesting is permitted
• A group can only have users an no sub-groups
• There is no default group in AWS, for holding all users
• Any renaming of a group name or its path,  is reflected on policies attached to group, unique ids, users within the group.
• AWS IAM is not responsible to update policies if group is listed as a resource but it handled manually
• Group deletion involves detaching users and policies from the group and, deletion of inline policies.
• Varied access level for AWS service is needed as
  • A user can belong to multiple groups
  • Groups cannot belong to other groups

Roles

• Roles are used by any of the following
  • AWS IAM user present in same AWS account as role
  • AWS IAM user present in different AWS account than role
  • AWS offered web service like EC2
  • external user which has been validated using IdP (external identity provider) compliant to SAML 2.0/OpenID Connect
• AWS resources canalso be assigned to roles created by you
  • Like–EC2 instance having role to access S3, which is without any usernames, passwords, etc.
• Limit of 500 IAM roles
• API Actions for assuming roles:
  • AssumeRole
    • Can’t call AssumeRole from AWS root account credentials. use credentials for AWS IAM user or IAM role to call AssumeRole.
  • AssumeRoleWithSAML –users are validated by SAML authentication response, like an on-premises VPC
  • AssumeRoleWithWebIdentity  – users are validated by in mobile/web app using a web based identity provider like Facebook/Google

Role types:

• AWS Service
• Another AWS Account (allowing entity in other AWS accounts to act in current account)
• Web Identity (Amazon, Cognito, Facebook, Google)
• SAML / OpenID Connect

IAM Policies

• Resource property is a must in every IAM Policy
• Policies have 3 main parts – Action, Resource, and Effect
• Effect – refers to result i.e., access is allowed or denied by policy
• Action – Allowed action list, as per policy
• Resource –resource list on which actions can take place as per policy
• Condition (Optional) – Situation under which policy gives permission
• Roles as per their intrinsic capabilities, provide more security against programmatic access
• Multi-Factor Authentication or MFA should be enabled for all users for more secured access
• Policy Types
  • Identity-based policies – It can be attached to an IAM identity only like IAM user/ group/ role. To control what actions the assigned identity can perform, further classified as
    • Managed policies – It is an standalone identity-based policy which can be attached to multiple users/groups/roles in the AWS account. Further two types, as
      • AWS managed policies – creation and management by AWS
      • Customer managed policies –creation and management by user  by applying a visual editor or editing JSON policy document.
  • Inline policies – User created and embedded into a single user/group/role. Not recommended as management is precarious
  • Resource-based policies – Can only be attached to a resource like S3 bucket

Policy Example

{

  “Version”: “2012-10-17”,

  “Statement”: {

    “Effect”: “Allow”,

    “Action”: “s3:ListBucket”,

    “Resource”: “arn:aws:s3:::example_bucket”

  }

}

In above listing, ListBucket Request is allowed to perform on example_bucket S3 bucket

Flow models in federated identity management, are of types

• identity provider initiated model or IdP-initiated
• service provider initiated model  or SP-initiated

IdP-initiated

1. user access intranet using company’s authentication
2. user goes to web page and clicks link to Connections Cloud product like Connections Cloud S2.
3. SSO is started and SAML assertion is sent to connections Cloud endpoint via HTTP POST. If valid, access is granted.
4. The user interacts with Connections Cloud.

SP-initiated hybrid

1. The user visits Connections Cloud login page and clicks Use My Organization’s Login.
2. user provides email address linked with his or her account.
3. Connections Cloud redirects to organization’s authentication mechanism.
4. Rest flow as last step in IdP-initiated model.

AWS SAML

• SAML 2.0 or Security Assertion Markup Language 2.0 is supported by AWS
• SAML is an open standard that many identity providers (IdPs) use.
• Benefit of providing federated single sign-on (SSO)
• SAML  validated users can log into the AWS Management Console or call AWS API even if not an IAM user

Use cases supported by IAM federation

• Federated access allows user/application to call AWS API.
  • It uses SAML assertion to get temporary credentials.
• Web-based single sign-on (SSO) to AWS Management Console.

Using SAML-Based Federation for API Access to AWS

Example to give employees to copy data from their computers to a backup folder.

1. User request authentication by IdP using a client app
2. IdP authenticates the user
3. IdP generates a SAML assertion and sends  to client app
4. client app gives ARN of SAML provider, role to assume by calling AWS STS AssumeRoleWithSAML API
5. If valid, API responds with temporary credentials
6. Client app uses temporary credentials to call S3 API operations

SAML – Console – AssumeRoleWithSAML

• Corporate user can access Active Directory Federation Services  or ADFS
• AD FS authenticates user against Microsoft AD or Active Directory
• SAML Token contains membership generated
• Similar to IdP, Sigin in with SAML Token to AWS Sign-in Endpoint
• AssumeRoleWithSAML send to STS
• STS returns Credentials
• AWS Sign-in endpoint returns Console URL
• Corporate user Redirected to AWS Console
• Benefits include
  • Federation proxy not needed
  • No IAM permission for federation proxy, needed

Boost your chances to qualify AWS Certified Developer – Associate Exam with expert guidance and hundred of Practice Exam Now!