Chapter 15 — Cloud and container security: guided lab

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 Setup"]
  N2["Lab — baseline check"]
  N3["15.2 Reading the result"]
  N4["15.3 Why client-b differs"]
  N5["15.4 Plan"]
  N6["15.5 Total"]
  N7["Running safely"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 Setup"]
  N2["Lab — baseline check"]
  N3["15.2 Reading the result"]
  N4["15.3 Why client-b differs"]
  N5["15.4 Plan"]
  N6["15.5 Total"]
  N7["Running safely"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 Setup]
    |
    v
[Lab — baseline check]
    |
    v
[15.2 Reading the result]
    |
    v
[15.3 Why client-b differs]
    |
    v
[15.4 Plan]
    |
    v
[15.5 Total]
    |
    v
[Running safely]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) run a baseline check against synthetic cluster settings; (2) interpret failures; (3) plan fixes.

15.1 Setup

Priya exports settings for three clusters into synthetic records: client-a, client-b and Cobalt's internal cluster. The lab compares each with the baseline. The exports are synthetic copies of each cluster's six baseline settings, using the same names as the baseline file. Client-a is a dedicated cluster, client-b is the contractor-built cluster where old-admin was found, and the internal cluster runs Cobalt's own tools. Using copies means the lab can be run, repeated and shared without access to any real cluster.

Lab — baseline check

"""Check synthetic cluster settings against a small benchmark-style baseline (stdlib only)."""
baseline = {"audit_logging": True, "anonymous_auth": False, "pod_security_default": "restricted",
            "secrets_encryption": True, "public_endpoint": False, "node_auto_upgrade": True}
clusters = {
 "client-a": {"audit_logging": True, "anonymous_auth": False, "pod_security_default": "restricted",
              "secrets_encryption": True, "public_endpoint": True, "node_auto_upgrade": True},
 "client-b": {"audit_logging": False, "anonymous_auth": False, "pod_security_default": "privileged",
              "secrets_encryption": False, "public_endpoint": True, "node_auto_upgrade": False},
 "internal": {"audit_logging": True, "anonymous_auth": False, "pod_security_default": "baseline",
              "secrets_encryption": True, "public_endpoint": False, "node_auto_upgrade": True}}
for c, s in clusters.items():
    fails = [k for k, v in baseline.items() if s[k] != v]
    print(f"{c}: {len(baseline)-len(fails)}/{len(baseline)} pass; fails: {', '.join(fails) or 'none'}")

Run with python3 lab_baseline.py. Verified output:

client-a: 5/6 pass; fails: public_endpoint
client-b: 1/6 pass; fails: audit_logging, pod_security_default, secrets_encryption, public_endpoint, node_auto_upgrade
internal: 5/6 pass; fails: pod_security_default

15.2 Reading the result

Client-a passes 5 of 6, failing only on a public endpoint. Client-b passes 1 of 6: audit logging, pod security default, secrets encryption, public endpoint and node auto-upgrade all fail. The internal cluster passes 5 of 6, with a Baseline rather than Restricted default. The only setting client-b passes is anonymous access, which is already off. Its failures match the scenarios: missing audit logging hides misuse, a Privileged default allows risky pods, unencrypted secrets expose stored credentials, a public endpoint widens access and disabled auto-upgrades leave nodes unpatched.

15.3 Why client-b differs

Client-b was set up years ago by a contractor and never reviewed. It explains why the old admin account was found there too. The contractor's setup may have been reasonable when it was built, but the cluster was never compared with any baseline afterwards, so defaults and quick choices stayed in place. Nobody at Cobalt knew which settings had been chosen, because the cluster was configured by hand rather than through the repository. The same lack of review left old-admin bound to cluster-admin long after its owner had gone.

15.4 Plan

Client-b gets a planned rebuild; client-a's endpoint is restricted to Cobalt's office addresses; the internal cluster moves to Restricted after checking its workloads. The plan matches the effort to the size of each cluster's problem. With five failures, client-b is easier to rebuild through the repository than to fix setting by setting, and the rebuild also brings its configuration under review. Client-a's single failure needs only a narrower endpoint rule, made in an agreed change window, and the internal cluster's change waits until warn mode shows which of its workloads would fail Restricted.

15.5 Total

Seven failures across three clusters form the starting count for later comparison. The seven are one failure on client-a, five on client-b and one on the internal cluster. Priya records the figure with the date and the exact baseline version used, so later runs can be compared fairly. If the baseline grows, later runs report results for the original six checks as well as for any new ones. A single total also hides where the work lies, since five of the seven failures belong to client-b.

Running safely

The lab reads settings records only; it changes nothing. Running real checks against client clusters also uses read-only access, granted for that purpose. Priya confirms with Kwame that her account has read rights only before running the check against production settings exports.

What the check cannot see

The baseline check reads settings, so it cannot tell whether workloads inside a cluster behave safely, whether staff passwords are strong or whether the provider's own systems are secure. Priya lists these limits next to the results, so nobody reads a pass as a statement that the cluster is safe overall. She also notes that settings exports are a snapshot: a change made an hour after the export would not appear until the next run, which is one reason to schedule the check daily.

Worked example

Before changing client-b, Priya checks with the client and schedules a window. She tests the new settings on a copy first. The rebuild passes 6 of 6.

Synthetic case. Settings are synthetic.

Errors and limits

A passing check confirms settings, not that workloads behave safely.

Exercises

• EX043 — Lab totals. Give each cluster's result.
  Show marking criteria

  Rubric: 3 = a 5/6, b 1/6, internal 5/6; 2 = two; 1 = one; 0 = none.
• EX044 — Client-b cause. Why was client-b so far from baseline?
  Show marking criteria

  Rubric: 3 = contractor setup never reviewed; 2 = partial; 1 = vague; 0 = none.
• EX045 — Total failures. How many failures were counted in total?
  Show marking criteria

  Rubric: 3 = 7; 2 = partial; 1 = vague; 0 = none.

Synthesis

Run the baseline, explain each failure, and fix with care.

Continue studying — chapter 15 of 30

← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →