Chapter 22 — Cloud and container security: data and dependencies
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Image dependencies"]
N2["22.2 Base images"]
N3["22.3 Inventories"]
N4["22.4 Third-party images"]
N5["22.5 Managed service dependencies"]
N6["22.6 Update plan"]
N7["22.7 Removing dependencies"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Image dependencies"]
N2["22.2 Base images"]
N3["22.3 Inventories"]
N4["22.4 Third-party images"]
N5["22.5 Managed service dependencies"]
N6["22.6 Update plan"]
N7["22.7 Removing dependencies"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Image dependencies]
|
v
[22.2 Base images]
|
v
[22.3 Inventories]
|
v
[22.4 Third-party images]
|
v
[22.5 Managed service dependencies]
|
v
[22.6 Update plan]
|
v
[22.7 Removing dependencies]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) track images, base layers and library dependencies; (2) understand supply chain risk for containers; (3) manage third-party services; (4) plan updates.
22.1 Image dependencies
Each image depends on a base image, operating system packages and application libraries. A vulnerability in any of them is a vulnerability in the image.
records-api, for instance, builds on the shared Python base, which itself builds on a minimal operating system image, and adds about forty libraries from the package index. A flaw in any of those layers is shipped with records-api whether or not its own code uses the affected feature. Samuel's research study showed how much the choice of base alone changes the number of high-severity findings an image carries.
22.2 Base images
A shared, regularly rebuilt base image (chapter 18) reduces vulnerabilities and gives one place to apply fixes.
When an operating system package needs patching, the cloud team updates the shared base once, and every image built on it picks up the fix at its next rebuild. With many different public bases, the same fix would need to be found and applied separately in each. The pipeline check from the research chapter keeps teams on the approved base, and exceptions are recorded with a reason and an owner.
22.3 Inventories
A software bill of materials lists components in each image, so Westmere can answer "which images contain this library?" quickly when an advisory appears.
Without an inventory, answering that question means unpacking and searching every image by hand, which took the team about a week when they estimated it for the compression-library advisory. With one, a search returns the list in minutes. Inventories also help in the other direction: they show which images carry a library nobody remembers adding. Each list is tied to an image digest.
22.4 Third-party images
Images from public registries are mirrored into Westmere's registry after checking their digest and scanning them; the cluster runs only images from the internal registry.
Mirroring gives Westmere a copy it controls, so an upstream image being changed or removed cannot alter what StudyHub runs. Checking the digest confirms the mirrored copy matches what was reviewed, and scanning catches known vulnerabilities before the image is admitted. The admission control that accepts only internal images enforces this rule at deployment time.
22.5 Managed service dependencies
StudyHub depends on the managed database, identity provider and storage. Their availability and security notices are monitored.
A notice from the provider about a database vulnerability or an identity provider change can affect StudyHub even though Westmere does not run those services. The cloud team subscribes to the provider's notices and records which StudyHub components each one affects. Outages are tracked too, since availability is part of security. For each managed service, Samuel's dependency table records the provider's status page, the notice channel and the StudyHub components that would be affected by an outage or a security change, so the team can judge quickly whether a notice needs action.
22.6 Update plan
Base images rebuild weekly; application images rebuild when their base changes; critical advisories trigger immediate rebuilds.
The schedule balances speed and stability. Weekly rebuilds keep images current without surprise; rebuilding application images when the base changes means patches propagate within days; critical advisories skip the queue. Every rebuild passes through the test cluster first, so even an urgent fix is tested before it reaches students. Samuel's checker reports any running image whose base is more than two weekly rebuilds behind the current one. That turns the plan into something measurable, and the weekly report shows how many images are current.
22.7 Removing dependencies
Unused libraries and services are removed to shrink what must be tracked.
Each library removed is one fewer item to watch for advisories and one fewer path for a vulnerability. When Samuel compared records-api's inventory with its imports, he found several libraries from an old feature that no longer existed. Removing them shrank the image and removed two known vulnerabilities at once. Unused managed services are treated the same way: an old queue that nothing published to was deleted after a month of empty logs and a confirmation from its owner. Every removal is recorded in the inventory history.
Generating inventories
The build pipeline generates a component list for every image automatically and stores it with the image digest in the registry. A small script searches all lists for a given library name and version. Samuel tests the script against a synthetic advisory before relying on it, and checks that images built before the pipeline change are rebuilt so they also have lists.
Worked example
An advisory for a widely used compression library arrives. Using the inventory, Samuel finds it in 7 images within minutes; all are rebuilt from the patched base and deployed within two days. Without the inventory, the team estimates it would have taken a week to find them.
Synthetic case. Images and advisories are synthetic.
Errors and limits
Inventories must be generated automatically or they go stale.
Exercises
- EX064 — Image dependencies. What does an image depend on? Rubric: 3 = base image, OS packages, libraries; 2 = two; 1 = one; 0 = none.
- EX065 — Third-party images. How are third-party images handled? Rubric: 3 = mirrored, digest-checked, scanned; 2 = partial; 1 = vague; 0 = none.
- EX066 — Advisory response. How quickly were affected images found? Rubric: 3 = minutes via inventory; 7 images; 2 = partial; 1 = vague; 0 = none.
Synthesis
Track what goes into images so fixes reach every one.
Continue studying — chapter 22 of 40
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →