Chapter 3 — Cloud and container security: systems, data and dependencies
Lesson map
Lesson 03 published. Map, example, EX027.
flowchart TD
N0["Learning outcomes"]
N1["3.1 A simple policy"]
N2["3.2 Checking every item"]
N3["Lab — sharing check"]
N4["3.3 Reading the result"]
N5["3.4 Acting"]
N6["3.5 The booking container"]
N7["3.6 Agreement with the developer"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX027"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 A simple policy"]
N2["3.2 Checking every item"]
N3["Lab — sharing check"]
N4["3.3 Reading the result"]
N5["3.4 Acting"]
N6["3.5 The booking container"]
N7["3.6 Agreement with the developer"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]
[Learning outcomes]
|
v
[3.1 A simple policy]
|
v
[3.2 Checking every item]
|
v
[Lab — sharing check]
|
v
[3.3 Reading the result]
|
v
[3.4 Acting]
|
v
[3.5 The booking container]
|
v
[3.6 Agreement with the developer]
|
v
[Worked example] --> [Exercise EX027]
Learning outcomes
You will (1) list the clinic's data and where it is shared; (2) check sharing against a simple policy; (3) understand the booking container's dependencies.
3.1 A simple policy
Leila writes a one-line rule: sensitive items may be shared only with staff or administrators; non-sensitive items may also be public. Patient letters, referrals, invoices, backups and the booking app configuration count as sensitive.
The rule is short enough for any of the eight staff to apply without asking Leila. The list of sensitive items comes from what the clinic holds: treatment letters and referrals about patients, invoices with their details, backups that contain all of these, and the booking app configuration that holds a database password.
3.2 Checking every item
The April problem might not be the only one, so she checks every top-level item in storage against the rule.
A problem found by luck, through one patient's forwarded link, says nothing about what else is shared. The lab checks the sharing setting of all 8 top-level items against the rule. It looks only at what the provider's sharing report lists, so it touches no file and opens no link.
Its result found two items, invoices and old-backup.zip, that nobody had reported.
Lab — sharing check
"""List synthetic cloud storage items shared more widely than policy allows (stdlib only)."""
items = [("patient-letters/", "anyone-with-link", True), ("rota.xlsx", "staff", False), ("price-list.pdf", "public", False),
("referrals/", "staff", True), ("invoices/", "anyone-with-link", True), ("logo.png", "public", False),
("old-backup.zip", "anyone-with-link", True), ("booking-app-config", "admins", True)]
allowed = {True: {"staff", "admins"}, False: {"staff", "admins", "public"}}
bad = [(n, s) for n, s, sens in items if s not in allowed[sens]]
print(f"items {len(items)}, sensitive {sum(1 for i in items if i[2])}, shared too widely {len(bad)}")
for n, s in bad: print(f" {n}: {s}")
Run with python3 lab_sharing.py. Verified output:
items 8, sensitive 5, shared too widely 3
patient-letters/: anyone-with-link
invoices/: anyone-with-link
old-backup.zip: anyone-with-link
3.3 Reading the result
Of 8 items, 5 are sensitive and 3 are shared too widely: patient-letters (already fixed in chapter 1, still in the April export), invoices and old-backup.zip, all set to anyone-with-link.
The patient letters folder appears because the sharing report was exported before Leila changed it; that is the evidence copy, not a new problem. The two new findings matter: invoices hold patients' names and payment details, and old-backup.zip holds a full copy of data from the previous system. Both had been open to anyone with the link.
3.4 Acting
Invoices are set to staff-only. The old backup, from a previous system, is no longer needed; after checking with Mark and noting the clinic's retention rules, Leila deletes it. Fewer copies mean less to protect.
Leila records both changes in her decision log with their dates and reasons, and checks the activity log for each item before acting, as she did for the patient letters. The rota, price list and logo stay as they are: they are not sensitive, and the rule allows the price list and logo to be public.
3.5 The booking container
Leila asks the developer which base image the booking app uses and how often it is rebuilt. The answer is an older image last rebuilt a year ago. NIST SP 800-190 advises rebuilding images regularly from maintained bases and using trusted registries; Shu et al. (2017) found many public images carried known vulnerabilities.
A year without a rebuild means that fixes released for the base image in that time never reached the booking app. Leila does not need to read container files to act on this; she needs an agreement with the developer about how often images are rebuilt and how the clinic will know it happened.
3.6 Agreement with the developer
They agree on a monthly rebuild from a maintained base, with the developer sending a one-line confirmation each time.
The one-line confirmation turns the agreement into something Leila can check. The monthly routine includes "confirm the booking app image was rebuilt", and the confirmation email is the evidence. In June it was missing because the developer was on holiday, which is why they later agreed a backup contact.
Leila files each confirmation in the decision log, so a missing month is visible at a glance, as June's was.
3.7 Secrets
The booking app's configuration contains a database password. The developer moves it into the platform's secret settings, following the Kubernetes good-practice idea of keeping secrets out of images and files.
A password written in a configuration file travels with every copy of that file: into backups, into the developer's laptop and, in Oakfield's case, into a storage item that is now on the sensitive list. Moving it to the platform's secret settings means a leaked backup or image no longer reveals the database password. The developer also changes the password, because the old one may already have been copied.
Worked example
Leila asks whether the booking app must run on Kubernetes. The developer explains it runs on a simpler hosted platform, but the same ideas apply: trusted images, regular rebuilds, secrets kept separately and least privilege.
Synthetic case. Synthetic.
Errors and limits
A one-off check finds today's problems; only a routine finds tomorrow's.
Exercises
- EX027 — Policy rule. State Leila's sharing rule. Rubric: 3 = sensitive only staff/admins; non-sensitive may be public; 2 = partial; 1 = vague; 0 = none.
- EX028 — Lab result. Which items were shared too widely? Rubric: 3 = patient-letters, invoices, old-backup; 2 = two; 1 = one; 0 = none.
- EX029 — Sensitive count. How many items were sensitive? Rubric: 3 = 5; 2 = partial; 1 = vague; 0 = none.
- EX030 — Backup decision. What was done with the old backup and why? Rubric: 3 = deleted after checking retention; fewer copies; 2 = partial; 1 = vague; 0 = none.
- EX031 — Image age. What did the developer reveal about the image? Rubric: 3 = old, rebuilt a year ago; 2 = partial; 1 = vague; 0 = none.
- EX032 — Rebuild agreement. What rebuild schedule was agreed? Rubric: 3 = monthly with confirmation; 2 = partial; 1 = vague; 0 = none.
- EX033 — Password move. Where did the database password go? Rubric: 3 = platform secret settings; 2 = partial; 1 = vague; 0 = none.
- EX034 — Public images. What did Shu et al. (2017) find? Rubric: 3 = many public images had known vulnerabilities; 2 = partial; 1 = vague; 0 = none.
- EX035 — Platform question. Do the ideas apply without Kubernetes? Rubric: 3 = yes: images, rebuilds, secrets, least privilege; 2 = partial; 1 = vague; 0 = none.
- EX036 — Why check all. Why check every item, not just the reported folder? Rubric: 3 = other problems may exist; 2 = partial; 1 = vague; 0 = none.
- EX037 — One-off limit. What can a one-off check not do? Rubric: 3 = find future problems; 2 = partial; 1 = vague; 0 = none.
- EX038 — Container guidance. Which NIST publication covers container images? Rubric: 3 = SP 800-190; 2 = partial; 1 = vague; 0 = none.
Synthesis
Check every item against a simple rule and agree how dependencies stay current.
Continue studying — chapter 03 of 04
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →