IAM
Identity and Access Management
Last updated
Identity and Access Management
Last updated
Free global service.
Help you manage access to services, and resources.
IAM entities:
IAM Groups: contain users
IAM Users: a person, or service
IAM Federated users: Amazon, Facebook, Google, Twitter users.
IAM Roles:
temporary permission to interact with resources.
A role do not have long-term credentials.
It has 1-many relationship with users or applications.
Cross account access in different environment. Ex: Same user want to access both dev and prod environment. So by assume different role, that user can access prod without creating new identity.
JSON document used to define ALLOW/DENY permissions.
There are 3 types of policies: AWS managed, inline and Customer managed.
In JSON policy, a statement consist of EAR (basic structure)
Effect: ALLOW or DENY
Action: Get, Put, Write...
Resource
Principal: AWS account/user/role to which the policy apply to.
Conditional (optional): when this policy effect.
IAM policy example
Can you create a SQS queue?
No because there's an explicit deny.
Can you delete a SQS queue?
No because there's an explicit deny on top which precedes the allow.
Can you create an EC2 instance?
There's no explicit deny or allow. Since everything in AWS is deny by default so no.
Identity-based
Resource-based
Organization SCPs
Access control lists (ACLs)
If has 1 or more DENY, than the result is DENY
If nobody is ALLOW, then the result is also DENY.
When you assume role, you give up original permission of your principal and take the new ones given by the role.
When using resouce-based policy, you DON'T have to give up permission of your principal.
The maximum permission that you can grant to an IAM entity.
Quickly analyze thousands of resource policies
Continuously monitors and helps you refine permissions
Provides the highest levels of security assurance
identify which resources grant public or cross-account access.
Step1: Create an analyzer -> continuously scans the policies.
Step2: Review your findings
Step3: Take action: modify the policy.
List all your IAM users and status of their various credentials.
Grant permissions, create users, groups or roles in the tenant
Manage per-account access, or multi-account access (IAM Identity Center)
Verify right-size permission (least priviledge principle)
Control how user access AWS
Using SSL?
Which IP address?
Time of day
Authenticated user only
Multi-factor authentication device.
Integrate with corporate directory
Using temporary credentials
Use MFG
Rotate access keys
Don't user root account for anything except Billing
Use IAM Access Analyzer to generate least-privilege policies based on access activity
Regularly review and remove unused users, roles, permissions, policies, and credentials
Use permissions boundaries: set maximum permissions
IAM user and IAM group are for people. IAM Roles are for machines and services.
Groups cannot belong to other groups. NO nesting.
CANNOT add role to a group. Only users and services can assume a role to take on permissions.
IAM policy process in top-down order. If there a DENY above an ALLOW statement for the same permission, the ALLOW statement does not processed -> In IAM policies, an explicit "Deny" overrides an "Allow".
Add condition key aws:PrincipalOrgID to resource-based policy if you want to allow all AWS accounts from the organization to access that resource.
Apply
If you want to manage multiple AWS account, use (AWS SSO)
