Chapter 13 — Identity and access
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Human identities"]
N2["13.2 Service identities"]
N3["Lab — Lab — account review"]
N4["13.3 Lab result"]
N5["13.4 Stale access"]
N6["13.5 Keys"]
N7["13.6 Reviews"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Human identities"]
N2["13.2 Service identities"]
N3["Lab — Lab — account review"]
N4["13.3 Lab result"]
N5["13.4 Stale access"]
N6["13.5 Keys"]
N7["13.6 Reviews"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Human identities]
|
v
[13.2 Service identities]
|
v
[Lab — Lab — account review]
|
v
[13.3 Lab result]
|
v
[13.4 Stale access]
|
v
[13.5 Keys]
|
v
[13.6 Reviews]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) review cloud user accounts and keys; (2) enforce multi-factor authentication; (3) remove stale access; (4) prefer federated and short-lived identities.
13.1 Human identities
Staff sign in through the university's identity provider with multi-factor authentication. Separate cloud console users should not exist except for documented break-glass accounts.
Federation through the identity provider means that when someone leaves Westmere, disabling their university account also removes cloud access. Separate console users break that link, which is how old-contractor survived long after the contract ended. Break-glass accounts are the only exception, because they must work when the identity provider does not. Samuel's checker lists every console user and flags any that are not break-glass accounts.
13.2 Service identities
Services should use workload identity or managed identities that issue short-lived credentials, not long-lived access keys.
svc-backup's 610-day-old key shows the problem with long-lived keys: it could have been copied at any point in that time and would still work. A managed identity issues credentials that last minutes and are tied to the running workload, so there is nothing durable to steal. The opening case's connection string had the same weakness. StudyHub's pods now use workload identity, so each service receives credentials for its own role only, which expire automatically and never appear in images or configuration files.
Lab — Lab — account review
"""Review synthetic cloud console users: MFA, key age and last sign-in (stdlib only)."""
users = [("c.jensen", True, None, 2), ("t.becker", True, 45, 1), ("svc-backup", False, 610, None),
("old-contractor", False, 400, 220), ("s.osei", True, None, 5)]
for u, mfa, key_age, last in users:
f = []
if last is not None and not mfa: f.append("console user without MFA")
if key_age and key_age > 90: f.append(f"access key {key_age} d old")
if last and last > 90: f.append(f"inactive {last} d")
print(f"{u:15} {'; '.join(f) or 'ok'}")
Run with python3 lab_mfa.py. Verified output:
c.jensen ok
t.becker ok
svc-backup access key 610 d old
old-contractor console user without MFA; access key 400 d old; inactive 220 d
s.osei ok
13.3 Lab result
c.jensen, t.becker and s.osei are ok. svc-backup has an access key 610 days old. old-contractor is a console user without MFA, with a 400-day-old key, inactive for 220 days. old-contractor should be removed; svc-backup should move to a managed identity.
Each finding has a different remedy. old-contractor has no reason to exist, so it is removed after checking for dependencies. svc-backup does needed work, so it is moved to a managed identity rather than deleted. The ok results confirm that the checks do not flag every account.
13.4 Stale access
Accounts inactive for 90 days are disabled after confirming with owners. Leavers' access is removed through the identity provider, which removes cloud access too when federation is used.
Confirming with owners first matters because an inactive account may still run something, as old-contractor's hidden report showed. Disabling before deleting gives a chance to notice failures and reverse the change. Federated leavers lose access automatically, which removes the most common route to stale accounts. Disabled accounts are deleted after a further thirty days if nothing has broken, and the decision is recorded in the access review.
13.5 Keys
Keys older than 90 days are rotated or, better, replaced by short-lived credentials.
Rotation limits how long a stolen key works but still leaves a key to steal. For svc-backup, Samuel's recommendation was replacement rather than rotation, since the backup job runs inside the cloud and can use a managed identity. Keys remain only where an outside system cannot use federation, and each is listed with its owner. Samuel's checker reports any key older than ninety days, with its owner, so rotation is prompted rather than remembered. Each remaining key also has a documented reason.
13.6 Reviews
Quarterly access reviews list who has which roles; owners confirm each.
Owners confirm each role or mark it for removal. A review that only lists access without asking owners to act becomes a report nobody reads. Samuel's checker prepares the list from exports, so reviewers spend their time deciding rather than gathering data, and the decisions are recorded with dates. Roles that no owner claims are removed after notice. The first quarterly review removed several roles left from finished projects, and the review record now shows the trend in unclaimed roles from one quarter to the next, which helps the team see whether access is being kept tidy between reviews.
Break-glass accounts
Two break-glass accounts exist for emergencies when the identity provider is unavailable. Their credentials are sealed, use hardware MFA, and any sign-in raises an immediate alert to the security team. They are tested twice a year. The access review checks they have not been used outside tests, and each test is recorded with who performed it and why.
Role design
Roles are designed per task, such as read-only support, deployer and database administrator, and reviewed when tasks change.
Worked example
Removing old-contractor reveals that a scheduled report used that account's key. The report is moved to a service identity with read-only access to one bucket, and the account is deleted. The incident shows why personal accounts must never run automation.
Synthetic case. Accounts are synthetic.
Errors and limits
Disabling accounts can break hidden dependencies; disable before deleting and watch for failures.
Exercises
- EX037 — Lab findings. What did the lab find for old-contractor? Rubric: 3 = no MFA, 400 d key, inactive 220 d; 2 = two; 1 = one; 0 = none.
- EX038 — svc-backup. What should happen to svc-backup? Rubric: 3 = move to managed identity; 2 = partial; 1 = vague; 0 = none.
- EX039 — Hidden dependency. What hidden dependency was found? Rubric: 3 = scheduled report used contractor key; 2 = partial; 1 = vague; 0 = none.
Synthesis
Federated, short-lived identities and regular reviews keep access tidy.
Continue studying — chapter 13 of 40
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →