Gnu Group Learning AcademyGnu Group ↗
Cloud Infrastructure Fundamentals · Module 02 of 12

Identity and access management

Learn identities, roles, policies, temporary credentials, least privilege, MFA and why workloads should not embed long-lived cloud access keys.

Learning objectives

By the end of this module, you should be able to:

  • Explain authentication versus authorization.
  • Prefer roles and temporary credentials for workloads.
  • Read a least-privilege policy statement and identify risky wildcards.

Users, groups, roles and policies are different IAM building blocks

A user represents a person or long-lived principal when one is truly needed. Groups organize permissions for sets of users. Roles are assumable identities designed for temporary sessions, including workloads and federated users. Policies describe allowed or denied actions on resources.

For workloads, prefer workload identity or role assumption that yields temporary credentials instead of embedding static access keys.

Authentication answers who; authorization answers what

Cloud IAM separates identity proof from permission evaluation. Policies typically express effects, actions, resources and optional conditions. Deny statements and organization-level guardrails can constrain otherwise allowed actions.

Temporary credentials reduce long-lived secret exposure

Human access should generally use federation and MFA. Workloads should use service identities or roles that issue temporary credentials instead of embedding static access keys in code, images or configuration.

Least privilege is iterative

Start with the minimum permissions needed for a task, observe legitimate access, then remove broad wildcards. Scope resources and use conditions where supported.

Worked examples

See the idea in practice.

Narrow object-read policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": ["arn:aws:s3:::academy-lab/*"]
  }]
}
  • The action allows reads but not writes or bucket administration.
  • The resource scope is narrower than Resource:"*".
Core lab · Modes 1–2 · Concept + local simulation

Lab — Review an IAM policy

Goal: Use a local policy file to detect broad actions/resources and improve scope.

Before you start

  • No AWS credentials required.
STEP 1

Create an intentionally broad policy

cat > /tmp/policy.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:*","Resource":"*"}]}
EOF
STEP 2

Audit for wildcards

python3 - <<'PY'
import json
p=json.load(open('/tmp/policy.json'))
s=p['Statement'][0]
print('broad_action=', '*' in s['Action'])
print('broad_resource=', s['Resource']=='*')
PY
STEP 3

Write a narrower policy

cat > /tmp/policy-least-privilege.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:GetObject"],"Resource":["arn:aws:s3:::academy-lab/*"]}]}
EOF

Verify

  • The first policy is flagged as broad.
  • The replacement removes s3:* and Resource:"*".

Expected outcome

  • You can identify basic least-privilege problems before a policy reaches production.

Diagnose / troubleshoot

  • If the wildcard audit does not flag s3:*, inspect whether Action is a string or list before assuming the policy is narrow.
  • If a narrower policy breaks the workload, identify the exact denied action/resource from audit logs before re-adding broad permissions.
Real-world connection

Production IAM reviews combine policy analysis, access logs, federation, MFA and periodic removal of unused permissions.

Mode 3 · Optional AWS lab

Optional AWS — inspect the current identity

Observe the active AWS principal and attached identity context without changing IAM.

Resources created

  • None — this is a read-only inspection lab.

Estimated cost / risk

  • Expected incremental resource cost: none because the supplied commands are read-only.
  • Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

  • Optional sandbox AWS account and AWS CLI.
  • Use a least-privilege or federated identity; do not paste long-lived access keys into course files.
AWS 1
aws sts get-caller-identity
AWS 2
aws iam list-account-aliases --output table

Verify

  • The account and principal ARN are visible and recognized.
  • No AWS resources are created by the supplied commands.

Cleanup

  • No AWS cleanup is required because this lab creates no AWS resources.

Warnings

  • Optional only: not required for course completion or the main validator.
  • Do not create IAM users or access keys for this lab.
Avoid these traps

Common mistakes

  • Embedding access keys in source code.
  • Giving administrative permissions to a workload for convenience.
  • Confusing an IAM role with a permanent username/password identity.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Why prefer workload roles?

They provide scoped temporary credentials without distributing long-lived access keys.

2What does least privilege mean?

Grant only the permissions required for the legitimate task and scope them as narrowly as practical.

3What does MFA strengthen?

Authentication by requiring an additional factor beyond the primary credential.

4Scenario: a CI job currently stores a permanent access key in a repository secret. What is the preferred redesign?

Use workload federation or role assumption to obtain short-lived credentials scoped to the deployment job, rather than maintaining a long-lived cloud access key.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.