Identity and Access Management (RAM)
Core concepts
RAM manages identities and permissions. Users are long-term identities (people or apps) with credentials; groups bundle users for policy attachment; roles are assumable identities without permanent credentials, used for cross-account access and service delegation (e.g., ECS instances assuming a role via instance metadata). Policies are JSON documents granting or denying actions on resources; they attach to users, groups, or roles.
Key ideas: principal, action, resource, condition, and effect. STS (Security Token Service) issues temporary credentials for roles. MFA strengthens user login. The primary account (root) should be locked down and not used for daily work.
Traps in questions
- User vs. role: applications on ECS should assume a role, not embed a user's AccessKey.
- Explicit deny wins: a deny in any attached policy overrides allows.
- Policy attachment scope: attaching to a group grants all members; attaching to a user affects only that user.
- Temporary credentials: STS tokens expire; code must refresh them.
- Root account: avoid using it; enable MFA and create RAM users instead.
Rule of thumb
Prefer roles over long-term AccessKeys, and grant the minimum actions on the narrowest resources. If a question shows an AccessKey hardcoded in an application, the correct answer is usually to replace it with a role.
Worked example
An ECS-hosted app must read one OSS bucket. Create a RAM role with a policy allowing oss:GetObject on that bucket only, attach the role to the instance, and let the app fetch temporary credentials from instance metadata. A RAM user with oss:* on * violates least privilege.