Identity Access Management IAM refers to a framework of policies and technologies for ensuring that an organization has the appropriate technology resources.
Or
AWS identity and access management (IAM) is a web service that allows you to securely control access to AWS resources by controlling who is authenticated (signed in) and authorized (has access to the resources).
When you first create an AWS account, you begin with a single sign-on identity that has complete access to all AWS services and resources in the account.
This identity is called the "AWS account of the root user" and is accessed by signing in with the email address and password that you used to create the account.
AWS strongly advises against using the root user for routine tasks, even administrative ones.
Use other IAM user accounts to manage the administrative aspects of your account and securely lock away the root user credentials, using them to perform only a few account and service management tasks.
The IAM user limit per AWS account is 5000; you can add up to 10 users at once.
You are also limited to 300 groups per AWS account.
You are limited to 1,000 IAM roles under your AWS account.
The default limits of managed policies attached to an IAM role are 10,.
An IAM user can belong to a maximum of ten groups.
An IAM user can have a maximum of two access keys assigned to them.
1) With shared access to your AWS account, you can grant other people permission to be administrators and use resources in your AWS account without having to share your access credentials (passwordd access key).
2) Permissions Granularity
You can grant different permissions to different people for different resources.
For instance, you can allow some users complete access to EC2, S3, Dynamo DB, and Redshift, while for others, you can allow read-only access to just some S3 buckets or permission to administer just some EC2 instances or to access your billing information but nothing else.
3) Secure access to AWS resources for applications that run on Amazon EC2.
You can use IAM features to securely provide the credentials required by applications running on EC2 instances to access other AWS resources. Examples include S3 buckets and RDS or Dynamo DB databases.
4) Multi-factor authentication (MFA)
You can add two-factor authentication to your account and to individual users for extra security. You can use physical hardware or virtual MFAC (for example, Google Authentication).
5) Identity federation
You can allow users who already have passwords elsewhere, e.g., in your corporate networks or with an internet identity provider, to get temporary access to your AWS account.
6) Identity information for assurance
If you use AWS cloud trail, you receive log records that include information about those who made requests for resources in your account; this information is based on IAM identities.
7) PCI-DSS conformity
IAM supports the processing, storage, and transmission of credit card information by a merchant or service provider and has been validated as being compliant with the Payment Card Industry (PCI) Data Security Standard (DSS).
8) Eventually, consistency
If a request to change the same data is successful, the change is committed and safely stored; however, the change must be replicated across IAM, which can take some time.
IAM achieves high availability by replicating data across multiple servers within an AWS data center around the world.
IAM Terms:
1) Principles: A principle is a person or application that can make a request for an action or operation on an AWS resource.
Your administrative IAM users are your first priority.
You can allow users and services to assume a role.
IAM users, federated IAM users, and services to assume a rate.
You can support federated users or programmatic access to allow an application to access your AWS account.
2) Request: When a principle tries to use the AWS management console or the AWS CLI, that principle sends a request to AWS. This request includes the following information:
3) Action: That the principles want to perform.
the resource on which the actions are carried out.
information about the principles, including the environment in which the request was made.
Actions are defined by a service and are things that you can do to a resource, such as viewing, creating, editing, and deleting that resource.
IAM supports approximately 40 actions for a user resource, including create user, delete user, etc.
Any actions or resources that are not explicitly allowed are denied by default.
After your request was authenticated and authorized, AWS approved the action in your request.
4) Request Context: Before AWS can evaluate and authorize a request, it gathers the request information.
principle, the requester is determined based on the authorization data.
This includes the aggregate permission that is associated with that principle.
information about the environment, such as an IP address, a user agent, SSL-enabled states, or the time of day.
data on resources or data related to the resources requested.
5) Authentication: A person sending a request must be authenticated and signed in to AWS to send a request to AWS.
Some AWS services, like AWS S3, allow requests from anonymous users; these are exceptions to the rule.
To authenticate from the console as a root user, you must sign in with your username and password.
You must provide your access key and secret key to authenticate from the API to the CLI.
You might also be required to provide additional security information, like MFA.
e.g., Google authentication
6) Authorization: To authorize a request, IAM users use the request context to check for matching policies and determine whether to allow or deny the request.
IAM policies are sorted in IAM as JSON documents and specify the permissions that are allowed or denied.
User-based (identity-based) policies specify which principles have permissions granted or denied. s.
7) Resource: A resource is an entity that exists within a service.
There are EC2 instances, S3 buckets, IAM users, and a DynamoDB table, for example.
Each AWS service defines a set of actions that can be performed on each resource.
After AWS approves the actions on your request, these actions can be performed on the related resources in your account.
When you make a request to perform an unrelated action on a resource, it is denied.
When you provide permission using the identity-based policy in IAM, you provide permission to access resources only within the same account.
Note: By default, only the AWS root user has access to all the resources in that account.
Resources-based policies specify whether permission is granted or denied for resources that are commonly used to grant cross-account permission.
IAM checks each policy that matches the context of your request and stops evaluating it; this is called an "explicit deny."
By default, all requests are denied; an explicit allow overrides this default.
An explicit deny overrides any allows.
You can create a new IAM policy in the AWS management console using one of the following methods:
1) JSON: You can create your own JSON syntax.
2) Visual editor: You can create a new policy from scratch in the visual editor; you do not have to understand JSON syntax.
3) Import: You can import a managed policy within your account and then edit the policy to meet your specific requirements.
Identity Federation:
If your account user already has a way to be authorized, such as authentication through your corporate network,
You can federate those user identities into AWS.
a user who has previously used their corporate identity to access the corporate network.
The corporation can replace their existing identity in your AWS accounts with a temporary identity.
This user is able to access the AWS management console.
Similarly, an application that the user is working with can make parametric requests using permissions that you define.
* In this case, federation is only partially useful.
1) Your users already have identities in a corporate directory.
Make up languages (2.0) if your corporate directory is corporate with security assertions.
You can configure your corporate directory to provide AWS access via single sign-on (SSO).
management console for your users.
If your corporate directory is not compatible with SAML 2.0,
You can create an identity broker application to provide single-sign-on SSD access to the AWS management console for your users.
If your corporate directory is Microsoft Active Directory, you can use the AWS directory service to establish trust between your corporate directory and your AWS account.
2) Your users already have Internet identities.
If you are developing a mobile or web-based app that allows users to identify themselves via an internet identity provider, such as Amazon, Facebook, Google, or any other open ID connect (ODC) compatible identity provider, the app can use web federation to access AWS.
AWS recommends using AWS cognate for identity federation.
3) IAM users and SSO
IAM users in your account have access only to the AWS resources that you specify in the policy that is attached to the user or to an IAM group that the user belongs to. To work in the console, the user must have permissions to perform the actions that the console performs, such as hosting and creating AWS resources.
IAM Identities
User, group, role
IAM Identities is the section of your AWS account that you check to provide authentication for people who apply for and use your AWS account.
Identities request the user and can be authenticated and then authorized to perform actions in AWS.
Each of these can be associated with one or more policies to determine what actions a user, role, or member of a group can take with resources and under what conditions.
IAM groups are collections of IAM users.
IAM roles are very similar to those of IAM users.
User:
An IAM user is an entity that you create in AWS. It represents the person or service that uses the IAM user to interact with AWS.
You can add up to five users at once.
An IAM user can reprint a real person or a program that needs AWS access to perform actions on AWS resources.
A primary use for IAM users is to give people the ability to sign into the AWS management console for interaction tasks and to make programmatic requests to AWS services using the API or CLI.
For any user, you can assign them.
A username and password are required to access the AWS console.
to access the key ID and secret key that they can use for programmatic access.
The newly created IAM user has no password or access key; you must create one.
Each IAM user is associated with one online AWS account.
Groups:
An IAM group is a collection of IAM users.
It is a way to assign permission policies to multiple users at once.
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 create a group called "HR" and grant it the permissions that the HR department typically requires.
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 administrative privileges, you can assign the appropriate permission by adding the user to that group.
If a person changes jobs in your organization, instead of asking that user's permission, you can remove him or her from the old groups and add him or her to the appropriate new groups.
Groups limitations:
A group is not truly ideological in IAM because it cannot be identified as a principle in a permission policy.
Groups cannot be nested.
You have a limit of 300 groups in your AWS account.
A user can be a member of up to 10 IAM groups.
IAM Roles:
A user IAM role is similar to an IAM role in that it focuses on identification with permissions policies that determine what the identified can and cannot do in AWS.
An IAM role does not have any credentials (password or access key) associated with it.
Instead of being uniquely associated with one person, a role is intended to be assumed by anyone who needs it.
An IAM user can temporarily assume different permissions for a specific task by assuming a role.
An IAM role can be assigned to a federated user who signs in with an external identity rather than IAM.
IAM has temporary credentials.
Temporary credentials are primarily used with IAM roles, but there are also other users.
You can request temporary credentials that have a more restricted set of permissions than your standard IAM users.
This prevents you from performing tasks that are explicitly forbidden by the more restricted credentials.
A benefit of temporary credentials is that they expire automatically after a set period of time.
Permissions and policies
The access management portion of AWS identity and access management (IAM) helps you define what a user or other entity is allowed to do in an account, often referred to as authorization.
Permission is granted via policies, which are created and then assigned to user groups or roles.
Policies and users
By default, IAM users can't access anything in your account.
You grant permissions to a user by creating a policy, which is a document that defines the effects of actions, resources, and optional conditions.
Any actions or resources that are not explicitly allowed are denied by default.
I have several policies.
Users or groups can have multiple policies attached to them that grant different permissions.
in the case of multiple policies attached to a user or a group.
The users' permissions are calculated based on the combinations of policies.
* Federated Users' and Roles:
Federated users don't have permanent identities in their AWS accounts the way that IAM users do.
To assign permissions to federated users, you can create an entity referred to as a role and define permissions for the role.
When a federated user signs in to AWS, the user is associated with the role and is granted the permissions that are defined in the role.
Resources and policies
In the same cases (like an S3 bucket), you can attach a policy to resources in addition to attaching it to a group OU; this is called resource-based policy.
A resource-based policy contains slightly different information than a user-based policy.
In a resources-based policy, you specify what actions are permitted and what resources are different.
You also explicitly list who is allowed access to the resources (a principle).
Resource-based policies include a principal element that specifies who is granted the permissions.
AWS recommends that you don't use root user credentials for Everday access.
Additionally, AWS advises against sharing your root user credentials with anyone because doing so grants them unrestricted access to your user account.
Make an IAM user for yourself and grant yourself administrative access to your account.
You can then sign in as that user to add more users as needed.
You can then sign in as that user to add more users as needed.
An IAM user with administrator permissions is not the same as the AWS account root user.
By default, a new IAM user
A new IAM user has no permission to do anything.
does not have a password or an access key (neither an access key ID nor a secret access key). It means no credentials of any kind.
You must create the type of credentials for an IAM user based on what the user will be doing.
You can grant user permissions by attaching IAM policies to them directly or by making them members of an IAM group, in which case they inherit the group policies' permissions.
You can have up to 5000 users per AWS account.
An IAM role is 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. Instead of being uniquely associated with one person, a role is intended to be assumed by anyone who needs it.
A role does not have any standard long-term credentials (passwords or access keys) associated with it.
If a user assumes a role, temporary security credentials are automatically created and provided to the user.
There are two approaches to using roles:
Interacting in the IAM console 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 user must give up their original permissions and take on the permissions assigned to the role.
when the user gives up their original permission and takes on the permission assigned to them.
When the user exits the role, their original permissions are restored.
Programmatically with the AWS CLI, tools for Windows PowerShell, or API
An AWS-provided application or service (such as Amazon EC2) can assume a role by requesting temporary security credentials for a role in order to make programmatic requests to AWS.
You use a role in this manner to avoid having to share maintained long-term security credentials with each entity that needs access to a resource.
In other words, the user continues to have access to resources in the trusted account at the same time that he or she has access to the resources in the trusted account.
This is useful for tasks such as transferring information to or from the shared resources in the other account.
Note That:
Not all services and support resources follow this policy.
To delegate permissions to access resources, you create an IAM role that has two policies attached.
1) The trust policy
2) The permission policy
The trust entity is included in the policy as the principal element in the documents.
When you create a trust policy, you cannot specify a wild card as a principle.
* Cross-account permissions
You might need to allow users from another AWS account to access resources in your AWS account; if so, don't share security credentials such as access keys between accounts.
in place of US IAM roles
You can define a role in the trust that specifies what permissions the IAM users in the other account are allowed.
You can also determine which AWS accounts have the IAM users that are allowed to assume the role that we do not define as "users," but rather an "AWS account."
Roles are the primary way to grant cross-account access.
However, you can attach policies directly to specific resources using the same type of web server provided by AWS; these are known as resource-based policies. You can use them to grant users in another AWS account access to the resources.
The following services support resource-based policy:.
Amazon S3
Amazon Simple Notification Services
Amazon Simple Queue Service
Amazon Glacier Value
