IAM is a powerful service that allows you to control how people and programs are allowed to manipulate your AWS infrastructure.
First, IAM is not an identity store/authorization system for your applications.
Second, IAM is not operating system identity management.
Authentication Technologies
| Use Case | Technology Solutions |
|---|---|
| Operating System Access | Active Directory LDAP Machine-specific accounts |
| Application Access | Active Directory Application User Repositories Amazon Cognito |
| AWS Resources | IAM |
Principals
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.
Root User
The root user is similar in concept to the UNIX root or Windows Administrator account—it has full privileges to do anything in the account, including closing the account. It is strongly recommended that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user and then securely locking away the root user credentials.
IAM Users
Users are persistent identities set up through the IAM service to represent individual people or applications.
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.
Amazon EC2 Roles
Using IAM roles for Amazon EC2 removes the need to store AWS credentials in a configuration file.
Cross-Account Access//重点
Another common use case for IAM roles is to grant access to AWS resources to IAM users in other AWS accounts. These accounts may be other AWS accounts controlled by your company or outside agents like customers or suppliers. You can set up an IAM role with the permissions you want to grant to users in the other account, then users in the other account can assume that role to access your resources. This is highly recommended as a best practice,as opposed to distributing access keys outside your organization.
Federation//重点
Many organizations already have an identity repository outside of AWS and would rather leverage that repository than create a new and largely duplicate repository of IAM users.Similarly, web-based applications may want to leverage web-based identities such as Facebook, Google, or Login with Amazon. IAM Identity Providers provide the ability to federate these outside identities with IAM and assign privileges to those users authenticated outside of IAM.
Authentication
User Name/Password
IAM allows you to create a password policy enforcing password complexity and expiration.
Access Key
Key—An access key is a combination of an access key ID (20 characters) and an access secret key (40 characters).
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.
Authorization
Authorization is handled in IAM by defining specific privileges in policies and associating those policies with principals.
Policies
A policy is a JSON document that fully defines a set of permissions to access and manipulate AWS resources.
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”
For some services, wildcard values are allowed;
Action—The action value specifies the subset of actions within a service that the permission allows or denies.
Condition—The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.
Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) can add an extra layer of security to your infrastructure by adding a second method of authentication beyond just a password or access key.
It is strongly recommended that AWS customers add MFA protection to their root user.
Rotating Keys
it is a security best practice to rotate access keys associated with your IAM users.
Access keys should be rotated on a regular schedule.
Resolving Multiple Permissions
- Initially the request is denied by default.
- All the appropriate policies are evaluated; if there is an explicit “deny” found in any policy, the request is denied and evaluation stops.
- If no explicit “deny” is found and an explicit “allow” is found in any policy, the request is allowed.
- If there are no explicit “allow” or “deny” permissions found, then the default “deny” is maintained and the request is denied.