Chapter 15 — Cloud and container security: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 The missing service"]
N2["15.2 Partner agreement"]
N3["15.3 Dependencies"]
N4["15.4 Images"]
N5["15.5 Container guidance"]
N6["15.6 Reviews"]
N7["Managing the partner relationship"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 The missing service"]
N2["15.2 Partner agreement"]
N3["15.3 Dependencies"]
N4["15.4 Images"]
N5["15.5 Container guidance"]
N6["15.6 Reviews"]
N7["Managing the partner relationship"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 The missing service]
|
v
[15.2 Partner agreement]
|
v
[15.3 Dependencies]
|
v
[15.4 Images]
|
v
[15.5 Container guidance]
|
v
[15.6 Reviews]
|
v
[Managing the partner relationship]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) provide a secure partner file service; (2) manage dependencies on external services; (3) review images used in the cluster.
15.1 The missing service
The incident began because there was no approved way to share files with partners. Fairway sets up time-limited signed links that expire after 24 hours. Signed links give the partner a way to download a manifest without making any bucket public. Each link works for a single object and stops after 24 hours, so a link that leaks later is useless. dev-sam's original need was real; the new service meets it in a way the account-level block allows. Partners request links through IT, and each request is logged with the object and the expiry.
15.2 Partner agreement
The partner agrees to download promptly and delete copies after processing. Prompt download keeps the 24-hour expiry practical, and deletion limits how long copies sit outside Fairway's control. The agreement is recorded in the supplier register, and the partner confirms in writing how they store and delete files. Fairway cannot check the partner's systems itself, because they are outside its authority and the review's scope. Each year the account manager checks that the partner's practices have not changed. The partner also now receives a reduced export with only parcel identifiers and postcodes, which limits what any copy could reveal.
15.3 Dependencies
The tracking site depends on a base image, a mapping service and the email provider. Each dependency is listed with an owner. Each dependency can affect security: a vulnerable base image affects every container built on it, the mapping service receives delivery addresses, and the email provider sends tracking messages to customers. The dependency list records what data each one receives, so a problem at a supplier can be assessed quickly. Owners review their entries on the set date and record any change in data received.
15.4 Images
Shu et al. (2017) found many public images contained vulnerabilities; Fairway builds its images from a maintained base in its own registry. Building from a maintained base in Fairway's own registry means the team knows where each image came from and can rebuild when the base is patched. Images are rebuilt monthly, and the inventory confirms the cluster runs the new version. This reduces the risk the study describes without claiming any image is free of vulnerabilities. The base image source is listed in the dependency register with its owner.
15.5 Container guidance
NIST SP 800-190 advises using trusted registries and monitoring images for vulnerabilities. Fairway applies this by pulling images only from its own registry and scanning them when built and on a schedule. The tracker image named in deploy.yaml, registry.fairway.example/tracker:4.2, is an example of an image from the trusted registry. Findings from scans are recorded with owners, like other security findings. The cluster is configured to run only images from that registry, so an image pulled from a public source is refused. Any exception needs Grace's written approval and a recorded reason in the register.
15.6 Reviews
New dependencies require a short review. The review asks what the dependency does, what data it receives, who owns it and how it will be updated. For a new mapping or messaging service, that takes a short meeting and an entry in the dependency list. Without the review, a new service could receive customer addresses without anyone recording that it does. The review result is stored with the dependency list entry and its review date. A dependency without a review cannot be added to the tracking site's deployment.
Managing the partner relationship
The partner is asked to confirm in writing how they store and delete files, and Fairway records the answer in its supplier register. Each year the account manager checks that nothing has changed. This reflects the shared responsibility idea beyond cloud providers: once a file leaves Fairway, the partner's practices matter.
Tomás also asks whether the partner needs full manifests. They need only parcel identifiers and postcodes, so the export is reduced.
Image updates
Base images are rebuilt monthly, and the inventory confirms the cluster runs the new version.
Approval
New partners must use signed links; any other method needs Grace's written approval.
Review of reduced export
The partner confirms the reduced export meets their needs, and the change is recorded.
Worked example
The partner tests a signed link. It works, expires as planned, and the partner confirms the process is easier than before.
Synthetic case. Synthetic.
Errors and limits
Signed links can still be forwarded; keep expiry short.
Exercises
- EX057 — Sharing method. What sharing method replaced the public bucket? Rubric: 3 = signed links expiring in 24h; 2 = partial; 1 = vague; 0 = none.
- EX058 — Partner duties. What did the partner agree? Rubric: 3 = download promptly, delete after; 2 = partial; 1 = vague; 0 = none.
- EX059 — Image source. Where does Fairway build images from? Rubric: 3 = maintained base in own registry; 2 = partial; 1 = vague; 0 = none.
- EX060 — Link risk. What risk remains with signed links? Rubric: 3 = forwarding; 2 = partial; 1 = vague; 0 = none.
Synthesis
Provide safe ways to do needed work so people need not improvise.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →