Chapter 25 — Design studio I | 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 25 — Design studio I

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 The brief"]
  N2["25.2 Alternatives"]
  N3["25.3 Comparison"]
  N4["25.4 Review package"]
  N5["25.5 Critique"]
  N6["25.6 Revision"]
  N7["Studio process"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 The brief"]
  N2["25.2 Alternatives"]
  N3["25.3 Comparison"]
  N4["25.4 Review package"]
  N5["25.5 Critique"]
  N6["25.6 Revision"]
  N7["Studio process"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The brief]
    |
    v
[25.2 Alternatives]
    |
    v
[25.3 Comparison]
    |
    v
[25.4 Review package]
    |
    v
[25.5 Critique]
    |
    v
[25.6 Revision]
    |
    v
[Studio process]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) design an end-to-end secure deployment path for meterhub in a team; (2) critique alternatives; (3) produce a design review package; (4) incorporate feedback.

25.1 The brief

Teams design how code becomes a running meterhub workload: build, scan, sign, store, admit, deploy and observe, meeting requirements R1 to R6.

The brief covers the whole path from code to running pod, because weaknesses often appear between steps. An image could be scanned but not signed, or signed but not checked at admission. Teams must show how each requirement is met along the path. Each team presents its design as a sequence of steps with the requirement met at each step and the evidence that would prove it. Teams also list which steps could fail and what happens to a deployment when one does.

25.2 Alternatives

Team A proposes push-based deployment from the pipeline with a production deployer identity. Team B proposes pull-based GitOps, where a controller in the cluster pulls approved manifests. Elena's team compares them on credentials exposed, auditability and recovery.

Push-based deployment gives the pipeline a credential that can change production, which becomes a high-value target. Pull-based GitOps keeps that power inside the cluster. Comparing them on agreed criteria keeps the discussion grounded rather than based on familiarity. Elena's team scores both options against the three criteria and notes the evidence for each score.

25.3 Comparison

Pull-based deployment means the pipeline never holds cluster credentials, and the cluster's state is always reconciled to the repository. Push-based is simpler to adopt. Both can verify signatures at admission.

Pull-based design reduces credential exposure and makes drift self-correcting, but it needs teams to learn a new workflow. Push-based is familiar but concentrates risk in the pipeline. Signature checks at admission protect both, since only signed images run regardless of how they were deployed. The team recommends pull-based GitOps for production and push-based for the test cluster, where speed matters more.

25.4 Review package

Diagram, requirement trace, threat scenarios addressed, open risks and a test plan.

Each item lets reviewers check a different aspect: the diagram shows structure, the trace shows requirements met, threat scenarios show risks addressed, open risks show honesty, and the test plan shows how claims will be proved. Missing items are noted in the critique. Teams submit the package two days before the critique session, so critics can read it carefully. Elena's team keeps it to eight pages plus diagrams, with each open risk naming who would accept it and why.

25.5 Critique

Studio critics ask how emergency fixes work if the repository is unavailable, and who can change the GitOps controller itself.

Both questions target hidden dependencies. If the repository is down, can urgent fixes still be deployed safely? Whoever controls the GitOps controller effectively controls production, so its own configuration needs strong protection. Good critique finds such weak points before deployment. The critics also ask how a new engineer would learn the process. Elena's team had no answer and adds a short onboarding guide to the design, with a worked example of deploying a change end to end.

25.6 Revision

The design adds a documented break-glass path with alerts, and restricts controller changes to a separate reviewed repository.

A break-glass path allows urgent changes when normal channels fail, but every use raises an alert and must be reviewed afterwards. Keeping controller configuration in a separate repository with its own review limits who can change the most powerful component. The revisions close the gaps the critique found. The team tests the break-glass path on the test cluster to confirm the alert fires and the change is recorded properly.

Studio process

Each team has two weeks: one for design, one for review and revision. Critics are platform engineers from another energy company, invited under a confidentiality agreement and shown only synthetic diagrams. Their outside view is valuable: they point out that GitOps controllers themselves need updates and monitoring. Teams are assessed on clarity, trace to requirements, honesty about open risks and response to critique, not on choosing a particular design.

Package format

Review packages are limited to ten pages so critics can read them fully.

Worked example

The panel selects the pull-based design for production with the break-glass addition. Elena's team notes that it also addresses the console-change problem: manual edits are reverted by reconciliation.

Synthetic case. Designs are synthetic.

Errors and limits

Studio designs skip operational details; plan pilots before committing.

Exercises

EX073 — Brief stages. List the deployment path stages. Rubric: 3 = build, scan, sign, store, admit, deploy, observe; 2 = four; 1 = two; 0 = none.
EX074 — Pull advantage. What is pull-based deployment's credential advantage? Rubric: 3 = pipeline holds no cluster credentials; 2 = partial; 1 = vague; 0 = none.
EX075 — Critique. What did critics ask? Rubric: 3 = emergency path; who changes controller; 2 = two; 1 = one; 0 = none.

Synthesis

Compare designs on credentials, auditability and recovery.

Continue studying — chapter 25 of 50

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →