Chapter 31 — Cloud and container security: implementation II | Engineering Cloud and container security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 31 — Cloud and container security: implementation II

Lesson map

Lesson 31 published. Map, example, EX091.

flowchart TD
  N0["Learning outcomes"]
  N1["31.1 Image signing"]
  N2["31.2 Rollout sequence"]
  N3["31.3 Network policies"]
  N4["31.4 Exceptions"]
  N5["31.5 Communication"]
  N6["31.6 Confirming"]
  N7["31.7 Cleanup"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX091"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["31.1 Image signing"]
  N2["31.2 Rollout sequence"]
  N3["31.3 Network policies"]
  N4["31.4 Exceptions"]
  N5["31.5 Communication"]
  N6["31.6 Confirming"]
  N7["31.7 Cleanup"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]

[Learning outcomes]
    |
    v
[31.1 Image signing]
    |
    v
[31.2 Rollout sequence]
    |
    v
[31.3 Network policies]
    |
    v
[31.4 Exceptions]
    |
    v
[31.5 Communication]
    |
    v
[31.6 Confirming]
    |
    v
[31.7 Cleanup]
    |
    v
[Worked example] --> [Exercise EX091]

Learning outcomes

You will (1) implement image signing, admission verification and default-deny networking across production; (2) sequence the rollout; (3) manage exceptions; (4) confirm results.

31.1 Image signing

The standard pipeline signs every image after build and scanning, and records the image digest. Admission verifies the signature and that the image comes from Solent's registry. Images are referenced by digest, not mutable tags, so what was verified is what runs.

Signing after scanning means a signature also certifies that the image passed the pipeline's checks, not just that the pipeline built it. Recording the digest ties the signature to exact bytes. A tag such as 'latest' can be moved to point at different content at any time, so a manifest that names a tag might run something other than what was verified. Referencing digests closes that gap and makes deployments repeatable.

31.2 Rollout sequence

Signature verification starts in audit mode, logging unsigned images without blocking, for two weeks. The log shows which teams still use old pipelines. Enforcement follows namespace by namespace once each is clean.

Turning enforcement on everywhere at once would block any team still using an old pipeline, possibly during an urgent fix. Audit mode shows who would be blocked without blocking them, so the platform team can help those teams move first. Enforcing namespace by namespace means each switch affects a known, prepared group, and a problem in one namespace does not stop deployments across the whole platform.

31.3 Network policies

Default-deny policies roll out in the order from chapter 24, with denied-connection logs watched for a day after each namespace.

Following the order set during design means the riskiest paths, such as web to database, are closed early. Watching denied-connection logs for a day after each namespace catches flows that the traffic map missed, such as a daily report job. Each missed flow found this way gets an allow rule with a reason, and the traffic map is updated so the next namespace benefits.

31.4 Exceptions

The node agent keeps its exception on a dedicated node pool; the two services writing to their root filesystem complete their changes and their exception expires on time.

The node agent's exception stays because its job genuinely needs elevated access, and the dedicated pool limits what that access could reach. The two services that wrote to their root filesystem were given time to move writes to a mounted volume. Letting their exception expire on schedule, rather than extending it, shows the process works and that exceptions are truly temporary.

31.5 Communication

A shared calendar shows each namespace's enforcement date. Teams can ask for a delay with a reason, approved by the platform lead.

Teams plan better when they know dates in advance; surprise enforcement leads to frustration and pressure to roll back. Allowing delays with a reason keeps the rollout realistic, since a team mid-release may genuinely need a week. Requiring the platform lead's approval keeps delays from becoming routine and records why each one was granted. Most teams keep their original dates.

31.6 Confirming

After each step, verification tests from chapter 30 run again in production using synthetic test workloads in a dedicated test namespace.

Laboratory tests showed controls worked in the test cluster; rerunning them in production shows they work where it matters. A dedicated namespace keeps test workloads separate from real services, and synthetic workloads mean no real data are involved. Results are recorded the same way as in the laboratory, adding production evidence to the record. Any failure pauses the next namespace's enforcement.

31.7 Cleanup

Old pipeline jobs that cannot sign images are archived so they cannot be used by mistake.

An old pipeline job left in place could be used by someone in a hurry, producing an unsigned image that admission would then reject, or worse, prompting a request for an exception. Archiving removes the temptation while keeping the history for reference. Elena lists the archived jobs and their owners in the change record. A pipeline check also rejects references to archived jobs, so nobody restores one by copying old configuration.

Signing keys

Signing keys live in a managed key service; the pipeline can request signatures but cannot export the key.

Worked example

Audit mode reveals a third-party monitoring image pulled directly from a public registry. Instead of an exception, the platform team mirrors it into Solent's registry after checking its published digest and signs it with a separate key marked "third-party, verified", keeping one admission rule for all images.

Synthetic case. Images and timelines are synthetic.

Errors and limits

Audit periods that never end become permanent gaps; set an end date.

Exercises

EX091 — Digest use. Why reference images by digest? Rubric: 3 = what was verified is what runs; 2 = partial; 1 = vague; 0 = none.
EX092 — Audit mode. What did audit mode achieve? Rubric: 3 = found teams on old pipelines without blocking; 2 = partial; 1 = vague; 0 = none.
EX093 — Third-party image. How was the monitoring image handled? Rubric: 3 = mirrored, digest-checked, signed as third-party; 2 = partial; 1 = vague; 0 = none.

Synthesis

Roll out enforcement after audit periods and keep one rule for all images.

Continue studying — chapter 31 of 50

← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →