Chapter 34 — Cloud and container security: integration
Lesson map
Lesson 34 published. Map, example, EX100.
flowchart TD
N0["Learning outcomes"]
N1["34.1 Logging"]
N2["34.2 Alerting"]
N3["34.3 Incident response"]
N4["34.4 Change management"]
N5["34.5 Governance"]
N6["34.6 People"]
N7["34.7 Integration testing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX100"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["34.1 Logging"]
N2["34.2 Alerting"]
N3["34.3 Incident response"]
N4["34.4 Change management"]
N5["34.5 Governance"]
N6["34.6 People"]
N7["34.7 Integration testing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]
[Learning outcomes]
|
v
[34.1 Logging]
|
v
[34.2 Alerting]
|
v
[34.3 Incident response]
|
v
[34.4 Change management]
|
v
[34.5 Governance]
|
v
[34.6 People]
|
v
[34.7 Integration testing]
|
v
[Worked example] --> [Exercise EX100]
Learning outcomes
You will (1) integrate cloud controls with logging, incident response, change management and the wider organisation; (2) connect alerts to people; (3) align with governance.
34.1 Logging
Cloud audit logs, Kubernetes audit logs, admission decisions and network denials flow to Solent's central log platform, kept for a year in a separate account.
Each log source answers different questions: cloud audit logs show changes to accounts and storage; Kubernetes audit logs show actions in the cluster; admission decisions show what was blocked; network denials show blocked connections. Keeping them in a separate account protects them from tampering by someone who compromises production. Retention of a year supports investigations that start long after an event, such as a key misused months later.
34.2 Alerting
High-risk events (public access settings changed, new keys created, policy engine disabled, privileged pod admitted under exception) raise alerts routed to the on-call engineer, meeting the 15-minute objective from chapter 7.
Each listed event is rare in normal operation and serious when unexpected, so alerting on it produces few false alarms. A policy engine being disabled could precede an attack. Routing directly to the on-call engineer avoids the delays that pushed the earlier p95 to forty minutes. Each alert links to its runbook.
34.3 Incident response
Runbooks describe first steps for each alert type, including revoking credentials and isolating namespaces.
Runbooks give the first steps so the on-call engineer can act quickly and consistently at any hour. Revoking credentials stops their misuse; isolating a namespace limits spread. Each runbook names when to escalate and to whom. Runbooks are written for an engineer who may be woken at night, so each step is short and exact, with the command or console path given. Each runbook also lists what evidence to preserve before acting, so containment does not destroy what investigators will need later.
34.4 Change management
Policy changes follow the normal change process with security review; emergency changes are reviewed afterwards.
Security review of policy changes catches mistakes that could open gaps or break services. Emergency changes are allowed when needed but reviewed afterwards to confirm they were justified and correct. The record shows every change to controls over time. Changes are linked to the requirement they affect, so reviewers can check the change still meets it. The record of emergency changes is reviewed monthly to see whether any recur, which would suggest a gap in the normal process.
34.5 Governance
Monthly coverage and incidents feed Solent's risk committee; CSA CCM v4 mapping supports the regulator's annual review.
Regular reporting keeps managers informed and lets them make decisions about risk and investment. Mapping to CCM shows how Solent's controls meet recognised standards, which simplifies the regulator's review and highlights any gaps. Elena prepares the first monthly report herself, showing coverage by namespace, incidents and open exceptions on one page. The committee's questions guide what later reports include, and the CCM mapping is updated whenever a control changes.
34.6 People
Developers get training on the new controls and a help channel; the platform team runs office hours.
Controls that developers do not understand cause frustration and workarounds. Training explains why each control exists and how to work with it. A help channel and office hours make it easy to ask questions, reducing the chance of teams requesting unnecessary exceptions. Feedback from office hours shapes documentation and sometimes the controls themselves; a confusing error message is rewritten after three teams ask about it.
34.7 Integration testing
Synthetic events are injected monthly to check each alert reaches the on-call engineer.
An alert that never reaches anyone is useless, and routing can break silently through configuration changes. Monthly synthetic events check the whole path from source to on-call engineer. The time taken is recorded and compared with the fifteen-minute objective. The injected events use test identities and test resources, so they cannot be confused with real incidents. Each one carries a marker that the on-call engineer recognises. A missed or slow test alert is treated like a real failure and investigated.
Training developers
Training is short and practical: a one-hour session showing how admission messages explain a rejection, how to request an exception and how to read denied-connection logs. Rejection messages link to a page with the rule, the reason and an example fix. After training, help-channel questions about rejections fall by half, and most remaining ones lead to clearer messages.
Ownership of alerts
Every alert rule has an owning team and a runbook link, checked quarterly so that rules without owners are fixed or removed.
Worked example
An injected "public access setting changed" event takes 31 minutes to reach on-call because the alert rule's severity was set to low. The rule is corrected, and the monthly injection is added to the verification schedule.
Synthetic case. Systems and events are synthetic.
Errors and limits
Alerts nobody receives are equivalent to no alerts.
Exercises
- EX100 — Alert examples. Name three high-risk alerts. Rubric: 3 = public access, new keys, engine disabled, privileged pod; 2 = two; 1 = one; 0 = none.
- EX101 — Log retention. Where and how long are logs kept? Rubric: 3 = separate account, one year; 2 = partial; 1 = vague; 0 = none.
- EX102 — Injection finding. What did the injection test find? Rubric: 3 = 31 min due to low severity; 2 = partial; 1 = vague; 0 = none.
Synthesis
Controls work only when integrated with people and processes.
Continue studying — chapter 34 of 50
← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →