<a id="ch-07"></a>

## Chapter 7 — Cloud and container security: controls and verification

<!-- open-cyber-academy:lesson-figures:start ch-07 -->
### Lesson map

Lesson 07 published. Map, example, EX031.

```mermaid
flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Changes"]
  N2["7.2 Verification"]
  N3["Lab — remediation confirmation"]
  N4["7.3 Reading the result"]
  N5["7.4 Handling the open item"]
  N6["7.5 Reporting"]
  N7["Test pod"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]
```

### Logical drawing

```mermaid
flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Changes"]
  N2["7.2 Verification"]
  N3["Lab — remediation confirmation"]
  N4["7.3 Reading the result"]
  N5["7.4 Handling the open item"]
  N6["7.5 Reporting"]
  N7["Test pod"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
```

```text
[Learning outcomes]
    |
    v
[7.1 Changes]
    |
    v
[7.2 Verification]
    |
    v
[Lab — remediation confirmation]
    |
    v
[7.3 Reading the result]
    |
    v
[7.4 Handling the open item]
    |
    v
[7.5 Reporting]
    |
    v
[Test pod]
    |
    v
[Worked example] --> [Exercise EX031]
```
<!-- open-cyber-academy:lesson-figures:end ch-07 -->


### Learning outcomes

You will (1) apply role and workload changes; (2) verify each remediation with fresh evidence; (3) report status.

### 7.1 Changes

Hannah's plan has six items: remove storage.admin from permits-app, remove iam.admin and storage.read from reporting, remove iam.admin and registry.delete from deploy-bot, rebuild permits-web, rebuild reporting, and enforce Restricted in the permits namespace. Each item corresponds to a finding and has a named owner and a planned date. The permission removals go first in staging, tested with the digital team, then to production through the change process one at a time, so a problem can be traced to a single change. The rebuilds follow the tier deadlines, and enforcing Restricted comes last, after the workloads have been checked against it.

### 7.2 Verification

Each item is confirmed with fresh evidence: a new role export, a new scan, and the namespace label plus a test deployment of a synthetic non-compliant pod in staging that should be rejected. Fresh evidence shows that the change took effect in production, not only that it was approved. The new role export shows that each removed permission is gone, the new scan shows that rebuilt images no longer carry the finding, and the rejected test pod shows that Restricted is enforced. Hannah saves each piece with its time and source in the evidence register, as she did for the original exports.

### Lab — remediation confirmation

```python
"""Confirm remediation items against fresh synthetic evidence (stdlib only)."""
items = {"remove storage.admin from permits-app": True, "remove iam.admin from reporting": True,
         "remove iam.admin and registry.delete from deploy-bot": True, "rebuild permits-web (CVE-A)": True,
         "rebuild reporting (CVE-D)": False, "enforce Restricted in permits namespace": True}
done = sum(items.values())
print(f"confirmed {done}/{len(items)}")
for k, v in items.items():
    if not v: print("  open:", k)
```

Run with `python3 lab_confirm.py`. Verified output:

```text
confirmed 5/6
  open: rebuild reporting (CVE-D)
```

### 7.3 Reading the result

Five of six items are confirmed. The reporting rebuild is open because the reporting job uses an old library that does not work with the new base image. The open item is reported as open, with its reason, rather than counted as done because the change was planned. Hannah records which items are confirmed and the evidence for each, and lists the reporting rebuild separately with the digital team's explanation. This is the information audit receives, so its picture matches what is actually running.

### 7.4 Handling the open item

The digital team needs two weeks to update the library. Hannah records an exception with compensating controls: reporting runs internally with no internet access and its role is now read-only. The controls reduce risk while the library is updated: without internet access, the vulnerability in the reporting image is harder to reach, and with a read-only role, even a compromised job could not change permissions or records. Dev approves the exception with a review date of two weeks, and it is included in the update to audit.

### 7.5 Reporting

Audit receives the status with evidence for each closed item and the exception for the open one. For each closed item, audit sees the original finding, the change made, the date and the fresh evidence confirming it. The exception shows the reason the reporting rebuild is open, the compensating controls, the owner and the expected date. Hannah presents the status in a short table, so audit can check each finding quickly. She also includes the two process recommendations, since audit asked how the findings arose. Dev signs off each verified item, and its evidence is archived.

### Test pod

The synthetic non-compliant pod requests to run as root. It is used only in staging and is rejected as expected, proving the admission rule works without harming anything. The test is part of the verification record and repeated after any cluster upgrade, because upgrades have removed security features before, as when PodSecurityPolicy was removed in Kubernetes 1.25.

### Worked example

Audit asks how Hannah knows Restricted is enforced. She shows the namespace label and the staging rejection of the synthetic test pod, with timestamps.

> **Synthetic case.** Synthetic.

### Errors and limits

A ticket marked done is not verification; check the system itself.

### Exercises

- **EX031 — Lab result.** How many items were confirmed, and which was open? *Rubric:* 3 = 5/6; reporting rebuild; 2 = partial; 1 = vague; 0 = none.
- **EX032 — Restricted evidence.** What evidence showed Restricted was enforced? *Rubric:* 3 = label and staging rejection of test pod; 2 = partial; 1 = vague; 0 = none.
- **EX033 — Open item cause.** Why was the reporting rebuild delayed? *Rubric:* 3 = old library incompatible; 2 = partial; 1 = vague; 0 = none.
- **EX034 — Compensating controls.** What compensating controls applied? *Rubric:* 3 = internal only, no internet, read-only role; 2 = two; 1 = one; 0 = none.
- **EX035 — Done versus verified.** Why is a closed ticket not verification? *Rubric:* 3 = must check the system; 2 = partial; 1 = vague; 0 = none.

### Synthesis

Verify each fix with fresh evidence and record honest exceptions.

### Continue studying — chapter 07 of 12

[← Chapter 06 (draft)](#ch-06) · [Course chapter index](../SUBJECTS.md) · [Chapter 08 (draft) →](#ch-08)

## Worked answers

<a id="answer-ex031"></a>
**EX031.** Five of six; the reporting rebuild was open.

<a id="answer-ex032"></a>
**EX032.** The namespace label and a staging rejection of a synthetic non-compliant pod.

<a id="answer-ex033"></a>
**EX033.** An old library did not work with the new base image.

<a id="answer-ex034"></a>
**EX034.** Internal only, no internet access and a read-only role.

<a id="answer-ex035"></a>
**EX035.** Verification requires checking the system itself.