Course PreviewAWS Identity and Access Management
AWS Identity and Access Management (IAM) controls who can do what across an AWS account. It defines users, roles, and policies that grant or deny specific API actions on specific resources, forming the authorization layer for every AWS service.
itCloud computing | OpenSkills.info
Intro
AWS Identity and Access Management
AWS Identity and Access Management, or IAM, controls access to AWS resources. It answers two separate questions. Authentication establishes who or what is making a request. Authorization decides whether that principal may perform the requested action.
IAM matters because almost every AWS operation is an API request. A console click, command-line call, software development kit call, and service-to-service operation eventually asks an AWS service to do something. IAM supplies identities and policies that help AWS decide whether to accept that request.
Use one request model throughout this course:
- A principal uses credentials to send a request.
- The request names an action and usually a resource.
- AWS builds a request context with details such as the principal, time, network path, tags, and requested Region.
- AWS finds every policy that applies to that context.
- AWS authorization logic returns allow or deny.
The model is compact. The policy combinations are not. A safe IAM design makes each layer's job explicit.
Identities and credentials
An AWS account begins with a root user. The root user has complete access to the account and can perform account-level tasks that other identities cannot. It is not an everyday administrator. Protect its sign-in and recovery paths, register multi-factor authentication, avoid root access keys, and use it only for tasks that require it.
An IAM user is an identity in one AWS account. It can have long-term credentials, including a console password or access keys. That persistence creates rotation, storage, removal, and exposure concerns. AWS recommends federation and temporary credentials for human users. IAM users remain appropriate for limited cases that cannot use federation or roles, including carefully controlled emergency access.
An IAM group collects IAM users so you can attach identity-based policies to the group. A group is not a principal. You cannot sign in as a group or name one as the principal in a resource-based policy.
An IAM role is an assumable identity with permission policies. It has no standard long-term password or access keys. A person, workload, AWS service, or principal in another account assumes the role and receives temporary credentials for a role session.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
Supports
- IAM controls authentication and authorization for AWS resources
- AWS evaluates permissions when a principal makes a request
- IAM is eventually consistent and policy changes can take time to propagate
- https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
Supports
- Human users should use federation and temporary credentials
- Workloads should use temporary credentials through IAM roles
- Least privilege, multi-factor authentication, conditions, Access Analyzer, credential review, and permission guardrails are recommended practices
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
Supports
- An IAM role is an assumable identity without standard long-term credentials
- Assuming a role produces temporary credentials for a role session
- Roles support delegation, cross-account access, workloads, and AWS services
- IAM users are reserved for use cases that federation and roles do not support
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html
Supports
- An IAM user group collects IAM users and can receive identity-based policies
- An IAM user group is not a principal and cannot be used as the Principal in a resource-based policy
- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
Supports
- AWS Security Token Service issues temporary security credentials
- Temporary credentials expire and support roles, federation, delegation, and cross-account access
- Temporary credentials avoid distributing long-term credentials to supported applications
- https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
Supports
- IAM Identity Center connects workforce users to AWS accounts and applications
- An organization instance centrally assigns workforce permissions across multiple AWS accounts
- IAM Identity Center can connect an external identity provider or manage users directly
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
Supports
- Policies define permissions and most use JSON documents
- Identity-based policies grant permissions to identities and resource-based policies grant permissions to named principals
- Permissions boundaries, session policies, SCPs, RCPs, and VPC endpoint policies have distinct limiting roles
- A role trust policy is a common resource-based policy
- https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html
Supports
- IAM policy statements use elements including Effect, Principal, Action, Resource, and Condition
- Policy element support varies by AWS service and action
- IAM and Access Analyzer provide policy validation capabilities
- https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html
Supports
- Policy conditions compare request-context keys with values using condition operators
- Context-key and operator support varies by service, action, resource, and data type
- https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
Supports
- Identity-based and resource-based policies can combine permissions for same-account requests
- Permissions boundaries and organization policies restrict effective permissions
- An explicit deny overrides an allow
- https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html
Supports
- Requests are implicitly denied unless the evaluation produces an allow
- Any applicable explicit deny produces a final denial
- Resource-based policy behavior depends on the exact principal type named in the policy
- Session policies and permissions boundaries participate in applicable request evaluation
- https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html
Supports
- Cross-account access requires authorization in both the trusted and trusting accounts
- A role trust policy permits external principals to assume the role
- The role permissions policy controls what resulting temporary credentials can access
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
Supports
- A permissions boundary caps permissions for an IAM user or role
- A permissions boundary does not grant permissions on its own
- Effective permissions depend on the intersection of grants and applicable limits
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
Supports
- SCPs limit maximum available permissions for IAM users and roles in member accounts
- SCPs do not grant permissions
- Identity policies cannot restore actions excluded by an applicable SCP
- https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
Supports
- Access Analyzer can analyze external, internal, and unused access
- Access Analyzer validates policies and supports custom policy checks
- Access Analyzer can generate policies from CloudTrail access activity
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html
Supports
- Access Analyzer generates policy templates from CloudTrail activity
- Policy generation has documented action-level and data-event coverage limits
- Generated policies require review and refinement
- https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
Supports
- The root user has complete account access and should be used only for required tasks
- Root credentials, account recovery mechanisms, and multi-factor authentication require protection
- AWS recommends avoiding root access keys and using temporary credentials for routine access
- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
Supports
- CloudTrail records actions by users, roles, and AWS services as events
- Events cover console, command-line, software development kit, and API activity
- Event history, trails, and CloudTrail Lake provide different recording and analysis paths
- https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html
Supports
- AWS publishes service-by-service actions, resource types, and condition keys for policy authoring
- Resource-level and condition-key support must be checked for the target service and action