Learning about IAM Roles and Policies

Users

• Are the individual accounts.
• By default, new users don’t have access to any AWS services.
• Always set up MFA (Multifactor Authentication) on your root account.
• IAM can be used to create and customise password rotation policies.
• There are two ways to access AWS:
  • Username + Password
  • Access Key ID + Secret Access Key
• Username and Password
  • Cannot be used to interact with the API
  • Can be used to sign in via a custom sign-in link which you can create via the IAM console

Access Key ID and Secret Access Key

• Assigned on user creation
• Can be used to interact via the AWS command line, SDKs, or APIs.
• Not the same as Username and Password.
• Can only be viewed once. If you lose them, they need to be regenerated. Save them in a secure location.

Groups

• A collection of IAM users
• simplifying the assigning of permissions
• Usually groups for different departments like Sales, HR, etc,
• A user can belong to multiple groups (10 max)
• Cannot be nested and can only have users within it
• No default group to hold all users
• Renaming of a group name or path,  w.r.t to policies attached to the group, unique ids, users within the group.
• IAM does not update policies where group is mentioned as a resource and must be handled manually
• Group deletion requires detaching users and managed policies and delete any inline policies.
• all require different levels of AWS access.
  • A user can belong to multiple groups
  • Groups cannot belong to other groups

Roles

• Roles can be used by,
  • an IAM user in the same AWS account as the role
  • an IAM user in a different AWS account than the role
  • a web service offered by AWS such as Amazon Elastic Compute Cloud (Amazon EC2)
  • an external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker.
• You can create roles, then assign them to AWS resources.
• Example – For an EC2 instance, give it a role saying it can access S3. So, access S3 without usernames, passwords, etc.
• Limited to 500 IAM roles under AWS account.
• API Actions for assuming roles:
  • AssumeRole
    • You cannot call AssumeRole by using AWS root account credentials; access is denied. You must use credentials for an IAM user or an IAM role to call AssumeRole.
  • AssumeRoleWithSAML – for when users have been authenticated via a SAML authentication response, i.e. an on-premises VPC
  • AssumeRoleWithWebIdentity (when users have been authenticated in a mobile app or web app with a web identity provider suh as Facebook, Google, or OpenID connect)

Role types:

AWS Service

Another AWS Account (allows entities in other accounts to perform actions in the current account)

Web Identity (Amazon, Cognito, Facebook, Google)

SAML / OpenID Connect

API Actions for assuming roles:

AssumeRole

You cannot call AssumeRole by using AWS root account credentials; access is denied. You must use credentials for an IAM user or an IAM role to call AssumeRole.

AssumeRoleWithSAML – for when users have been authenticated via a SAML authentication response, i.e. an on-premises VPC

AssumeRoleWithWebIdentity (when users have been authenticated in a mobile app or web app with a web identity provider suh as Facebook, Google, or OpenID connect)

IAM Policies

• Each IAM Policy must contain the Resource property
• Policies consist of 3 main components, Action, Resource, and Effect
• Effect – Whether the policy allows or denies access
• Action – The list of actions that are allowed or denied by the policy
• Resource – The list of resources on which the actions can occur
• Condition (Optional) – The circumstances under which the policy grants permission
• Roles are more secure than programmatic access, and should always be used as the first resort where possible
• All IAM users should have MFA (Multi-Factor Authentication) enabled
• Policy Types
  • Identity-based policies – Attach to an IAM identity – IAM user, group, or role. Control what actions the identity can perform
    • Managed policies – Standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. You can use two types of managed policies:
      • AWS managed policies – created and managed by AWS.
      • Customer managed policies – User create and manage in AWS account using visual editor or by creating the JSON policy document directly.
  • Inline policies – Policies that you create and manage and that are embedded directly into a single user, group, or role. Not recommended using them.
  • Resource-based policies – Attach to a resource – Amazon S3 bucket or an IAM role trust policy.

Policy Example

{

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

“Statement”: {

“Effect”: “Allow”,

“Action”: “s3:ListBucket”,

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

}

}

The above allow a ListBucket Request to be performed on the example_bucket S3 bucket for example.

Enrich your profile and get ready to qualify as AWS Solutions Architect Associate with hundreds of Free Practice Test Now!