IAM: Identity and Access Management
If you are studying for AWS Solutions Architect Professional Exam, this guide will help you with quick revision before the exam. it can use as study notes for your preparation.
Dashboard Other Certification NotesIAM: Identity and Access Management
- When accessing AWS, the root account should never be used. Users must be created with the proper permissions. IAM is central to AWS
- Users: A physical person
- Groups: Functions (admin, devops) Teams (engineering, design) which contain a group of users
- Roles: Internal usage within AWS resources
- Cross Account Roles: roles used to assumed by another AWS account in order to have access to some resources in our account
- Policies (JSON documents): Defines what each of the above can and cannot do. Note: IAM has predefined managed policies
- There are 3 types of policies:
- AWS Managed
- Customer Managed
- Inline Policies
- There are 3 types of policies:
- Resource Based Policies: policies attached to AWS services such as S3, SQS
Policies
- IAM policies define permissions for an action regardless of the method that you use to perform the operation.
Policy types
- Identity-based policies: attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity
- Resource-based policies: attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to a principal entity that is specified in the policy. Principals can be in the same account as the resource or in other accounts
- Permissions boundaries: use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity
- Organizations SCPs: use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions
- Access control lists (ACLs): use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are 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 entity. ACLs cannot grant permissions to entities within the same account
- Session policies: pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user’s identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see Session Policies
Policies Deep Dive
- Anatomy of a policy: JSON document with
Effect
,Action
,Resource
,Conditions
andPolicy Variables
- An explicit
DENY
has precedence overALLOW
- Best practice: use least privilege for maximum security
- Access Advisor: a tool for seeing permissions granted and when last accessed
- Access Analyzer: used of analyze resources shared with external entities
- Common Managed Policies:
AdministratorAccess
PowerUserAccess
: does not allow anything regarding to IAM, organizations and account (with some exceptions), otherwise similar to admin access
-
IAM policy condition:
"Condition": { "{condition-operator}": { "{condition-key}": "{condition-value}" } }
- Operators:
- String:
StringEquals
,StringNotEquals
,StringLike
, etc. - Numeric:
NumericEquals
,NumericNotEquals
,NumericLessThan
, etc. - Date:
DateEquals
,DateNotEquals
,DateLessThan
, etc. - Boolean
- IpAddress/NotIpAddress:
"Condition": {"IpAddress": {"aws:SourceIp": "192.168.0.1/16"}}
- ArnEquals/ArnLike
- Null
"Condition": {"Null": {"aws:TokenIssueTime": "192.168.0.1/16"}}
- String:
- Policy Variables and Tags:
${aws:username}
: example"Resource:["arn:aws:s3:::mybucket/${aws:username}/*"]
- AWS Specific:
aws:CurrentTime
aws:TokenIssueTime
aws:PrincipalType
: indicates if the principal is an account, user, federated or assumed roleaws:SecureTransport
aws:SourceIp
aws:UserId
- Service Specific:
ec2:SourceInstanceARN
s3:prefix
s3:max-keys
sns:EndPoint
sns:Protocol
- Tag Based:
iam:ResourceTag/key-name
iam:PrincipalTag/key-name
Policy Evaluation Logic
- Components involved in a policy evaluations:
- Organization SCPs
- Resource Policies
- IAM Identity Boundaries
- Session Policies
- Identity Policies
- Policy evaluation logic - same account:
- Policy evaluation logic - different account:
AWS Policy Simulator
- When creating new custom policies you can test it here:
- https://policysim.aws.amazon.com/home/index.jsp
- This policy tool can you save you time in case your custom policy statement’s permission is denied
- Alternatively, you can use the CLI:
- Some AWS CLI commands (not all) contain
--dry-run
option to simulate API calls. This can be used to test permissions. - If the command is successful, you’ll get the message:
Request would have succeeded, but DryRun flag is set
- Otherwise, you’ll be getting the message:
An error occurred (UnauthorizedOperation) when calling the {policy_name} operation
- Some AWS CLI commands (not all) contain
IAM Roles vs Resource Based Policies
- When we assume a role (user, application or service), we give up our original permission and take the permission assigned to the role
- When using a resource based policy, principal does not have to give up any permissions
- Example: user in account A needs to scan a DynamoDB table in account A and dump it in an S3 bucket in account B. In this case if we assume a role in account B, we wont be able to scan the table in account A
Best practices
- One IAM User per person ONLY
- One IAM Role per Application
- IAM credentials should NEVER be shared
- Never write IAM credentials in your code. EVER
- Never use the ROOT account except for initial setup
- It’s best to give users the minimal amount of permissions to perform their job