Before start reading about the advanced IAM concepts, please go through this page
Web Identity Federation
Users access AWS resources after successful authentication with a web-based identity provider like Facebook, google. if the authentication is successful, users will get an authentication code from the web ID provider. Users can get temporary AWS security credentials & authorizing access to AWS resources using this authentication code.
Cognito
Cognito acts as an Identity Broker, handling all interactions with web identity providers. AWS recommends web identity federation for mobile applications.
Cognito User Pools
User directories are used to manage sign-up and sign-in functionality for mobile and web applications. It creates a Serverless database of users for web and mobile apps.
We can create our own user directories and set up all features like email & phone number verification, MFA, password reset, block users if credentials are compromised, federated identities(users from fb or google). It provides a simple login feature and that returns JWT token.
We can set up our client application. Once login is successful, the user will be redirected to the client application.
Cognito Identity pool
Provides temporary AWS credentials. Users will login & get token from Cognito User Pools or from Google or Facebook. Then, the token will be exchanged with Cognito Identity pool for temporary AWS credentials.
Cognito Identity pool will connect with STS & get the temporary credentials. Using that credentials, users can access AWS services like S3 or DynamoDB.
If you have a requirement to allow many users to access aws services/resources, you cannot create IAM users for every facebook/google users or for the users in Cognito User Pools.
STS – Security Token Service
Allows to grant limited and temporary access to AWS resources. Below are the APIs provided by STS,
AssumeRole: Assume roles within your account or cross-account.
AssumeRoleWithSAML: return credentials for users logged with SAML.
AssumeRoleWithWebIdentity: returns credentials for users logged with an Idp(Facebook login, Google login, OIDC compatible). Regular web application can use this API. AWS recommends Cognito Identity pool for mobile applications.
GetSessionToken: for MFA, from a user or AWS account root user.
GetFederationToken: Obtain temporary credentials for a federated user.
GetCallerIdentity: return details about the IAM user or role used in the API call.
DecodeAuthorizationMessage: decode error message when an AWS API is denied.
Amazon Cognito SDK
With the Amazon Cognito SDK, you just write a few lines of code to enable your users to sign-up and sign-in to your mobile and web apps.
Cross Account Access
Delegate access to resources in different aws accounts. For example, Production account have to access a resource from dev account and vice versa.
IAM:PassRole
We can pass a role to an EC2 instance, Lambda function, Code Pipeline to allow them to invoke other services. For this, we need the IAM permission iam:PassRole. To view the role being passed, we can user iam:GetRole.
We cannot pass any role to any service. Roles can be passed to what their trust allows. A trust policy for the role that allows the service to assume the role.
AWS Directoy services
AWS managed Microsoft AD : Allows us to create our own AD in AWS & manage users within AWS. It will also establish trust connection with on-prem AD. So user will be in both AWS managed AD & on-prem AD. It also supports MFA
Simple AD: User will only be on AWS. Cannot be connected/joined with on-prem AD.
AD Connector: It is just proxy to redirect to on-prem AD. User will be managed only on on-prem AD.
Inline vs Managed Policies
AWS recommends using managed policies over Inline policies.
Managed Policy
We can add up to 10 managed policies to a user, role, or group. The size of each managed policy cannot exceed 6,144 characters.
AWS Managed Policy: Created and Administered by AWS. Updated by AWS in case of new services / new APIs.
Customer Managed Policy: Create and Administered by us. We can attach this policy to multiple users, groups and roles within our own account. We can copy and customize AWS managed policy and use it.
Inline Policy
Strict to a one-to-one relationship between policy and entity. The policy is deleted if you delete the user, group or role in which the inline policy is embedded.
- User policy size cannot exceed 2,048 characters.
- Role policy size cannot exceed 10,240 characters.
- Group policy size cannot exceed 5,120 characters.
Dynamic Policies
If we want to create a folder(/home/${user}) for every user in the S3 bucket & make sure they cannot access other users folders, we don’t need to create one policy per user. If we start creating one policy for one user, we will have Scaling issues. Rather, we can create one dynamic policy using the special policy variable ${aws:username}
IAM Policies & S3 Bucket Policies
IAM Policies are attached to users, roles, groups. S3 Bucket Policies are attached to buckets. The union of its assigned IAM Policies & S3 Bucket Policies will be evaluated
- If IAM Role attached to EC2 instance, authorize RW to “my bucket” and no S3 Bucket Policy attached, then EC2 instance can read & write to S3 bucket
- If IAM Role attached to EC2 instance, authorize RW to “my bucket” and S3 Bucket Policy attached & has explicit deny to the IAM Role, then EC2 instance cannot read and write to “my_bucket”
- IAM Role attached to EC2 instance, no S3 bucket permissions and S3 Bucket Policy attached and has explicit RW allow to the IAM Role, then EC2 instance can read & write to S3 bucket
- IAM Role attached to EC2 instance, explicit deny S3 bucket permissions and S3 Bucket Policy attached and has explicit RW allow to the IAM Role, then EC2 instance cannot read and write to “my_bucket”
If there is an explicit DENY, end decision and DENY. If there is an explicit ALLOW, end decision and ALLOW. Else DENY.
Policy Types
A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. When you create a permissions policy to restrict access to a resource, you can choose an identity-based policy or a resource-based policy.
Identity-based policies: Attached to an IAM user, group, or role. These policies let you specify what that identity can do (its permissions)
Resource-based policies: Attached to a resource. we can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, VPC endpoints, and AWS Key Management Service encryption keys.
We can also read more about Permission boundaries, Organization SCPs (Service Control Policy), Access Control List(ACL), Session policies from the https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html