Chapter 10 — Cloud and container security: quality and troubleshooting
Lesson map
Lesson 10 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Quality checks"]
N2["10.2 Breakage"]
N3["10.3 Root cause"]
N4["10.4 Workflow improvements"]
N5["10.5 Measures"]
N6["Independent review value"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Quality checks"]
N2["10.2 Breakage"]
N3["10.3 Root cause"]
N4["10.4 Workflow improvements"]
N5["10.5 Measures"]
N6["Independent review value"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[10.1 Quality checks]
|
v
[10.2 Breakage]
|
v
[10.3 Root cause]
|
v
[10.4 Workflow improvements]
|
v
[10.5 Measures]
|
v
[Independent review value]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) check the quality of security work; (2) troubleshoot problems after changes; (3) improve the workflow.
10.1 Quality checks
Hannah asks a colleague to repeat her role analysis on one role from raw exports. Their results match. Repeating the analysis from raw exports tests both Hannah's method and her work. If a colleague following the method note reaches the same result, the method can be applied by others. The colleague chose the reporting role and checked which permissions appeared in the usage logs. Hannah records the check, the role chosen and the result in her portfolio. Dev signs the record as reviewer, which gives Kingsbridge assessors independent evidence that the method note is usable by someone else. A colleague repeats one analysis every quarter to keep the method honest.
10.2 Breakage
After removing storage.admin, the worker fails to set an object's metadata. The error shows it needs a narrower metadata permission, which is added. The failure happened in staging, as planned, so the service was not affected. Rather than restoring storage.admin, Hannah and the digital team find the specific permission needed and add only that, keeping the role narrow. The change is recorded and the staging test repeated before production. Hannah adds the failure and its fix to the evidence register, so audit sees the full history of the change. For a week after each change, error rates and failed requests are checked daily to catch slower problems, such as a job that runs weekly.
10.3 Root cause
The usage log had recorded the action under a different name; Hannah updates her method to map action names carefully. The worker had been using the metadata action all along, but the log recorded it under a name that did not match the permission, so it looked unused. Hannah adds a mapping step to her method note: for each permission, list the action names that may appear in logs. She also rechecks the other removals with the new mapping and finds no further mismatches. She describes the missed mapping in her Kingsbridge reflection as the main technical lesson of the project.
10.4 Workflow improvements
Scan triage now takes 15 minutes weekly; role reviews take an hour quarterly. Fifteen minutes a week is enough because the scanner tiers findings automatically and the digital team only needs to check new tier 1 and 2 findings. An hour a quarter for role reviews works because the core roles are now narrow and the analysis method is written down. Hannah records these times so Dev can plan the work. Keeping both routines short makes it more likely they continue after the project. Each problem and fix goes into a lessons log shared with the platform team.
10.5 Measures
Unused permissions fell from 6 of 13 to 0 in the core roles; tier 1 findings were fixed in three days. Hannah reports these figures with their sources: the new role exports for permissions and the deployment records for the tier 1 fix. She states that the figures cover the three core roles and the three images in scope, not the council's other cloud services. The open reporting rebuild is reported with its exception rather than left out of the figures. Dev checks the figures against the new role exports and scan results before they go to audit. Triage time fell from an unplanned afternoon to fifteen minutes, freeing developer time.
Independent review value
The colleague's repetition found no errors in results, but found that one step in Hannah's notes was unclear: how she excluded the yearly archive job. She rewrites the step. Independent repetition tests both results and method description.
After the breakage, Hannah adds a rule to her method: before removing a broad permission, list the specific actions recorded under it and check for narrower equivalents.
Worked example
The digital team suggests adding the triage output to their sprint board directly. Hannah agrees; findings now appear where developers already work.
Synthetic case. Synthetic.
Errors and limits
Repeated checks by another person catch errors the author cannot see.
Exercises
- EX046 — Quality check. How was the role analysis quality-checked? Rubric: 3 = colleague repeated one role from raw exports; 2 = partial; 1 = vague; 0 = none.
- EX047 — Breakage fix. What fixed the worker failure? Rubric: 3 = narrow metadata permission; 2 = partial; 1 = vague; 0 = none.
- EX048 — Method lesson. What did the breakage teach? Rubric: 3 = map action names carefully; 2 = partial; 1 = vague; 0 = none.
- EX049 — Measures. Give two improvement measures. Rubric: 3 = unused 6/13→0; tier 1 fixed in 3 days; 2 = partial; 1 = vague; 0 = none.
- EX050 — Sprint board. Why put triage on the sprint board? Rubric: 3 = where developers work; 2 = partial; 1 = vague; 0 = none.
Synthesis
Check work independently and improve the workflow from experience.
Continue studying — chapter 10 of 12
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →