AWS Identity and Access Management (IAM)

Wed, Jul 5, 2017

AWS Identity and Access Management (IAM) gives you the facilities to manage users and their access level through AWS console. AWS IAM spacially targeted on an organization who have multiple users and need to assign different access to different users.

IAM is a powerful service that allows you to control how people and programs are allowed to manipulate your AWS infrastructure.
IAM is used to control
- Identity – who can use your AWS resources (authentication)
- Access – what resources they can use and in what ways (authorization)
IAM can also keep your account credentials private.
IAM is controlled like most other AWS Cloud services:
- Through the AWS Management Console
- With the CLI
- Via the AWS SDKs

IAM Principle

A principal is an IAM entity that is allowed to interact with AWS resources. A principal can be permanent or temporary, and it can represent a human or an application.
There are three types of principals:
- root users,
- IAM users,
- and roles/temporary security tokens.

IAM Root Account/User

Root Account is the email address and password with which you are sign-in into the AWS account. Root account have full unrestricted access to AWS account including the account security credentials which include sensitive information.

The root user is similar in concept to the UNIX root or Windows Administrator account Note: Do not use or share the Root account once the AWS account is created, instead create a separate user with admin privilege.

IAM User/Group

Users are persistent(no expiration period) identities set up through the IAM service to represent individual people or applications.
You may create separate IAM users for each member or create dev, test, and production users for applications that need to access
IAM users can be created by principals with IAM administrative privileges at any time through the AWS Management Console, CLI, or SDKs.

Roles/Temporary Security Tokens

Roles and temporary security tokens are very important for advanced IAM usage, but many AWS users find them confusing. Roles are used to grant specific privileges to specific actors for a set duration of time. These actors can be authenticated by AWS or some trusted external system.
When one of these actors assumes a role, AWS provides the actor with a temporary security token from the AWS Security Token Service (STS) that the actor can use to access AWS Cloud services.
Requesting a temporary security token requires specifying how long the token will exist before it expires. The range of a temporary security token lifetime is 15 minutes to 36 hours.
Roles and temporary security tokens enable a number of use cases:
- Amazon EC2 Roles: Granting permissions to applications running on an Amazon EC2 instance.
- Cross-Account Access: Granting permissions to users from other AWS accounts, whether you control those accounts or not.
- Federation: Granting permissions to users authenticated by a trusted external system.

Authentication

There are three ways that IAM authenticates a principal:
- User Name/Password: When a principal represents a human interacting with the console, the human will provide a user name/password pair to verify their identity. IAM allows you to create a password policy enforcing password complexity and expiration.
- Access Key: An access key is a combination of an access key ID (20 characters) and an access secret key (40 characters). When a program is manipulating the AWS infrastructure via the API, it will use these values to sign the underlying REST calls to the services. The AWS SDKs and tools handle all the intricacies of signing the REST calls, so using an access key will almost always be a matter of providing the values to the SDK or tool.
- Access Key/Session Token: When a process operates under an assumed role, the temporary security token provides an access key for authentication. In addition to the access key (remember that it consists of two parts), the token also includes a session token. Calls to AWS must include both the two-part access key and the session token to authenticate.

It is important to note that when an IAM user is created, it has neither an access key nor a password, and the IAM administrator can set up either or both. This adds an extra layer of security in that console users cannot use their credentials to run a program that accesses your AWS infrastructure.

IAM Features

Centralized control of your AWS account
Shared access to your AWS account
Integrated with existing active directory account and allows single sign on
Has fine grained access to the AWS resource
Access available on user/group/roles
MFA: Allows Multi-Factor authentication (MFA)
Temporary Access: Provides temporary access for users,and devices and services where necessary
Password: Allows us to set up password rotation policy
Eventually Consistent: IAM is a global service. It is not region specific
Granular permissions/Identity federation: IAM allows users to access AWS resources, without requiring the user to have accounts with AWS. You can grant different permissions to different people for different resources.
Free to use: AWS Identity and Access Management is a feature of your AWS account offered at no additional charge. You will be charged only for use of other AWS products by your IAM users.

Critical Terms

Users: End users / people.
Groups: A collection of users under one set of permissions.
Roles: Similar to a group, but you can assign both users and AWS resources(EC2). EC2 instances have credentials stored on them,however it is a security risk and difficult to manage. Roles solve this issue.
Policies: Document (JSON format) that defines one or more permissions – assign to user or groups

Policies Document

A policy is a (JSON) document that defines one or more permissions to a user, group, role, or resource. A policy consists of one or more statements, each of which describes one set of permissions. Here’s an example of a simple policy.

Policy documents contain one or more permissions, with each permission defining:

Effect: A single word: Allow or Deny.
Service: For what service does this permission apply? Most AWS Cloud services support granting access through IAM, including IAM itself.
Resource: The resource value specifies the specific AWS infrastructure for which this permission applies. This is specified as an Amazon Resource Name (ARN). The format for an ARN varies slightly between services, but the basic format is:
- "arn:aws:service:region:account-id:[resourcetype:]resource"
Action: The action value specifies the subset of actions within a service that the permission allows or denies. For instance, a permission may grant access to any readbased action for Amazon S3. A set of actions can be specified with an enumerated list or by using wildcards (Read*).
Condition: The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.

{
  "Version": "2012-10-17",
  "Statement": {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]},
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
}

Sid: Statement ID.
Effect: what the effect will be when the user requests access—either allow or deny.
Principal: Policy has to include information about who is allowed to access the resource.
Actions: what actions you will allow.
Resources: which resources you allow the action on.
Condition: When a policy statement contains a Condition element, the statement is only in effect when the Condition element evaluates to true.

Types of Policies

In IAM we have create three types of policy

Managed Policies: Standalone policies that you can attach to multiple users, groups, and roles in your AWS account. We don’t have a permission to make changes in managed policies.
Customer Managed Policies: You can create standalone policies that you administer in your own AWS account, which we refer to as a customer managed policies. You can then attach the policies to multiple principal entities in your AWS account. A great way to create a customer managed policy is to start by copying an existing AWS managed policy and after that do needfull changes.
Inline policies: Policies that you create and manage, and that are embedded directly into a single user, group, or role. Resource-based policies are another form of inline policy.

Password Policy for IAM Users

You can set a password policy on your AWS account to specify complexity requirements and mandatory rotation periods for your IAM users’ passwords.

Minimum password length: You can specify the minimum number of characters allowed in an IAM user password. You can enter any number from 6 to 128.
Require at least one uppercase letter: You can require that IAM user passwords contain at least one uppercase character from the ISO basic Latin alphabet (A to Z).
Require at least one lowercase letter: You can require that IAM user passwords contain at least one lowercase character from the ISO basic Latin alphabet (a to z).
Require at least one number: You can require that IAM user passwords contain at least one numeric character (0 to 9).
Require at least one nonalphanumeric character: You can require that IAM user passwords contain at least one of the following nonalphanumeric characters: ! @ # $ % ^ & * ( ) _ + - = [ ] { } | ‘
Allow users to change their own password: You can permit all IAM users in your account to use the IAM console to change their own passwords.
Enable password expiration: You can set IAM user passwords to be valid for only the specified number of days.
Prevent password reuse: You can prevent IAM users from reusing a specified number of previous passwords. You can set the number of previous passwords from 1 to 24, inclusive.

IAM FAQ

Latest FAQ’s find on this link.

IAM Summary

IAM is universal. It does not apply to regions at this time.
The “root account” is simply the account created when first setup your AWS account. It has complete Admin access.
New users have NO permissions when first created.
New users are assigned Access Key ID & Secret Access Keys when frist created.
You cannot user Access key ID & Secret Access Key to login into the console. You can use this to access AWS via APIs and command line however.
You only get to view these (Access Key ID & Secret Access Keys) once. If you lose them, you have to regenerate them. So save them in a secure location.
Always setup MFA (Multi-factor Authentication) on your root account.
You can create and customise your own password rotation polices.

Manage Multi-Factor Authentication (MFA)

AWS 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:

First factor: Need username and password
Second factor: Authentication code from their AWS MFA device

MFA Form Factors

Rotating Keys

The security risk of any credential increases with the age of the credential. To this end, it is a security best practice to rotate access keys associated with your IAM users. IAM facilitates this process by allowing two active access keys at a time. The process to rotate keys can be conducted via the console, CLI, or SDKs:

Create a new access key for the user.
Reconfigure all applications to use the new access key.
Disable the original access key (disabling instead of deleting at this stage is critical, as it allows rollback to the original key if there are issues with the rotation).
Verify the operation of all applications.
Delete the original access key.

Identity Federation

AWS Identity and Access Management (IAM) supports identity federation for delegated access to the AWS Management Console or AWS APIs. With identity federation, external identities (federated users) are granted secure access to resources in your AWS account without having to create IAM users. Identity federation allows to sign in using a well-known two types identity provider (IdP)

Corporate identity provider: such as Microsoft Active Directory or from the AWS Directory Service
Web identity provider: such as Amazon Cognito, Login with Amazon, Facebook, Google or any OpenID Connect (OIDC) compatible provider

Key Terms - Federation - Identity Provider(IDP) - Identity Broker - Identity Store - Identities

Federation Type

Web Identity Federation
Mobile or Web Identity Federation with Cognito
SAML 2.0-based Federation
Custom Identity broker Federation

Pending Topics

Microsoft Active Directory intregation with AWS
Identity federation
Directory management
SMAL intregation
Single sign off (SSO)
Microsoft ADFS

These all topics are not cleared yet, I have to explain all of them.