PolarSPARC |
AWS Identity and Access Management (IAM) - Quick Notes
Bhaskar S | 12/25/2023 |
AWS Identity and Access Management
AWS Identity and Access Management, also referred to as IAM, allows a customer to control who is authenticated (identity) and who is authorized (has access) to use resources.
The following is the summary of the various features/capabilities of IAM:
Has a Global scope
The first user created when an AWS account is created is Root user
The root user has complete access to all AWS services and resources
Users are people within an AWS account
One can create upto 5000 users and by default they have NO permissions
A Group is a way of organizing users
Groups can only contain users and NOT other groups
A User can be a member of up to 10 Groups
A user DOES NOT have to belong to any group
A Role is an identity that has specific permissions that can be attached to resources
An Entity (or an Identity) can be a user, a group, or a role
A Amazon Resouce Name (ARN for short) is a name that uniquely identify AWS resources
A Policy is a JSON document that allows one to define Permissions that explicitly allow or deny access to AWS resources
A policy provides fine-grained access control to specific API requests for the AWS resources the policy applies to
A policy document contains of the following elements:
Version number
Policy Id (optional)
A List of Statements
A policy statement consists of the following elements:
Statement Id (optional)
Effect - Must be either "Allow" or "Deny"
Principal - Must be the ARN of an identity (user, role, resource)
Action - A list of resource API requests
Resource - A list of resource ARNs to which the Actions apply
Condition (optional) - The rules under which the policy takes effect
The following some commonly used conditions:
aws:SourceIp - Restricts client IP from which requests can be made
"Condition": { "NotIpAddress": { "aws:SourceIp": ["192.168.1.0/24", "10.0.1.0/24"] } }
aws:RequestedRegion - Restricts the Region the requests are made to
"Condition": { "StringEquals": { "aws:RequestedRegion": ["us-east-1", "us-central-2"] } }
aws:ResourceTag - Restricts based on tags
"Condition": { "StringEquals": { "ec2:ResourceTag/Project": "Analytics", "aws:PrincipalTag/Department": "OU-Data" } }
aws:MultiFactorAuthPresent - Forces Multi Factor Authentication (MFA)
"Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } }
The following is an example policy:
{ "Version": "2023-12-23", "Id": "Policy123", "Statement": [ { "Sid": "Stmt1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::515151515151:user/Alice" }, "Action": "s3:*", "Resource": "arn:aws:s3:::images" } ] }
A policy attached to a user directly is referred to as an Inline policy
Policies are primarily of two types - Identity-based policy OR Resource-based policy
An Identity-based policy can be applied to users, groups, or roles
A Resource-based policy can be applied to various AWS resources or services (Ex: S3 Bucket Policy, SQS Access Policy)
A Trust Policy is a type of resource-based policy (also referred to as Trust Relationship Policy) that defines the trusted entities that can assume the role to get the allowed permissions
Policies can be either AWS managed or customer managed
AWS managed policies CANNOT be modified by a customer
Roles are used for delegation and are assumed by users OR services
When an identity assumes a role, it gives up its original permissions and take the permissions granted by that role
With Resource-based policies, the identity making the request does not give up its original permissions
Some AWS services will need to perform actions on behalf of a user. This means we need to assign permissions to those AWS services using roles (Ex: EC2 Instance accessing an S3 bucket)
By default, all requests are implicitly DENIED, except for the root user
An explicit Deny in any policy will always take precedence and override any Allow
An explicit Allow in identity-based policies OR resource-based policies overrides the default
A Permissions Boundary is a type of policy that sets the maximum permissions that an identity (users OR roles and NOT groups) can be granted
Permissions Boundary DOES NOT explicitly grant permissions, but sets a clear boundary to ensure the policy only grants the required privileges to AWS resources
A Session Policy is similar to a Permissions Boundary and limits the permissions that an identity-based policy (or a resource-based policy) grants to a particular session
IAM Credentials Report is an account-level report that lists all the user accounts and the status of their credentials
IAM Access Advisor is an user-level report that shows the service permissions granted to a user and when those services were last accessed
AWS Organizations
AWS Organizations is an account management service that enables one to consolidate multiple AWS accounts into an organization for better account and billing management to meet the budgetary, security, and compliance needs of a business.
The following is the summary of the various features/capabilities of Organizations:
Is global service
The topmost organization is called the Root Organization
An organization can have other organizations underneath it
The main account is called the Management Account, which has full admin power, while the other accounts are referred to as the Member Accounts
Each member account can only belong to one organization
Enables one to automate the creation of member accounts programmatically
Allows a customer to get volume discounts from AWS for some services that have a tiered pricing (Ex: EC2)
Allows one to enable CloudTrail at the managementment account and it will automatically apply to all member accounts
Allows one to establish and manage cross account roles
Service Control Policies (SCP for short) are policies that can be attached to specific organizations or accounts to control maximum permissions granted to users and roles
SCPs DO NOT apply to the management account under a root organization
SCPs must include explicit Allow to grant permission
AWS Policy Evaluation
The following flowchart shows the AWS policy evaluation:
The following is the summary of the evaluation logic for policies in an account:
By default, all requests are implicitly denied with the exception for the root user
By default, all Statements in the policies are logically ORed before the evaluation
An explicit Allow in an identity-based or resource-based policy overrides the default
If a permissions boundary, organizations SCP, or session policy is present, it might override the Allow with an implicit Deny
An explicit Deny in any policy overrides any Allow
When there are conflicts in the policy, the outcome is a Deny
References