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
Password to access AWS services through AWS Management Console
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.
Are short term and are regularly rotated
Can be configured to last from few minutes to several hours
Do not have to be embedded or distributed
Are not stored or attached with the User, but are generated dynamically and provided to the user as and when requested
The AWS STS API operations create a new session with temporary security credentials that include an access key pair and a session token.
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
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.
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.
GetSessionToken: returns a set of temporary credentials for an AWS account or IAM user, not a role like the app needs.
Example Code:
BasicSessionCredentials sessionCredentials = new BasicSessionCredentials(
session_creds.getAccessKeyId(),
session_creds.getSecretAccessKey(),
session_creds.getSessionToken());
AmazonS3 s3 = AmazonS3ClientBuilder.standard()
.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.
The operation creates a new session with temporary credentials.
This session has the same permissions as the identity-based policies for that role.
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
Services like EC2 instance running an application that needs to access other AWS services.
Allowing users from different AWS accounts have access to AWS resources in different account, instead of having to create users.
Company uses a Corporate Authentication mechanism and don’t want the User to authenticate twice or create duplicate users in AWS
Applications allowing login through external authentication
Instance Profile
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
If a Role is created for EC2 instance or any other service that uses EC2 through AWS Management Console, AWS creates a Instance profile automatically with the same name as the Role. However, if the Role is created through CLI the instance profile needs to created as well
An instance profile can contain only one IAM role. However, a role can be included in multiple instance profiles.
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:
AWS Service Roles
Some AWS services need to interact with other AWS services for e.g. EC2 interacting with S3, SQS etc
Deleting a role or instance profile that is associated with a running EC2 instance will break any applications running on the instance .
Application can retrieve the temporary credentials either using the Instance metadata directly or through AWS SDK
Cross-Account access Roles
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.
However, only One set of permissions are applicable at a time.
Users must actively switch to the role using the AWS Management Console.
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
When the user exits the role, the user’s permissions revert to the original permissions held before switching to the role
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
IAM Role – Identity Providers and Federation
Identity Provider can be used to grant external user identities permissions to AWS resources without having to be created within your AWS account.
Well-know web identity provider such as login with Amazon, Google etc.
IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0).
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.
Types:
Mobile or Web Identity Federation with Cognito
Use Amazon Cognito as the identity broker for almost all web identity federation scenarios
SAML 2.0-based Federation
WS supports identity federation with SAML 2.0 with LDAP
Custom Identity broker Federation
If the Organization doesn’t support SAML compatible IdP, a Custom Identity Broker can be used to provide the access
Use CAses:
Providing AWS resources with access to other AWS services
Providing access to externally authenticated users
Providing access to third parties
Switching roles to access resources in: Your AWS account & Any other AWS account (with cross-account access)
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:
{
“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}/” ]
}
}
}
}
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:
Identity-based, or IAM permissions (Important)
Identity-based, or IAM permissions are attached to an IAM user, group, or role and specify what the user, group or role can do.
Includes AWS-managed, customer-managed, and inline options for policies
User, group, or role itself acts as a Principal
IAM permissions can be applied to almost all the AWS services .
They are managed or inline policies.
IAM Policy version has to be 2012-10-17
Resource-based permissions (Important)
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 policies.
Supported only by some AWS services
Version 2012-10-17 or 2008-10-17
Permissions boundaries
Defines the maximum permissions that the identity-based policies can grant to an entity such as users or roles , but does not grant permissions.
Permissions boundaries act as a barrier to prevent an entity from performing an action on a service that it should not perform.
Organizations SCPs
We use the Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU).
Access control lists (ACLs)
Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached.
Session policies
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
Managed policies
Managed policies are Standalone policies that can be attached to multiple users, groups, and roles in an AWS account.
Managed policy changes are implemented as versions (limited to 5)
Managed policies allow reusability
Managed policies have their own ARN
Two types of managed policies:
AWS managed policies:Created and managed by AWS
Customer managed policies: You create and manage in your AWS account.
Inline policies
Policies that you add directly to a single user, group, or role.
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
Policy simulator commands typically require calling API operations to do two things.
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.
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
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.
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
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.
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.
Amazon S3 allows you to define Bucket policy to grant access to the bucket and the objects
Amazon Simple Notification Service (SNS)
Amazon Simple Queue Service (SQS)
Amazon Glacier Vaults
AWS OpsWorks stacks
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).
MFA protection can be enabled for service api’s calls using “Condition”: {“Bool”: {“aws:MultiFactorAuthPresent”: “true”}} and is available only if the service supports temporary security credentials.
Configured Using: Security token-based
AWS Root user or IAM user can be assigned a hardware/virtual MFA device (six digit numeric code )
Configured Using: SMS text message-based (Preview Mode)
IAM user can be configured with the phone number (six digit numeric code ).
SMS-based MFA is available only for IAM users and does not work for AWS root account.
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.