Chapter 7 — Cloud and container security: organizational integration
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Ownership"]
N2["7.2 Change management"]
N3["7.3 Risk reporting"]
N4["7.4 Framework mapping"]
N5["7.5 Shared responsibility"]
N6["7.6 Training"]
N7["7.7 Funding"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Ownership"]
N2["7.2 Change management"]
N3["7.3 Risk reporting"]
N4["7.4 Framework mapping"]
N5["7.5 Shared responsibility"]
N6["7.6 Training"]
N7["7.7 Funding"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 Ownership]
|
v
[7.2 Change management]
|
v
[7.3 Risk reporting]
|
v
[7.4 Framework mapping]
|
v
[7.5 Shared responsibility]
|
v
[7.6 Training]
|
v
[7.7 Funding]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) integrate cluster security into Beacon's governance; (2) assign ownership; (3) connect to change management and risk reporting; (4) map controls to frameworks.
7.1 Ownership
The platform team owns the central policies; each product team owns its namespace exceptions; the security team owns evaluation and assurance; the risk committee owns acceptance of residual risk. Splitting ownership this way matches who at Beacon can actually make each kind of change. The platform team controls the central repository and cluster configuration, product teams know why their workloads need exceptions, the security team can test independently, and only the risk committee can accept residual risk on Beacon's behalf. Inês writes the split into the control record, so each owner knows their part.
7.2 Change management
Cluster upgrades now include a checklist step: confirm admission configuration and run the behaviour tests before and after. The change board will not approve an upgrade without the test record. The checklist step answers the cause of the audit finding directly: the upgrade that removed PodSecurityPolicy had no step to confirm its replacement was configured. Running behaviour tests before and after shows whether admission still rejects unsafe workloads. In a test run, the step took ten minutes and caught a missing label in a staging upgrade, and the change board made it standard.
7.3 Risk reporting
A monthly metric: share of namespaces enforced at the intended level, open exceptions and their age. The metric shows the risk committee whether enforcement is holding and whether exceptions are being cleared or accumulating. Exception age matters because an old exception may no longer have a valid reason. The platform team produces the figures from live cluster data each month, and Inês adds a short note on any change. Expired exceptions are flagged in red, so they cannot quietly continue past their agreed date. Exception age is shown in bands, so the committee can see at a glance which exceptions are nearing expiry.
7.4 Framework mapping
Beacon maps the controls to CSA CCM v4 domains and NIST SP 800-190 recommendations, so auditors can see coverage without new documents. Mapping to existing frameworks avoids writing new documents for auditors who already know CSA CCM and NIST guidance. Each control in the baseline is listed with the domain or recommendation it supports, and the evidence that it works, such as behaviour test records. Inês notes where a framework recommendation is not covered, so gaps are visible. Internal audit reviews the mapping before it is used in any external audit response.
7.5 Shared responsibility
Beacon uses a managed Kubernetes service; the provider secures the control plane, while Beacon configures admission and workloads. The provider's shared responsibility page is cited in the control record. Citing the provider's page shows auditors where Beacon's responsibility begins and confirms that the audit finding falls on Beacon's side. If Beacon moved to another provider, the split would need to be checked again, as Inês later explained to an examiner. The control record is reviewed each year with the provider's current documentation, in case the split changes.
7.6 Training
Short guidance for product teams explains levels and how to request exceptions. Product teams do not need to understand every rule, but they need to know what each Pod Security level allows and how to ask for an exception if a workload needs more. The guidance gives examples from Beacon's own workloads, such as why monitoring is Privileged and how the quotes team requested an exception. It is published where teams already look for platform documentation. Product leads review the guidance before it is published, so its examples match their workloads.
7.7 Funding
Option B's budget covers one engineer for a year; ongoing work goes into the platform team's plan. Funding one engineer for a year covers the rollout across four clusters, the policy engine and the assurance tests. After that, maintaining the baseline becomes part of the platform team's normal work rather than a separate project. Inês records the funding decision and the hand-over date in the plan, so it is clear when the project ends and routine ownership begins. The risk committee approves the hand-over date, after which the platform team's plan carries the work.
Auditor walkthrough
When the external auditor returns, Inês walks through the control record: the mapping to CSA CCM v4, the upgrade checklist, the monthly metric and the evaluation report. The auditor samples two upgrades and confirms the test records exist. Because evidence was produced by normal work rather than prepared for the audit, the walkthrough takes an afternoon instead of a week, and the finding is closed with one minor observation about exception review dates.
Worked example
The change board initially sees the new step as overhead. After a test run takes ten minutes and catches a missing label in a staging upgrade, the board makes it standard.
Synthetic case. Organisation details are synthetic.
Errors and limits
Integration succeeds when controls fit existing processes.
Exercises
- EX031 — Owners. Who owns central policies and exceptions? Rubric: 3 = platform team; product teams; 2 = partial; 1 = vague; 0 = none.
- EX032 — Upgrade step. What upgrade checklist step was added? Rubric: 3 = confirm admission config and behaviour tests; 2 = partial; 1 = vague; 0 = none.
- EX033 — Metric. What monthly metric is reported? Rubric: 3 = namespaces enforced, exceptions and age; 2 = partial; 1 = vague; 0 = none.
- EX034 — Shared responsibility. What does the provider secure versus Beacon? Rubric: 3 = control plane; admission and workloads; 2 = partial; 1 = vague; 0 = none.
- EX035 — Change board. What convinced the change board? Rubric: 3 = ten-minute test caught missing label; 2 = partial; 1 = vague; 0 = none.
Synthesis
Embed controls in ownership and change processes.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →