55. AWS Identity and Access Management

松桐
2023-12-01

Overview

  • AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources.
  • You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
  • When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account.
  • We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones.

IAM features

  • Shared access to your AWS account
  • Granular permissions
  • Secure access to AWS resources for applications that run on Amazon EC2
  • Multi-factor authentication (MFA)
  • Identity federation
  • Identity information for assurance
  • PCI DSS Compliance
  • Integrated with many AWS services
  • Eventually Consistent
  • Free to use

How IAM works

Terms

  • IAM 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.
  • 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.
  • IAM Entities
    • The IAM resource objects that AWS uses for authentication.
    • These include IAM users and 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. Principals include federated users and assumed roles.

Principal

  • principal is a person or application that can make a request for an action or operation on an AWS resource.
  • The principal is authenticated as the AWS account root user or an IAM entity to make requests to AWS

Request

  • When a principal tries to use the AWS Management Console, the AWS API, or the AWS CLI, that principal sends a request to AWS. The request includes the following information:
    • Actions or operations – The actions or operations that the principal wants to perform. This can be an action in the AWS Management Console, or an operation in the AWS CLI or AWS API.
    • Resources – The AWS resource object upon which the actions or operations are performed.
    • Principal – The person or application that used an entity (user or role) to send the request. Information about the principal includes the policies that are associated with the entity that the principal used to sign in.
    • Environment data – Information about the IP address, user agent, SSL enabled status, or the time of day.
    • Resource data – 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. 
  • To authenticate from the console as a root user, you must sign in with your email address and password
  • To authenticate from the API or AWS 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.
  • To provide your users with permissions to access the AWS resources in their own account, you need only identity-based policies.
  • Resource-based policies are popular for granting cross-account access.
  •  If a single permissions policy includes a denied action, AWS denies the entire request and stops evaluating. This is called an explicit deny.
  • AWS authorizes your request only if every part of your request is allowed by the applicable permissions policies

Actions or operations

  • After your request has been authenticated and authorized, AWS approves the actions or operations in your request. 
  • To allow a principal to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource.

Resources

  • After AWS approves the operations in your request, they can be performed on the related resources within your account.

IAM Identities

Root user credentials

  • the email address and password that you provided when creating the account
  • When you use your root user credentials, you have complete, unrestricted access to all resources in your AWS account, including access to your billing information and the ability to change your password

IAM users

  • Instead of sharing your root user credentials with others, you can create individual IAM users within your account
  • IAM users are not separate accounts; they are users within your account
  • Each user can have its own password for access to the AWS Management Console.
  • You can also create an individual access key for each user so that the user can make programmatic requests to work with resources in your account.
  • We recommend that you create an IAM user for yourself and then assign yourself administrative permissions for your account.
  •  A user in AWS consists of a name and credentials.
  • 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 have a maximum of two access keys.
      • Access keys are long-term credentials for an IAM user or the AWS account root user.
      • When you create an access key pair, save the access key ID and secret access key in a secure location.
      • The secret access key is available only at the time you create it. If you lose your secret access key, you must delete the access key and create a new one.
    • 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. 
  • As a best practice, use temporary security credentials (IAM roles) instead of access keys, and disable any AWS account root user access keys.
  • Each IAM user is associated with one and only one AWS account.
  • For increased security, we recommend that you configure multi-factor authentication (MFA) to help protect your AWS resources.
  • You can generate and download a credential report that lists all users in your account and the status of their various credentials, including passwords, access keys, and MFA devices
  • You can generate a credential report as often as once every four hours

IAM User Group

  • An IAM user group is a collection of IAM users. You can use user groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users. 
  • Any user in that user group automatically has the permissions that are assigned to the user group.
  • A user group is a way to attach policies to multiple users at one time
  • User groups can't be nested; they can contain only users, not other user groups.

IAM Role

  • An IAM role is an IAM identity that you can create in your account that has specific permissions.
  • An 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.
  • However, a role does not have any credentials (password or access keys) associated with it.
  • Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
  • 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
  • You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources.
  • 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 than 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.

AWS service role

  • 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. 

AWS service role for an EC2 instance

  • A special type of service role that an application running on an Amazon EC2 instance can assume to perform actions in your account. This role is assigned to the EC2 instance when it is launched.

AWS service-linked role

  • 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. 
  • A service might automatically create or delete the role.
  • Service-linked roles make setting up a service easier because you don't have to manually add the necessary permissions.

Role chaining

  • Role chaining occurs when you use a role to assume a second role through the AWS CLI or API.
  • Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour

Delegation

  • The granting of permissions to someone to allow access to resources that you control.
  • Delegation involves setting up a trust between two accounts.
    • The first is the account that owns the resource (the trusting account).
    • The second is the account that contains the users that need to access the resource (the trusted account)
  • To delegate permission to access a resource:
    • create an IAM role in the trusting account 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 account members are allowed to assume the role.
      • The trust policy is attached to the role in the trusting account, and 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. 

Trust policy

  • 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.

Permissions policy

  • 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.

Permissions boundary

  • 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

Permissions and policies

  •  A policy is an object in AWS that, when associated with an identity or resource, defines their permissions.
  • You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources.
  • 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.
  • You can organize IAM users into IAM groups and attach a policy to a group. In that case, individual users still have their own credentials, but all the users in a group have the permissions that are attached to the group
  • 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
  • Identity-based policies are permissions policies that you attach to an IAM identity, such as an IAM user, group, or role.
    • 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 – Managed policies that are created and managed by AWS. If you are new to using policies, we recommend that you start by using AWS managed policies.
      • Customer managed policies – Managed policies that you create and manage in your AWS account. Customer managed policies provide more precise control over your policies than AWS managed policies. You can create, edit, and validate an IAM policy in the visual editor or by creating the JSON policy document directly. 
    • Inline policies – Policies that you create and manage and that are embedded directly into a single user, group, or role. In most cases, we don't recommend using inline policies.
  • Resource-based policies are permissions policies that you attach to a resource such as an Amazon S3 bucket or an IAM role trust policy.
    • Resource-based policies are inline policies, and there are no managed resource-based policies.
    • 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

Attribute-based access control (ABAC)

  • Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes.
  • In AWS, these attributes are called tags

AWS IAM Access Analyzer

  • Access Analyzer identifies resources shared with external principals by using logic-based reasoning to analyze the resource-based policies in your AWS environment.
  • For each instance of a resource shared outside of your account, Access Analyzer generates a finding.
  • Each finding includes details about the resource, the external entity with access to it, and the permissions granted so that you can take appropriate action. 
  • Access Analyzer also analyzes all resource-based policies periodically.

Reference

What is IAM? - AWS Identity and Access Management

 类似资料: