AWS Identity and Access Management (IAM) enables you to securely control access to AWS services and resources for your users. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources. IAM is a feature of your AWS account offered at no additional charge. You will be charged only for use of other AWS services by your users.
What does IAM give you?
Few Critical Terms:
Key Characteristics of IAM
Mandatory Security considerations in IAM Setup
IAM User Management Aspects
IAM Policy Influences on AWS
IAM Policy Examples
Understanding Policies
Policy Statement Properties
IAM Policy Types
Example Policy Statements in JSON format
Below are few Screen shot of AWS – IAM console and its Dashboards
IAM Users
An IAM user is an entity that you create in AWS to represent the person or service that uses it to interact with AWS. A user in AWS consists of a name and credentials.
How AWS identifies an IAM user
When you create a user, IAM creates these ways to identify that user:
A "friendly name" for the user, which is the name that you specified when you created the user, such as Bob or Alice. 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, such as when you specify the user 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/Bob
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.
Users and credentials
You can access AWS in different ways depending on the user credentials:
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 can assign two to a user at a time. These can be used to make programmatic calls to AWS when using the API in program code or at a command prompt when using the AWS CLI or the AWS PowerShell tools.
-
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. To learn which regions support ACM, see the AWS Certificate Manager section of the AWS General Reference.
By default, a brand new IAM user has no password and no access key (neither an access key ID nor a secret access key)—no credentials of any kind. You must create the type of credentials for an IAM user based on what the user will be doing.
Users as service accounts
An IAM user doesn't necessarily have to represent an actual person. An IAM user is really just an identity with associated credentials and permissions. You might create an IAM user to represent an application that needs credentials in order to make requests to AWS. This is typically referred to as a "service account." An application might have its own service account in your AWS account, and its own set of permissions, the same way that processes have their own service accounts defined in an operating system like Windows or Linux.
IAM Groups
An IAM group is a collection of IAM users. You can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users. For example, you could have a group called Adminsand give that group the types of permissions that administrators typically need. Any user in that group automatically has the permissions that are assigned to the group. If a new user joins your organization and should have administrator privileges, you can assign the appropriate permissions by adding the user to that group. Similarly, if a person changes jobs in your organization, instead of editing that user's permissions, you can remove him or her from the old groups and add him or her to the appropriate new groups. Note that a group is not truly an identity because it cannot be identified as a Principal in an access policy. It is only a way to attach policies to multiple users at one time.
The following diagram shows a simple example of a small company. The company owner creates an Admins group for users to create and manage other users as the company grows. The Admins group creates a Developers group and a Test group. Each of these groups consists of users (humans and applications) that interact with AWS (Jim, Brad, DevApp1, and so on). Each user has an individual set of security credentials. In this example, each user belongs to a single group. However, users can belong to multiple groups.
Following are some important characteristics of groups:
A group can contain many users, and a user can belong to multiple groups.
Groups can't be nested; they can contain only users, not other groups.
There's no default group that automatically includes all users in the AWS account. If you want to have a group like that, you need to create it and assign each new user to it.
-
IAM Roles
“IAM Role is entity which can be assigned to any (Principle) resources or services or user on which you have complete trust”. These AWS principle can assume this role to perform specific operations based on assigned policy or permissions.
An IAM role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have any credentials (password or access keys) associated with it. Instead, if a user is assigned to a role, access keys are created dynamically and provided to the user.
You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources. For example, you might want to grant users in your AWS account access to resources they don't usually have, or grant users in one AWS account access to resources in another account. Or you might want to allow a mobile app to use AWS resources, but not want to embed AWS keys within the app (where they can be difficult to rotate and where users can potentially extract them). Sometimes you want to give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory. Or, you might want to grant access to your account to third parties so that they can perform an audit on your resources.
IAM roles are a secure way to grant permissions to entities that you trust. Examples of entities include the following:
IAM user in another account
Application code running on an EC2 instance that needs to perform actions on AWS resources
An AWS service that needs to act on resources in your account to provide its features
Users from a corporate directory who use identity federation with SAML
IAM roles issue keys that are valid for short durations, making them a more secure way to grant access.
Principle and Identity Objects
Principle is object which encapsulates both Authentication and Authorization details whereas Identity objects encapsulates only authentication details of login entity or user. Below picture explains relationship between Principle and Identity objects.
Here are some basic terms to help you get started with roles.
Role
A set of permissions that grant access to actions and resources in AWS. These permissions are attached to the role, not to an IAM user or group. Roles can be used by the following:
An IAM user in the same AWS account as the role
An IAM user in a different AWS account as 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.
-
A role that a service assumes to perform actions on your behalf. When you set up most AWS service environments, you must define a role for the service to assume. This service role must include all the permissions required for the service to access the AWS resources that it needs. Service roles vary from service to service, but many allow you to choose your permissions, as long as you meet the documented requirements for that service. You can create, modify, and delete a service role from within IAM.
AWS service role for an EC2 instance
A special type of service role that a service assumes to launch an Amazon EC2 instance that runs your application. This role is assigned to the EC2 instance when it is launched. AWS automatically provides temporary security credentials that are attached to the role and then makes them available for the EC2 instance to use on behalf of its applications. For details about using a service role for an EC2 instance, see Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.
-
A unique type of service role that is linked directly to an AWS service. Service-linked roles are predefined by the service and include all the permissions that the service requires to call other AWS services on your behalf. The linked service also defines how you create, modify, and delete a service-linked role. A service might automatically create or delete the role. It might allow you to create, modify, or delete the role as part of a wizard or process in the service. Or it might require that you use IAM to create or delete the role. Regardless of the method, service-linked roles make setting up a service easier because you don’t have to manually add the necessary permissions.
Note
If you are already using a service when it begins supporting service-linked roles, you might receive an email telling you about a new role in your account. In this case, the service automatically created the service-linked role in your account. You don't need to take any action to support this role, and you should not manually delete it. For more information, see A New Role Appeared in My IAM Account.
For information about which services support using service-linked roles, see AWS Services That Work with IAMand look for the services that have Yes in the Service-Linked Role column. Choose a Yes with a link to view the service-linked role documentation for that service. If the service does not include documentation for creating, modifying, or deleting the service-linked role, then you can use the IAM console, CLI, or API. For more information, see Using Service-Linked Roles.
-
The granting of permission to someone to allow access to resources that you control. Delegation involves setting up a trust between the account that owns the resource (the trusting account), and the account that contains the users that need to access the resource (the trusted account). The trusted and trusting accounts can be any of the following:
To delegate permission to access a resource, you create an IAM role that has two policies attached. The permissions policy grants the user of the role the needed permissions to carry out the intended tasks on the resource. The trust policy specifies which trusted accounts are allowed to grant its users permissions to assume the role.
When you create a trust policy, you cannot specify a wildcard (*) as a principal. The trust policy on the role in the trusting account is one-half of the permissions. The other half is a permissions policy attached to the user in the trusted account that allows that user to switch to, or assume the role. A user who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role. When the user exits, or stops using the role, the original user permissions are restored. An additional parameter called external ID helps ensure secure use of roles between accounts that are not controlled by the same organization.
Federation
The creation of a trust relationship between an external identity provider and AWS. Users can sign in to a web identity provider, such as Login with Amazon, Facebook, Google, or any IdP that is compatible with OpenID Connect (OIDC). Users can also sign in to an enterprise identity system that is compatible with Security Assertion Markup Language (SAML) 2.0, such as Microsoft Active Directory Federation Services. When you use OIDC and SAML 2.0 to configure a trust relationship between these external identity providers and AWS, the user is assigned to an IAM role and receives temporary credentials that enable the user to access your AWS resources.
-
A document in JSON format in which you define who is allowed to assume the role. This trusted entity is included in the policy as the principal element in the document. The document is written according to the rules of the IAM policy language.
-
A permissions document in JSON format in which you define what actions and resources the role can use. The document is written according to the rules of the IAM policy language.
Principal
An entity in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role. You can grant permissions to access a resource in one of two ways:
If you reference an AWS account as principal, it generally means any principal defined within that account.
Note
You cannot use a wildcard (*) in the Principal element in a role's trust policy.
Role for cross-account access
Granting access to resources in one account to a trusted principal in a different account. Roles are the primary way to grant cross-account access. However, with some of the web services offered by AWS you can attach a policy directly to a resource (instead of using a role as a proxy). These are called resource-based policies, and you can use them to grant principals in another AWS account access to the resource. The following services support resource-based policies for the specified resources: Amazon Simple Storage Service (S3) buckets, Amazon Glacier vaults, Amazon Simple Notification Service (SNS) topics, and Amazon Simple Queue Service (SQS) queues.
Common Scenarios for Roles: User, Applications, and Services
As with most AWS features, you generally have two ways to use a role: interactively in the IAM console, or programmatically with the AWS CLI, Tools for Windows PowerShell, or API.
IAM users in your account using the IAM console can switch to a role to temporarily use the permissions of the role in the console. The users give up their original permissions and take on the permissions assigned to the role. When the users exit the role, their original permissions are restored.
An application or a service offered by AWS (like Amazon EC2) can assume a role by requesting temporary security credentials for a role with which to make programmatic requests to AWS. You use a role this way so that you don't have to share or maintain long-term security credentials (for example, by creating an IAM user) for each entity that requires access to a resource.
The simplest way to use roles is to grant your IAM users permissions to switch to roles that you create within your own or another AWS account. They can switch roles easily using the IAM console to use permissions that you don't ordinarily want them to have, and then exit the role to surrender those permissions. This can help prevent accidentalaccess to or modification of sensitive resources.
Security Token Services (STS)
Understanding some key terms in STS:
Using Assume role option on AWS Management Console, Services, CLI and Applications API (AssumeRole)
For more complex uses of roles, such as granting access to applications and services, or federated external users, you can call the AssumeRole API. This API call returns a set of temporary credentials that the application can use in subsequent API calls. Actions attempted with the temporary credentials have only the permissions granted by the associated role. An application doesn't have to "exit" the role the way a user in the console does; rather the application simply stops using the temporary credentials and resumes making calls with the original credentials.
Steps to Switch role or assume role:
To switch to a role
-
In the IAM console, choose your user name on the navigation bar in the upper right. It typically looks like this:username@account_ID_number_or_alias.
For Identity, select Switch Role. If this is the first time selecting this option, a page appears with more information. After reading it, click Switch Role. If you clear your browser cookies, this page can appear again.
On the Switch Role page, type the account ID number or the account alias and the name of the role that was provided by your administrator.
Note
If your administrator created the role with a path, such asdivision_abc/subdivision_efg/roleToDoXYZ, then you must type that complete path and name in the Role box. If you type only the role name, the attempt to switch role fails.
Important
If you create the role programmatically instead of in the IAM console, then you have an option to add a Path of up to 512 characters in addition to the RoleName, which can be up to 64 characters long. However, to use a role with the Switch Role feature in the IAM console, the combined Path andRoleName cannot exceed 64 characters. This is a limit of the browser cookies that store the role name.
(Optional) Type text that you want to appear on the navigation bar in place of your user name when this role is active. A name is suggested, based on the account and role information, but you can change it to whatever has meaning for you. You can also select a color to highlight the display name. The name and color can help remind you when this role is active, which changes your permissions. For example, for a role that gives you access to the test environment, you might specify a Display Name of Test and select the green Display Color. For the role that gives you access to production, you might specify a Display Name of Production and select red as theDisplay Color.
Click Switch Role. The display name and color replace your user name on the navigation bar, and you can start using the permissions that the role grants you.
To stop using a role
In the IAM console, select your role's Display Name on the right side of the navigation bar.
Select Back to UserName. The role and its permissions are deactivated, and the permissions associated with your IAM user and groups are automatically restored.
Using role for Federated Identity providers like Web Identity (Facebook, google and etc.,) / Third party identity providers (SAML 2.0) / Cross account access
Federated users sign in by using credentials from an identity provider (IdP) like Web Identity (Facebook, google and etc.,) or Third party identity provider. AWS then provides temporary credentials to the trusted IdP to pass on to the user for including in subsequent AWS resource requests. Those credentials provide the permissions granted to the assigned role.
Web Identity Federation role (AssumeRoleWithWebIdentity):
Please follow the below sequence of steps to work with Web Identity Federation services in Security Token Services. Amazon recently added this Web Identity Federation services in STS.
Active Directory (SAML 2.0) or Third party Identity Federation role (AssumeRoleWithSAML and GetFederationToken):
Below are steps which explains how AWS Management console is accessed via Active Directory Federation Services to achieve single sign-on (SSO) feature.
Below are steps which explains how some third party application using Federation service in AWS.
In the Exam point of view, please remember below mandatory steps and scenarios.
Scenario 1:
Scenario 2:
