Root Credentials has full unrestricted access to AWS account including the account security credentials which include sensitive information.

An Administrator account can be created for all the activities which too has full access to the AWS account except the accounts security credentials, billing information and ability to change password.

Identities: IAM identities determine who can access and help to provide authentication for people and processes in your AWS account. (User, Group, Roles)

IAM user represents the person or service who uses the access to interact with AWS.

User credentials can consist of the following

1. Password to access AWS services through AWS Management Console

2. Access Key/Secret Access Key to access AWS services through API, CLI or SDK

IAM user starts with no permissions.

Each IAM user is associated with one and only one AWS account.

IAM User cannot be renamed from AWS management console and has to be done from CLI or SDK tools.

IAM handles the renaming of user w.r.t unique id, groups, policies where the user was mentioned as a principal. However, you need to handle the renaming in the policies where the user was mentioned as a resource.

IAM group is a collection of IAM users

A group can have multiple users, while a user can belong to multiple groups (10 max).

Renaming of a group name or path, IAM handles the renaming w.r.t to policies attached to the group, unique ids, users within the group. However, IAM does not update the policies where the group is mentioned as a resource and must be handled manually .

IAM allows you to generate and download a credential report that lists all users in the account and the status of their various credentials, including passwords, access keys, and MFA devices. 

Credential report can be used to assist in auditing and compliance efforts.

Credential report can be used to audit the effects of credential lifecycle requirements, such as password and access key rotation.

Credential report is generated as often as once every four hours. If the existing report was generated less than four hours, the same is available for download. If more then four hours, IAM generates and downloads a new report. 

Shared access to your AWS account

• Grant other people permission to administer and use resources in your AWS account without having to share your password or access key.

Granular permissions

• Each user can be granted with different set granular permissions as required to perform their job

Secure access to AWS resources for applications that run on EC2

• IAM can help provide applications running on EC2 instance temporary credentials that they need in order to access other AWS resources.

Identity federation

• IAM allows users to access AWS resources, without requiring the user to have accounts with AWS, by providing temporary credentials for e.g. through corporate network or Google or Amazon authentication .

Identity information for assurance

• CloudTrail can be used to receive log records that include information about those who made requests for resources in the account.

PCI DSS Compliance

• IAM supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being Payment Card Industry Data Security Standard (PCI DSS) compliant.

Integrated with many AWS services

• IAM integrates with almost all the AWS services

Eventually Consistent

• IAM, like many other AWS services, is eventually consistent and achieves high availability by replicating data across multiple servers within Amazon’s data centers around the world.

• Changes made to IAM would be eventually consistent and hence would take some time to reflect.

Free to use

• IAM is offered at no additional charge and charges are applied only for use of other AWS products by your IAM users.

AWS Security Token Service

• AWS Security Token Service (STS) helps create and provide trusted users with temporary security credentials that control access to AWS resources

• STS is a global service with a single endpoint https://sts.amazonaws.com

• IAM provide STS which is an included feature of the AWS account offered at no additional charge.

• AWS STS API calls can be made either to a global endpoint or to one of the regional endpoints. Regional endpoint can help reduce latency and improve the performance of the API calls 

• AWS charges only for the use of other AWS services accessed by the AWS STS temporary security credentials.

• Web identity federation – You can allow users to sign in using a well-known third-party identity provider. Examples are: log in with Amazon, Facebook, Google, or any OpenID Connect (OIDC) 2.0 compatible provider. 

• You can provide access to your AWS resources to users without having to define an AWS identity for them.

• Commands

  1. decode-authorization-message --encoded-message <value>: The message is encoded because the details of the authorization status can contain privileged information that the user who requested the operation should not see. To decode an authorization status message, a user must be granted permissions through an IAM policy to request the DecodeAuthorizationMessage (sts:DecodeAuthorizationMessage ) action. 

  2. AssumeRoleWithWebIdentity: Returns a set of temporary security credentials for users who have been authenticated in a mobile or web application with a web identity provider. 

     • Example providers include the OAuth 2.0 providers Login with Amazon and Facebook, or any OpenID Connect-compatible identity provider such as Google or Amazon Cognito federated identities. 

     • Calling AssumeRoleWithWebIdentity does not require the use of AWS security credentials. 

  3. GetSessionToken: returns a set of temporary credentials for an AWS account or IAM user, not a role like the app needs. 

• Example Code:

  1. BasicSessionCredentials sessionCredentials = new BasicSessionCredentials(

  2.    session_creds.getAccessKeyId(),

  3.    session_creds.getSecretAccessKey(),

  4.    session_creds.getSessionToken());

  5. 
     

  6. AmazonS3 s3 = AmazonS3ClientBuilder.standard()

  7.    .withCredentials(new AWSStaticCredentialsProvider(sessionCredentials)).build();

An IAM role is an IAM identity that you can create in your account that has specific permissions.  

IAM role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS.

IAM role is not intended to be uniquely associated with a particular user, group or service and is intended to be assumable by anyone who needs it. 

Role does not have any credentials.

To assume a role, an application calls the AWS STS AssumeRole API operation and passes the ARN of the role to use. 

1. The operation creates a new session with temporary credentials. 

2. This session has the same permissions as the identity-based policies for that role. 

3. You can optionally pass inline or managed session policies. 

Like policies, they let you define a set of permissions.

Unlike policies, they are not attached to an IAM user or group. They are their own object.

Roles are assumed by the user or service that needs those permissions.

They are designed to easily attach or detach temporary permissions as needed without having to edit user or group policies repeatedly.

You can assume a role through the AWS Management Console, the AWS CLI, the AssumeRole API call, or AWS Security Token Service (AWS STS).

Modification of a Role can be done anytime and the changes are reflected across all the entities associated with the Role immediately.

IAM Role plays a very important role in the following scenarios

Instance Profile

Role can be assumed by: IAM user within the same AWS account, IAM user from a different AWS account, AWS service such as EC2, EMR to interact with other services and An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect (OIDC), or a custom-built identity broker.

Role involves defining two policies : Trust policy (Trust policy defines – who can assume the role) and Permissions policy (Permissions policy defines – what they can access)

Role Federation is creating a trust relationship between an external Identity Provider (IdP) and AWS

Role Types:

2. 1. 1. AWS Service Roles

         1. Some AWS services need to interact with other AWS services for e.g. EC2 interacting with S3, SQS etc

         2. Deleting a role or instance profile that is associated with a running EC2 instance will break any applications running on the instance .

         3. Application can retrieve the temporary credentials either using the Instance metadata directly or through AWS SDK 

      2. Cross-Account access Roles

         1. AM users can be granted permission to switch roles within the same AWS account or to roles defined in other AWS accounts that you own.

         2. However, only One set of permissions are applicable at a time. 

         3. Users must actively switch to the role using the AWS Management Console.

         4. Multi-factor authentication (MFA) protection can be enabled for the role so that only users who sign in with an MFA device can assume the role

         5. When the user exits the role, the user’s permissions revert to the original permissions held before switching to the role 

         6. Address Confused Deputy Problem using External ID: External ID provides a way for the account owner to permit the role to be assumed only under specific circumstances and prevents an unauthorized customer from gaining access to your resources 

      3. IAM Role – Identity Providers and Federation

         1. Identity Provider can be used to grant external user identities permissions to AWS resources without having to be created within your AWS account.

         2. Well-know web identity provider such as login with Amazon, Google etc.

         3. IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0).  

         4. If we want to use the On-Premise company users then we can use  SAML 2.0 identity provider, and single sign on (SSO) endpoint to authenticate. 

         5. Types:

            1. Mobile or Web Identity Federation with Cognito

               1. Use Amazon Cognito as the identity broker for almost all web identity federation scenarios

            2. SAML 2.0-based Federation

               1. WS supports identity federation with SAML 2.0 with LDAP

            3. Custom Identity broker Federation

               1. If the Organization doesn’t support SAML compatible IdP, a Custom Identity Broker can be used to provide the access

Use CAses:

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

You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. 

A policy is an object in AWS that, when associated with an identity (users, groups of users, or roles) or AWS resources. 

Most restrictive Policy always wins 

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. 

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

1. 1. 1. 1. {

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

         3.     “Statement”: {

         4.        “Principal“: {“AWS”: [“arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root”]},

         5.        “Action“: “s3:ListBucket”,

         6.        “Effect“: “Allow”,

         7.        “Resource“: “arn:aws:s3:::example_bucket”,

         8.        “Condition“: {“StringLike”: {

         9.            “s3:prefix”: [ “home/${aws:username}/” ]

         10.               }

         11.           }

         12.     }

         13. }

Police components:

• Version – Specify the version of the policy language that you want to use. As a best practice, use the latest 2012-10-17 version.

• Statement – Use this main policy element as a container for the following elements. You can include more than one statement in a policy.

• Sid (Optional) – Include an optional statement ID to differentiate between your statements.

• Effect – Use Allow or Deny to indicate whether the policy allows or denies access.

• Principal (Required in only some circumstances) – If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.

• Action – Include a list of actions that the policy allows or denies.

• Resource (Required in only some circumstances) – If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, then the resource to which the action applies is the resource to which the policy is attached.

• Condition (Optional) – Specify the circumstances under which the policy grants permission.

AWS supports six types of policies: identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs, ACLs, and session policies. 

AIM Policy Types:

1. 1. 1. Identity-based, or IAM permissions (Important)

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

         2. Includes AWS-managed, customer-managed, and inline options for policies 

         3. User, group, or role itself acts as a Principal 

         4. IAM permissions can be applied to almost all the AWS services .

         5. They are managed or inline policies. 

         6. IAM Policy version has to be 2012-10-17 

      2. Resource-based permissions (Important)

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

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

         3. Resource-based policies are inline policies. 

         4. Supported only by some AWS services 

         5. Version 2012-10-17 or 2008-10-17 

      3. Permissions boundaries 

         1. Defines the maximum permissions that the identity-based policies can grant to an entity such as users or roles , but does not grant permissions. 

         2. Permissions boundaries act as a barrier to prevent an entity from performing an action on a service that it should not perform.   

      4. Organizations SCPs  

         1. We use  the Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). 

      5. Access control lists (ACLs)

         1. Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached.  

      6. Session policies

         1.  Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user.  

Managed Policies and Inline Policies

1. 1. 1. Managed policies

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

         2. Managed policy changes are implemented as versions (limited to 5) 

         3. Managed policies allow reusability

         4. Managed policies have their own ARN 

         5. Two types of managed policies: 

            1. AWS managed policies:Created and managed by AWS 

            2. Customer managed policies: You create and manage in your AWS account. 

      2. Inline policies

         1. Policies that you add directly to a single user, group, or role.

         2.  Inline policies maintain a strict one-to-one relationship between a policy and an identity. 

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

1. Policy simulator commands typically require calling API operations to do two things.

   1. Evaluate the policies and return the list of context keys that they reference. You need to know what context keys are referenced so that you can supply values for them in the next step. iam:GetContextKeysForCustomPolicy or iam:GetContextKeysForPrincipalPolicy  command.

   2. Simulate the policies, providing a list of actions, resources, and context keys that are used during the simulation. simulate-custom-policy or iam:SimulatePrincipalPolicy  command 

2. For resources such as  Amazon S3 buckets, Amazon SQS queues, Amazon SNS topics, or Amazon S3 Glacier vaults, resource-based policies can be tested using IAM policy simulator. 

   1. To test resource-based policies, resources must be included in the simulator & resource policy needs to be selected for that resource. 

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 .

IAM Policy Simulator just reports the result Allowed or Denied .

IAM Policy Variables

Roles can be created to act as a proxy to allow users or services to access resources

Roles supports trust policy which helps determine who can access the resources and permission policy which helps to determine what they can access.

User who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role. 

Permissions provided to the User through the Role can be further restricted per user by passing optional policy to the STS request. This policy cannot be used to elevate privileges beyond what the assumed role is allowed to access 

Resource based policy allows you to attach a policy directly to the resource that you want to share, instead of using a role as a proxy.

Resource-based policy specifies who, as a Principal in the form of a list of AWS account ID numbers, can access that resource and what they can access.

With Cross-account access with a resource-based policy, User still works in the trusted account and does not have to give up her user permissions in place of the role permissions.

User can work on the resources from both the accounts at the same time and this can be useful for scenarios for e.g. copying of objects from one bucket to the other .

Resource based policies need the trusted account to create users with permissions to be able to access the resources from the trusting account

Only permissions equivalent to, or less than, the permissions granted to your account by the resource owning account can be delegated.

Resource that you want to share are limited to resources which support resource-based policies.

1. Amazon S3 allows you to define Bucket policy to grant access to the bucket and the objects

2. Amazon Simple Notification Service (SNS)

3. Amazon Simple Queue Service (SQS)

4. Amazon Glacier Vaults

5. AWS OpsWorks stacks

6. AWS Lambda functions

A "friendly name" for the user, which is the name that you specified when you created the user, such as Richard or Anaya. These are the names you see in the AWS Management Console.

An Amazon Resource Name (ARN) for the user. You use the ARN when you need to uniquely identify the user across all of AWS. For example, as a Principal in an IAM policy for an Amazon S3 bucket. An ARN for an IAM user might look like the following: arn:aws:iam::account-ID-without-hyphens:user/Richard

A unique identifier for the user. This ID is returned only when you use the API, Tools for Windows PowerShell, or AWS CLI to create the user; you do not see this ID in the console.

Console password: A password that the user can type to sign in to interactive sessions such as the AWS Management Console.

Access keys: A combination of an access key ID and a secret access key. You might use access keys when using the API for code or at a command prompt when using the AWS CLI or the AWS PowerShell tools.

SSH keys for use with CodeCommit: An SSH public key in the OpenSSH format that can be used to authenticate with CodeCommit.

Server certificates: SSL/TLS certificates that you can use to authenticate with some AWS services. We recommend that you use AWS Certificate Manager (ACM) to provision, manage, and deploy your server certificates. Use IAM only when you must support HTTPS connections in a region that is not supported by ACM. 

WS Multi-Factor Authentication (MFA): is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication code from their AWS MFA device (the second factor—what they have). 

Role chaining: Role chaining occurs when you use a role to assume a second role through the AWS CLI or API.

Delegation: The granting of permissions to someone to allow access to resources that you control. The trusted and trusting accounts can be any of the following: The same account, separate accounts that are both under your organization's control, or Two accounts owned by different organizations.

Federation: The creation of a trust relationship between an external identity provider and AWS. 

Federated user: Instead of creating an IAM user, you can use existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider. 

Role chaining: Role chaining occurs when you use a role to assume a second role through the AWS CLI or API.

Delegation: The granting of permissions to someone to allow access to resources that you control. The trusted and trusting accounts can be any of the following: The same account, separate accounts that are both under your organization's control, or Two accounts owned by different organizations.

Federation: The creation of a trust relationship between an external identity provider and AWS. 

Federated user: Instead of creating an IAM user, you can use existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider. 

Root Account -Don’t use & Lock away access keys

Lock away access to the account root user. You can do that by removing its access keys, giving it a strong password, and enabling multi-factor authentication on the account.

 Do not use or share the Root account once the AWS account is created, instead create a separate user with admin privilege

Permissions associated with your AWS Root account cannot be restricted.

Do not generate the access keys, if not required

Enable AWS multifactor authentication (MFA) on your AWS account 

User – Create individual IAM users; for anyone who needs access to your AWS account and give each user unique credentials and grant different permissions 

Groups – Use groups to assign permissions to IAM users

Permission – Grant least privilege

Passwords – Enforce strong password policy for users.

MFA – Enable MFA for privileged users

Use roles for applications running on EC2 instances instead of creating IAM user, and hardcoding the credentials within that application. 

Sharing – Delegate using roles instead of sharing credentials

Rotation – Rotate credentials regularly; Access keys allows creation of 2 active keys at the same time for an user. 

Track – Remove unnecessary credentials; Use the Credential report that lists all IAM users in the account and status of their various credentials 

Conditions – Use policy conditions for extra security; Define conditions under which IAM policies allow access to a resource. 

Auditing – Monitor activity in the AWS account; Enable logging features provided through CloudTrail, S3, CloudFront in AWS to determine the actions users have taken in the account and the resources that were used. Log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.

IAM Generals