Chapter 14 — Cloud and container security: automation | Technical 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.

Lesson map

Lesson 14 published. Map, example, EX053.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Daily check"]
  N2["14.2 Change alert"]
  N3["14.3 Pipeline rules"]
  N4["14.4 Review"]
  N5["14.5 Noise"]
  N6["14.6 Ownership"]
  N7["Testing the automation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX053"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Daily check"]
  N2["14.2 Change alert"]
  N3["14.3 Pipeline rules"]
  N4["14.4 Review"]
  N5["14.5 Noise"]
  N6["14.6 Ownership"]
  N7["Testing the automation"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX053"]

[Learning outcomes]
    |
    v
[14.1 Daily check]
    |
    v
[14.2 Change alert]
    |
    v
[14.3 Pipeline rules]
    |
    v
[14.4 Review]
    |
    v
[14.5 Noise]
    |
    v
[14.6 Ownership]
    |
    v
[Testing the automation]
    |
    v
[Worked example] --> [Exercise EX053]

Learning outcomes

You will (1) automate checks and alerts; (2) alert on public access changes; (3) keep automation reviewable.

14.1 Daily check

The verification script runs daily in the pipeline and posts results to the team channel. The daily run uses the same verification script as the lab, so its output looks the same: one line per bucket and a count of differences. Posting to the team channel means a new bucket created without logging is visible the next morning. If the count rises above the approved exception, someone has to explain why before the day ends. The run uses the auditor role, so it can read settings but change nothing.

14.2 Change alert

An alert fires within minutes if any bucket policy changes to public, using the provider's event notifications. In March the public policy stayed in place for nearly three days before anyone noticed; with the alert, the same change would be seen within minutes. The alert reads management events, which are recorded even where data access logging is off. Its message links to the runbook, so the person on call knows how to check and revert. The drill in staging measured four minutes from change to alert.

14.3 Pipeline rules

Infrastructure code that sets public access or disables encryption is blocked before merge, with a clear message. Rahman et al. (2019) found such smells recur in infrastructure code. The check reads infrastructure code in each merge request and stops it if a bucket is set public or encryption is turned off. The message explains the rule and points to the signed-link procedure for sharing files. Blocking before merge prevents the change from reaching the account at all, while the alert remains as a backstop for console changes.

14.4 Review

Automation scripts are reviewed like application code. A bug in the verification script could hide a public bucket as easily as a bug in the tracking site could hide an order. Each script change goes through a merge request that Grace or another team member reviews. Reviewers check both the logic and that the output never includes secret values or customer data. Review also confirms that each script still matches the current storage policy. When the policy gains a rule, such as the object ownership controls found by the provider tool, the script and its tests change in the same merge request. Script changes that arrive without passing tests are not merged into the pipeline.

14.5 Noise

Alerts must lead to action; the assets account is excluded to avoid constant alerts. The assets account is public by design, so every change there would trigger the public-access alert and teach people to ignore it. Excluding that account keeps each alert meaningful for the person who receives it. The daily check still covers site-assets, recording its public access as the approved exception, so the exclusion does not leave it unwatched. Tomás reviews alert volume monthly and adjusts rules that fire without leading to action.

14.6 Ownership

Grace owns the alert; Tomás maintains the scripts. Grace decides what the alert covers and who responds to it, while Tomás keeps the scripts working and updates them when the policy changes. Clear ownership means a broken check or a noisy alert has someone responsible for it. When Tomás finishes his apprenticeship, the handover names the person who takes over the scripts. Ownership is written into the runbook and the alert message itself, so responders know whom to contact. Grace reviews the alert's scope when new buckets or accounts are added.

Testing the automation

Every alert and check is tested with a synthetic change in staging when first created and then every quarter. A drill confirms that the alert fires, reaches the right channel and that the runbook is followed. Without drills, a broken alert could stay silent for months.

Tomás records drill results with the time to alert and the time to response.

Event sources

The alert uses the provider's management events for policy changes, which are recorded even without data access logging.

Failure of automation

If the daily check fails to run, it posts a failure message rather than staying silent.

Change control

Changes to alert rules go through review, so nobody can quietly disable them; the history shows who changed what and when.

Documentation

Each automated check links to its runbook in the alert message, so responders know what to do immediately.

Worked example

A test change in staging sets a bucket public. The alert arrives in four minutes, the on-call engineer checks the change, and the test is recorded as a successful drill.

Synthetic case. Synthetic.

Errors and limits

Automation catches known patterns; new services may need new checks.

Exercises

EX053 — Alert speed. How fast did the drill alert arrive?
Show marking criteria
Rubric: 3 = four minutes; 2 = partial; 1 = vague; 0 = none.
EX054 — Pipeline block. What infrastructure changes are blocked?
Show marking criteria
Rubric: 3 = public access, disabled encryption; 2 = partial; 1 = vague; 0 = none.
EX055 — Exclusion. Why exclude the assets account?
Show marking criteria
Rubric: 3 = avoid constant alerts; 2 = partial; 1 = vague; 0 = none.
EX056 — Owners. Who owns the alert and scripts?
Show marking criteria
Rubric: 3 = Grace; Tomás; 2 = partial; 1 = vague; 0 = none.

Synthesis

Automate checks and alerts with clear owners.

Continue studying — chapter 14 of 18

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →