AWS - Identity and Access Manag

• IAM is eventually consistent.

Workflow

Principal

A principal is a person or application that can make a request for an action or operation on an AWS resource.

Authentication

You need to sign your request with credentials, such as email, username, password, before it is sent to AWS. (signed in)

Reuqest

When a principal tries to use the AWS Management Console, the AWS API, or the AWS CLI, that principal sends a request including the following information to AWS:

• The actions or operations that the principal wants to perform.
• The AWS resource object upon which the actions or operations are performed.
• Information about the principal includes the policies that are associated with the entity that the principal used to sign in.
• Environment data such as IP address, user agent, SSL enabled status, or the time of day.
• Data related to the resource such as a DynamoDB table name or a tag on an Amazon EC2 instance.

Authorization

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. Requests are denied by default, AWS authorizes your request only if every part of your request is allowed by the applicable permissions policies. If a single permissions policy includes a denied action, AWS denies the entire request and stops evaluating. This is called an explicit deny. (has permission)

After your request has been authenticated and authorized, AWS approves the actions or operations in your request.

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.

User

• A user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. It consists of a name and credentials.
• Credentials: password, access key, and multi-factor authentication (MFA)
• When an IAM user forget his password, he must ask his administrator to reset his password
• For those regions do not support AWS Certificate Manager (ACM), you use IAM to manage certificates and access certificates by HTTPS connections. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage.
• You cannot manage your certificates in IAM from the IAM Console.
• You must obtain your server certificate from an external provider before you upload it into IAM.

MFA

• When you enable MFA for the root user, it affects only the root user credentials.
• You can get MFA from Virtual MFA devices, U2F security key, Hardware MFA device, and SMS text message-based MFA
• MFA-protected API access
  • MFA authentication is used only to determine whether a user can assume the role. Once the user has assumed the role, no further MFA checks are made
  • A policy must include the aws:MultiFactorAuthPresent condition key to enforce the use of MFA
  • GetSessionToken: Use when:
    1. call API operations that access resources in the same AWS account as the IAM user who makes the request
    2. access to resources that are protected with resource-based policies that include an MFA
  • Temporary credentials returned by GetSessionToken include MFA information
    condition
  • AssumeRole: Use when call API operations that access resources in the same or a different AWS account.
    Temporary credentials returned by AssumeRole do not include MFA information in the context,
• Federated users cannot be assigned an MFA device for use with AWS services, so they cannot access AWS resources controlled by MFA
• Other AWS STS API operations that return temporary credentials do not support MFA.
• Long-term credentials cannot be used with MFA-protected API access because they don't expire

Password Policy

You can set a password policy to specify complexity requirements and mandatory rotation periods for your IAM users' passwords
When the minimum length and character type requirements change, these settings are enforced the next time that your users change their passwords.
When you set a password expiration period, the expiration period is enforced immediately.

CodeCommit

CodeCommit is a managed version control service that hosts private Git repositories in the AWS cloud.
You can authenticate your IAM credentials used to communicate with CodeCommit repositories in three ways:

• Git Credentials (Recommended)
  You generate a static user name and password pair for your IAM user, and then use those credentials for HTTPS connections. You can also use these credentials with any third-party tool or integrated development environment (IDE) that supports static Git credentials.

• SSH Keys
  With SSH connections, you create public and private key files on your local machine that Git and CodeCommit use for SSH authentication. You associate the public key with your IAM user and store the private key on your local machine.

• AWS Access Keys
  You can allow Git to use a cryptographically signed version of your IAM user credentials or Amazon EC2 instance role whenever Git needs to authenticate with AWS to interact with CodeCommit repositories.
  This is the only connection method for CodeCommit repositories that does not require an IAM user.
  This is also the only method that works with federated access and temporary credentials.

Group

• An IAM group is a collection of IAM users.
• Groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users.
• A group can contain many users, and a user can belong to multiple groups.

Role

• An IAM role is an IAM identity that you can create in your account that has specific permissions.
• An IAM role is both an identity and a resource that supports resource-based policies.
• A role is intended to be assumable by anyone who needs it.
• A role does not have standard long-term credentials. Instead, when you assume a role, it provides you with temporary security credentials for your role session. IAM roles for EC2 instances Application must sign their API requests with AWS credentials.
• You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources.

Grant cross-account access.

• A user in one account can switch to a role in the same or a different account.

• A user must have the permission to call the AWS Security Token Service (AWS STS) AssumeRole API to grant a role in another account.

• In the account with the role, you specify the accounts by ID whose users need access in the Principal element of the role's trust policy. AWS STS verifies the request with the role's trust policy to ensure that the request is from a trusted entity.

• After verification, AWS STS returns temporary security credentials to the user. With the temporary security credentials, the user can perform only the actions and access only the resources permitted by the role; their original user permissions are suspended. When the user exits the role, the original user permissions are restored.

• To enable cross-account access to a resource, you must

  1. Specify an entire account or IAM entities in account A as the principal in a resource-based policy.in resource R in account B
  2. Add an identity-based policy in account B to grant the principal access to the resource R
     However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required.

Service Role

• A role that a service assumes to perform actions in your account on your behalf.
• You can bind it to your EC2 server so the server can perform services.
• AWS provides Service-linked roles, which are predefined by the service and include all the permissions that the service requires to call other AWS services on your behalf.

Role chaining

• If you have a user called User1 who has permission to assume RoleA and RoleB, and RoleA has the permission to assume RoleB. You can use User1's long-term user credentials in the AssumeRole API operation to assume RoleA, and then use RoleA's short-term credentials to assumeRoleB`. This is called a Role chaining.
• Occurs when you use a role to assume a second role through the AWS CLI or API.
• When you assume a role, you can pass a session tag and set the tag as transitive. Transitive session tags are passed to all subsequent sessions in a role chain.
• Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour. If you assume a role using role chaining and provide a DurationSeconds parameter value greater than one hour, the operation fails.

Providing access to AWS accounts owned by third parties

You need to provide the following to create a role that a third party AWS account can assume:

• The third party's AWS account ID.as the Principal of the trust policy of the role
• An external ID to uniquely associate with the role
• The permissions that the third party requires to work with your AWS resources
  After you create the role, you must provide the role's Amazon Resource Name (ARN) to the third party.

AWS Cognito

• Provides authentication for accessing AWS resources from mobile and web-based Apps.
• Provides API operations for synchronizing user data so that it is preserved as users move between devices.
• For more advanced scenarios, you can work directly with a third-party service like Login with Amazon, Facebook, Google, or any IdP that is compatible with OpenID Connect (OIDC).
• If your organization already uses an identity provider software package that supports SAML 2.0 (Security Assertion Markup Language 2.0), you can create trust between your organization as an identity provider (IdP) and AWS as the service provider. This is known as the single sign-on (SSO) approach to temporary access.
• If your identity store is not compatible with SAML 2.0, then you can build a custom identity broker application to perform a similar function. The identity broker application calls either AssumeRole or GetFederationToken to obtain temporary security credentials from AWS, and then provides them to the user to access AWS resources.
• The identity broker application need to have permissions to access IAM's token service (STS) API.
• To use an IdP, you create an IAM identity provider entity to establish a trust relationship between your AWS account and the IdP.
• IAM supports IdPs that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0).
• You need to generate a thumbprint to enable IdPs with OpenId Connect.
• After you create an IAM identity provider, you must create one or more IAM roles that permits your organization's IdP to request temporary security credentials for access to AWS. The policies assigned to the role determine what the federated users are allowed to do in AWS.

Relying Party and Claim Rule

Telling the IdP about AWS as a service provider is called adding relying party trust between your IdP and AWS.

A claim is information about the user and its groups. A claim rule maps that information into SAML attributes.

You need to create appropriate claim rules in your IdP that specify AWS as a relying party, which makes sure that SAML authentication responses from your IdP contain the necessary attributes that AWS uses in IAM policies to check permissions for federated users.

Tagging IAM Users and Roles

-- Tag keys and values can include any combination of letters, numbers, spaces, and _ . : / = + - @ . symbols.

• Tag key–value pairs are not case sensitive, but case is preserved. Tagging again to a key will overwrite its value.
• You cannot create a tag key or value that begins with the text aws:.
• You cannot create a tag will an empty value.
• You cannot specify multiple values in a single tag, but you can create a custom multi-value structure in the single value.
• You can configure your SAML assertion to pass session tags to AWS.
• You can use the aws:PrincipalTag key in the Condition element of your policies to allow or deny access based on those tags. When a user connect to AWS through a IdP or in AWS STS, you generate a session with credentials. When you use the session credentials to make a subsequent request, the request context includes the aws:PrincipalTag context key.
  When you use temporary credentials to make a request, your principal might include the following tags:
  1. Session tags – These tags were passed when you assumed the role or federated the user using the AWS CLI or AWS API.
  2. Incoming transitive session tags – These tags were inherited from a previous session in a role chain. You set keys as transitive to ensures that those session tags pass to subsequent sessions. You can set only session tags, but not role tags as transitive. If you want to pass a role tag to another session, you must manually include it as a session tag.
  3. IAM tags – These tags were attached to the IAM role that you assumed.
• Your session's permissions are the intersection of the role's identity-based policy and the session policies.
• Permissions are evaluated each time an AWS request is made using the credentials.
• You can use AWS CloudTrail to view the requests made to assume roles or federate users, including the principal tags for the assumed-role or federated user session.

Using Amazon Cognito for mobile apps

Delegation

• The granting of permissions to someone to allow access to resources that you control.
  Trusting account: the account that owns the resource
  Trusted account: the account that contains the users that need to access the resource
• To implement delegation, you create an IAM role in the trusting account with two policies:
  1. The permissions policy grants the user of the role the needed permissions to carry out the intended tasks on the resource.
  2. The trust policy specifies which trusted account members are allowed to assume the role. You cannot specify a wildcard (*) as a principal.

Federation

• The creation of a trust relationship between an external identity provider and AWS.
• A user logs in by existing identities from AWS Directory Service, an enterprise user directory, or a web identity provider is called a federated user.
• AWS assigns a role to a federated user when access is requested through an identity provider.
• A trust policy is a JSON policy document in which you define the principals that you trust to assume the role.
• A permission policy is a JSON format in which you define what actions and resources the role can use.
• A permissions boundary is an advanced feature you can apply to a service-linked role to limit the maximum permissions that an identity-based policy can grant to a role.

Entities

The IAM resource objects that AWS uses for authentication. These include IAM users, federated users, and assumed IAM roles.

Federating existing users

If your user is already:

1. Enterprise identity federation: have identities in a corporate directory, or
2. Web identity federation: have identified themselves through an Internet identity provider like Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC) compatible identity provider

you can temporarily federate those user identities into AWS.
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

The user, group, role, policy, and identity provider objects that are stored in IAM. You can add, edit, and remove resources from IAM.

Policies and Permission

• A policy is an object in AWS that, when associated with an identity or resource, defines their permissions for an action.
• Permissions in the policies determine whether the request is allowed or denied.
• Most policies are stored in AWS as JSON documents.
• Policies are summarized in three tables: the policy summary, the service summary, and the action summary.
• In some cases, if you want to include an action in your policy, you need to include additional related actions.
• Six types of policies:
  • Identity-based policies
  • Resource-based policies
  • Permissions boundaries
  • Organizations SCPs
  • ACLs
  • Session policies.

Identity-based policies

Permissions policies that you attach to an IAM identity
Consists of effect, action, resource, condition
Identity-based policies can contain resource-level permissions that allow a user to access some resources.
Identity-based policies and resource-based policies are both permissions policies and are evaluated together.

Managed policies

Standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account
The same managed policy can be attached to multiple principal entities
AWS managed policies – Managed policies that are created and managed by AWS
Customer managed policies – Managed policies that you create and manage in your AWS account
When you change a customer managed policy, the changed policy doesn't overwrite the existing policy. Instead, IAM creates a new version of the managed policy. IAM stores up to five versions of your customer managed policies. You can use policy versions to revert a policy to an earlier version if you need.
AWS recommends user to use managed policies instead of inline policies.

Inline policies

Policies that you create and manage and that are embedded directly into a single user, group, or role
Inline policies maintain a strict one-to-one relationship between a policy and an identity. when you delete that identity, the policies embedded in the identity are deleted as well.

Resource-based policies

Permissions policies that you attach to a resource
Consists of effect, principal, and action
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, Trust policies define which principal entities (accounts, users, roles, and federated users) can assume the role.

Services that supports resource-based policies for granting principals in another AWS account who access to the resource:

• Amazon S3 bucket
• Amazon Glacier vaults
• Amazon SNS topics
• Amazon SQS queues

Permissions Boundary

A permissions boundary is an advanced feature that allows you to use AWS managed policies to limit the maximum permissions that an identity-based policy can grant to a user or role.

Organizations service control policy (SCP)

A Organizations SCP is a JSON policy that specify the maximum permissions for account members of an organization or organizational unit (OU).

Access Control List (ACL)

ACL controls which principals in other accounts can access the resource to which the ACL is attached.
The only policy type that does not use the JSON policy document structure.
ACLs are cross-account permissions policies that grant permissions to the specified principal. They cannot grant permissions to entities within the same account.

Session policies

Session policies limit the permissions that the role or user's identity-based policies grant to the created session.

Permissions Across Multiple Accounts

• AWS recommends to use AWS Organizations service to help you manage permissions across multiple accounts.
• You can specify an entire account or IAM entities in another account as the principal in a resource-based policy to enable cross-account access.
• You can also use IAM roles or access control lists (ACLs) for cross-account permissions.

Granting permissions for AWS Services

Typical services: Amazon EMR, Elastic Load Balancing, and Amazon EC2 Auto Scaling
You usually attach a role that defines what the service is allowed to do to the service.

Policy evaluation logic

Attribute-based access control (ABAC)

• ABAC is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags.
• Tags can be attached to the IAM resource, passed in the request, or attached to the principal that is making the request. An IAM user or role can be both a resource and principal.
• To control access based on tags, you provide tag information in the condition element of a policy to control the access of resource, request, principal, or any part of the authorization process.

Role-based access control (RBAC).

RBAC defines permissions based on a person's job function.
In IAM, you implement RBAC by creating different policies for different job functions. You then attach the policies with minimum permissions necessary to identities (IAM users, groups of users, or IAM roles.
The disadvantage to using the traditional RBAC model is that when employees add new resources, you must update policies to allow access to those resources.

ABAC VS RBAC

• ABAC permissions scale with innovation. It's no longer necessary for an administrator to update existing policies to allow access to new resources. Developer users can add access to new resources by themselves by adding tags to them.
• ABAC requires fewer policies. Because you don't have to create different policies for different job functions.
• Using ABAC, teams can change and grow quickly by creating/switching tags.
• Using traditional RBAC, you must write a policy that allows access to only specific resources. However, when you use ABAC, you can allow actions on all resources, but only if the resource tag matches the principal's tag.
• You can configure your SAML-based or web identity provider to pass session tags to AWS. When your employees federate into AWS, You can then use ABAC to allow or deny permissions based on those session tags as attributes.

AWS Security Token Service (AWS STS)

• Basis of roles and identity federation
• Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested.
• AWS STS is a global service with a single endpoint. However, you can also choose to make AWS STS API calls to endpoints in any other supported Region. This can:
  1. Reduce latency (server lag) by sending the requests to servers in a Region that is geographically closer to you.
  2. Build a redundancy to improve the availability of service. You can add code to your application that switches your AWS STS API calls to a different Region. This ensures that if the first Region stops responding, your application continues to operate.
  3. Ensures session tokens are valid in all AWS Regions. Session tokens from Regional AWS STS endpoints are valid in all AWS Regions. Session tokens from the global STS endpoint are valid only in AWS Regions that are enabled by default. If you choose to use the global endpoints, and intend to enable session tokens in a non-default Region, you need to change the Region compatibility of STS session tokens for the global endpoint.
• No matter which Region your credentials come from, they work globally.
• You must activate the Region in the account where the temporary credentials are generated. For example, when you use an account A to request STS API in Region region1 for creating temporary credentials for the role in account B, account B must activate region1 for STS, and account A can choose not to activate region1 for STS.

Advantages

1. You do not have to distribute or embed long-term AWS security credentials with an application.
2. You do not have to rotate them or explicitly revoke them when they're no longer needed.
3. You can provide access to your AWS resources to users without having to define an AWS identity for them.

Bearer tokens

Some AWS services require that you have permission to get an AWS STS service bearer token before you can access their resources programmatically.
When you perform AWS CLI or AWS API operations that require bearer tokens, the AWS service requests a bearer token on your behalf. The service respondes you with the bearer token, which you can then use to perform subsequent operations in that service.

Special API

• GetFederationToken federates an IAM users by
  1. Adding session policies to the user
  2. Adding the user in the Principal element in specific resource-based policies
• GetSessionToken brings MFA context in its credentials if the user is successfully authenticated with an MFA device. It can be used to prove that a user is authenticated by MFA.
• Specify federated-user or role in the Principal element of a policy enable denying access to temporary security credentials issued by user name/role .
• Specify aws:TokenIssueTime in the Condition element of a policy enable denying access to temporary security credentials issued before a specific time .

Access Analyzer

Access Analyzer analyzes only the resource-based policies that are applied to AWS resources in the Region where you enabled Access Analyzer.

Access Analyzer generates a finding when a resource-based policy allows access to a resource, even if the resource was not accessed by the external entity. Access Analyzer does not currently report findings from AWS service principals or internal service accounts.

Access Analyzer is built on Zelkova, which translates IAM policies into equivalent logical statements, and runs a suite of general-purpose and specialized logical solvers (satisfiability modulo theories) against the problem.

For customer privacy and security, Access Analyzer also does not consider the state of any external accounts when making its determination.

Access Analyzer in S3 buckets

Generates a finding when an Amazon S3 bucket policy, ACL, or access point applied to a bucket grants access to an external entity.
You can enable block public access settings on your bucket. It overrides the bucket policies that are applied to the bucket.
Access Analyzer analyzes block public access settings at the bucket level whenever a policy changes. However, it evaluates the block public access settings at the account level only once every 6 hours.

Access Analyzer in IAM roles

For IAM roles, Access Analyzer analyzes trust policies.

Access Analyzer in KMS keys

For AWS KMS customer master keys (CMKs), Access Analyzer analyzes the key policies and grants applied to a key. Access Analyzer generates a finding if a key policy or grant allows an external entity to access the key.

Access Analyzer in Lambda functions and layers

For AWS Lambda functions, Access Analyzer analyzes policies, including condition statements in a policy, that grant access to the function to an external entity.
Access Analyzer also analyzes permissions granted when using the AddPermission operation of the AWS Lambda API with an EventSource Token.

Access Analyzer in SQS queues

For Amazon SQS queues, Access Analyzer analyzes policies, including condition statements in a policy, that allow an external entity access to a queue.

Business use cases for IAM