IAM Basics
IAM basics literacy names users, groups, roles, policies, and trust — read identity structure on YOUR $CLOUD_LAB AWS sandbox before live console changes.
Visual · t31_iam_basics
IAM basics literacy. $CLOUD_LAB only. Original Cyberlium.
Every API call has an identity story — literacy reads who can do what on accounts you own, not stranger accounts with leaked keys.
AWS IAM defines principals (users, roles, federated identities), policies (allow/deny actions on resources), groups for bulk assignment, and trust policies for role assumption. Root account, access keys, and overly broad AdministratorAccess drive most identity incidents — literacy names the objects before hardening. Cyberlium maps IAM basics on YOUR $CLOUD_LAB AWS account — document fictional role names and policy summaries on paper. Next: Least Privilege.
1. IAM objects (named)
User: long-lived principal — avoid where roles suffice. Role: temporary credentials via trust policy and STS. Group: policy container for teams. Policy: JSON allow/deny on actions and resources. Trust policy: who can assume a role.
On $CLOUD_LAB, sketch one user, one role, and one group with plain-language purpose for lab fictional app.
Command guide
Try these commands — IAM objects (named)
═══ DOCKER & CONTAINER AUDIT ═══
Check container running state and port bindings
Command — copy this
docker ps --format "table {{.ID}} {{.Image}} {{.Status}} {{.Ports}}" 2>/dev/null || echo "docker ps"Inspect container for elevated capabilities and root user
Command — copy this
docker inspect --format '{{json .HostConfig.Privileged}}' <container_id> 2>/dev/null || trueRun security vulnerability scan on container image using Trivy
Command — copy this
trivy image --severity HIGH,CRITICAL alpine:3.19 2>/dev/null || echo "trivy image alpine:3.19"
═══ KUBERNETES RBAC AUDIT ═══ Check current permissions in namespace
Command — copy this
kubectl auth can-i --list 2>/dev/null || echo "kubectl auth can-i"
Primary tools to practice this lesson: curl, grep. Reference sites: AWS IAM (https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html); IAM best practices (https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html); NIST AC-6 (https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Why IAM literacy precedes hardening
CSPM and GuardDuty findings cite iam:CreateUser or sts:AssumeRole — analysts who cannot read policy JSON mis-triage. Least privilege starts with naming current grants before trimming.
Students inventory IAM on personal sandbox — never import stranger account policy exports without scope.
3. Lab boundary
Forbidden: attaching AdministratorAccess to lab user 'because it is easier' on shared credentials. Allowed: IAM basics card — four objects defined with $CLOUD_LAB fictional principal names.
Ship: IAM basics card for YOUR sandbox. Next: Least Privilege.
4. What you ship: IAM basics card for $CLOUD_LAB
User, role, group, policy definitions with lab examples. $CLOUD_LAB named. chmod 600.
5. What you record before the next lesson
Date. IAM basics card. $CLOUD_LAB named. File t31-m03-l01-iam-basics.txt chmod 600.
6. Wrong vs right: stranger tenants vs YOUR cloud accounts
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
- Wrong: Use root for daily CLI. Copy stranger account policy without scope.
- Right: Write IAM basics card for YOUR $CLOUD_LAB AWS sandbox. Next: Least Privilege.
Mission: map IAM objects on YOUR lab account
1) Name user, role, group, policy in one sentence each. 2) Sketch trust relationship for one lab role. 3) Note why root should stay idle. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Roles beat long-lived users — literacy first, then least privilege trim.
APPLY: IAM on Cyberlium is practiced as:
APPLY: True or False: Trust policies define who can assume an IAM role.
APPLY: IAM basics literacy avoids: