(Identity and access management)
Shared access to your AWS account, Granular permission.
Secure access to resources for an application that runs on ec2 example S3, RDS, DynamoDB.
MFA, Identity federation.
Identity information for assurance (cloud trail logs).
PCI DSS compliance, eventually consistent, Free to use.
The IAM infrastructure includes the following elements:
Principal
Request
Authentication
Authorization
Resources
Action/Operations
Resources: The user, group, role, policy, and identity provider objects that are stored in IAM. As with other AWS services, you can add, edit, and remove resources from IAM.
Identities: The IAM resource objects that are used to identify and group. You can attach a policy to an IAM identity. These include users, groups, and roles.
Entities: The IAM resource objects that AWS uses for authentication. These include IAM users, federated users, and assumed IAM roles.
Principals: A person or application that uses the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS.
Request: Principal sends a request to AWS. That request includes action/operations, resources, principal, environment data, resource data.
**Here environment data is user IP, user-agent, user permission, time and date
**Resource data is all about Data related to the resource that is being requested. This can include information such as a DynamoDB table name or a tag on an Amazon EC2 instance.
AWS gathers the request information into a request context, which is used to evaluate and authorize the request.
Authentication: A principal must be authenticated (signed in to AWS) using their credentials to send a request to AWS. Some services, such as Amazon S3 and AWS STS, allow a few requests from anonymous users. However, they are the exception to the rule.
**To authenticate from the API or CLI, you must provide your access key and secret key.
Authorization: You must also be authorized (allowed) to complete your request. During authorization, AWS uses values from the request context to check for policies that apply to the request. It then uses the policies to determine whether to allow or deny the request. Most policies are stored in AWS as JSON documents and specify the permissions for principal entities.
AWS checks each policy that applies to the context of your request. If a single permissions policy includes a denied action, AWS denies the entire request and stops evaluating. This is called an explicit deny. Because requests are denied by default, AWS authorizes your request only if every part of your request is allowed by the applicable permissions policies. The evaluation logic for a request within a single account follows these general rules:
By default, all requests are denied. (In general, requests made using the AWS account root user credentials for resources in the account are always allowed.)
An explicit allow in any permissions policy (identity-based or resource-based) overrides this default.
The existence of an Organizations SCP, IAM permissions boundary, or a session policy overrides the allow. If one or more of these policy types exists, they must all allow the request. Otherwise, it is implicitly denied.
An explicit deny in any policy overrides any allows.
**An IAM user doesn't have to represent an actual person; you can create an IAM user in order to generate an access key for an application that runs in your corporate network and needs AWS access.
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 or resource, defines their permissions.
AWS evaluates these policies when a principal uses an IAM entity (user or role) to make a request. Permissions in the policies determine whether the request is allowed or denied.
When you create an IAM user, they can't access anything in your account until you give them permission. You give permissions to a user by creating an identity-based policy, which is a policy that is attached to the user or a group to which the user belongs.
The following example shows a JSON policy that allows the user to perform all Amazon DynamoDB actions (dynamodb:*) on the Books table in the 123456789012 account within the us-west-2 Region.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws-cn:dynamodb:us-west-2:123456789012:table/Books"
}
}
Identity-based policies: These are permissions policies that you attach to an IAM identity, such as an IAM user, group, or role. Identity-based policies control what actions the identity can perform, on which resources, and under what conditions. Identity-based policies can be further categorized:
Managed policies – Standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. You can use two types of managed policies: AWS managed policies, Customer managed policies.
Inline policies – Policies that you create and manage and that are embedded directly into a single user, group, or role. In most cases, AWS doesn't recommend using inline policies.
Resource-based policies: These are permissions policies that you attach to a resource such as an Amazon S3 bucket or an IAM role trust policy. These are popular for granting cross-account access. These are supported only by some AWS services.
Resource-based policies control what actions a specified principal can perform on that resource and under what conditions. Resource-based policies are inline policies only, not managed. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy.
The IAM service supports only one type of resource-based policy called a role trust policy, which is attached to an IAM role. Because an IAM role is both an identity and a resource that supports resource-based policies, you must attach both a trust policy and an identity-based policy to an IAM role.
Trust policies define which principal entities (accounts, users, roles, and federated users) can assume the role.
To better understand these concepts, view the following figure. The administrator of the 123456789012 account attached identity-based policies to the JohnSmith, CarlosSalazar, and MaryMajor users. Some of the actions in these policies can be performed on specific resources. For example, the user JohnSmith can perform some actions on Resource X. This is a resource-level permission in an identity-based policy. The administrator also added resource-based policies to Resource X, Resource Y, and Resource Z. Resource-based policies allow you to specify who can access that resource. For example, the resource-based policy on Resource X allows the JohnSmith and MaryMajor users list and read access to the resource.
The 123456789012 account example allows the following users to perform the listed actions:
JohnSmith – John can perform list and read actions on Resource X. He is granted this permission by the identity-based policy on his user and the resource-based policy on Resource X.
CarlosSalazar – Carlos can perform list, read, and write actions on Resource Y, but is denied access to Resource Z. The identity-based policy on Carlos allows him to perform list and read actions on Resource Y. The Resource Y resource-based policy also allows him write permissions. However, although his identity-based policy allows him access to Resource Z, the Resource Z resource-based policy denies that access. An explicit Deny overrides an Allow and his access to Resource Z is denied.
MaryMajor – Mary can perform list, read, and write operations on Resource X, Resource Y, and Resource Z. Her identity-based policy allows her more actions on more resources than the resource-based policies, but none of them deny access.
ZhangWei – Zhang has full access to Resource Z. Zhang has no identity-based policies, but the Resource Z resource-based policy allows him full access to the resource. Zhang can also perform list and read actions on Resource Y.
Amazon S3 supports identity-based policies and resource-based policies (referred to as bucket policies). In addition, Amazon S3 supports a permission mechanism known as an access control list (ACL) that is independent of IAM policies and permissions. You can use IAM policies in combination with Amazon S3 ACLs.
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.
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
Resource based policies need the trusted account to create users with permissions to be able to access the resources from the trusting account.
The principals that you can specify in a resource-based policy include accounts, IAM users, federated users, IAM roles, assumed-role sessions, or AWS services.
Federated users don't have permanent identities in your AWS account 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.
It is particularly useful in the cases below.
In the case of corporate active directory
Your corporate directory must be compatible with SAML 2.0.
If the directory is not compatible with SAML 2.0, an identity broker application will be created to provide access to a w s console.
If the directory is Microsoft’s active directory, AWS directory service can be used to establish trust between a corporate active directory and an AWS account.
In the case of web identity like Google, Facebook etc.
If a mobile app is being created that can let users identify themselves through an internet identity provider like Facebook, Google, or any open ID Connect (OIDC) identity provider using the web federation to access AWS.
Uses
Groups
Roles
Each of these can be associated with one or more policies to determine what actions a user or role can do with which resource under what condition.
A username and password are required to access the AWS console.
An access key and secret key is required to access an account using programmatic access.
Newly created IAM users don't have a password and access key. You need to create a password and access key.
A group is not truly an identity in IAM because it cannot be identified as a principal in a permission policy.
Groups cannot be nested.
Maximum 300 groups can be in an AWS account.
Users can be part of 10 groups.
An IAM role is similar to a user, it is an identity with permission policies that determine what the Identity can or can't do in AWS.
Roles doesn't have any credentials associated with it.
Permissions are granted through policies that are created and then attached to users, groups, or roles.
To assign permissions to federated users you can create a role and define the permission.
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 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, you could use an ARN to 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/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.
You can view and download the secret key only when you create the access key.
You cannot view or recover a secret key and access key later.
If you lose your secret key, you can create a new access key.
An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.
Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.
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/her own permission and instead takes on the permissions of the role. When the user exists, or stops using the role, the original user permissions are restored.
The primary way to grant cross-account access.
A role that a service assumes to perform actions in your account on your behalf.
When you set up some 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.
A service-linked role is a unique type of IAM 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.
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 for the service to complete actions on your behalf.
The linked service defines the permissions of its service-linked roles, and unless defined otherwise, only that service can assume the roles.
The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete the roles only after first deleting their related resources. This protects your resources because you can't inadvertently remove permission to access the resources.
A JSON policy document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM. The principals that you can specify in the trust policy include users, roles, accounts, and services.
An advanced feature in which you use policies to limit the maximum permissions that an identity-based policy can grant to a role. You cannot apply a permissions boundary to a service-linked role.
Instead of creating an IAM user, you can use existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider. These are known as federated users. AWS assigns a role to a federated user when access is requested through an identity provider.
Delegation is the granting of formation to someone to allow access to resources that you control.
Delegation involves setting up a trust between the account that owns the resources (trusting) and the account that contains the use of that need to access the resources (trusted).
The trusted interesting account can be any of the following:
Same account
The accounts that both are under control of your organization.
Two accounts owned by different organizations.
To delegate permissions to access a resource you create an IAM role which has two policies attached:
The trust policy
The permission policy
A trusted entity is included in the policy as the principal element in the document. We cannot use a wildcard as a principal in the policy.
Temporary security credentials are generated by AWS STS. By default, AWS STS is a global service.
You can use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources.
Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested. When (or even before) the temporary security credentials expire, the user can request new credentials, as long as the user requesting them still has permissions to do so.
You can provide access to your AWS resources to users without having to define an AWS identity for them. Temporary credentials are the basis for roles and identity federation.
Need 2 accounts, account 1 and account 2
Create a group in account 1 and add users.
Create an S3 bucket in account 2.
Create an IAM role in account 2.
Four trusted identities will be there:
AWS service
Another AWS account.
Web identity.
SAML 2.0 federation.
Select another AWS account
Paste account ID of account 1.
Permissions: S3 Read
create an inline policy in account1 and attach it to the group in account1.
Policy generator>Allow>security token service
Assume Role>ARN:*(All users) >Add Statement
Check by logging in user 1 and switch roles.