Chapter 5 — Security literacy
Lesson map
Lesson 05 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Core ideas"]
N2["5.2 Common cloud risks"]
N3["5.3 Least privilege"]
N4["5.4 Defence in depth"]
N5["5.5 Guidance"]
N6["5.6 Thinking like a defender"]
N7["Reading guidance critically"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Core ideas"]
N2["5.2 Common cloud risks"]
N3["5.3 Least privilege"]
N4["5.4 Defence in depth"]
N5["5.5 Guidance"]
N6["5.6 Thinking like a defender"]
N7["Reading guidance critically"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]
[Learning outcomes]
|
v
[5.1 Core ideas]
|
v
[5.2 Common cloud risks]
|
v
[5.3 Least privilege]
|
v
[5.4 Defence in depth]
|
v
[5.5 Guidance]
|
v
[5.6 Thinking like a defender]
|
v
[Reading guidance critically]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes
You will (1) explain core security ideas in cloud terms; (2) recognise common cloud risks; (3) understand defence in depth and least privilege; (4) read security guidance critically.
5.1 Core ideas
Confidentiality, integrity and availability; authentication and authorisation; least privilege; defence in depth; logging and accountability. Each has a cloud form: identity policies, encryption settings, multi-zone deployment, audit logs.
Mapped to the opening case, confidentiality failed when the registry allowed anonymous pulls; accountability failed when audit logging was off; defence in depth partly worked through the database's network rule. Seeing each idea in a concrete cloud setting makes the terms useful rather than abstract. Availability was not affected, which Samuel also records, since a full picture includes what went right.
5.2 Common cloud risks
Misconfigured storage and registries, over-broad identities, leaked credentials, unpatched images, missing logs. Most are configuration choices on the customer's side.
The opening case had three of the five: a misconfigured registry, a leaked credential in an image and missing logs. None required a sophisticated attacker to create; each came from a setting or a habit. That is why so much of the course focuses on checking configuration systematically. Unpatched images and over-broad identities were not involved in the opening case, but the role-path lab later in this part shows the second is present in StudyHub too.
5.3 Least privilege
Each person and service gets only the access it needs. If records-api had used a short-lived identity instead of a connection string, there would have been no secret to leak.
The connection string gave whoever held it the same access as records-api, with no expiry. A short-lived identity tied to the running workload would have been useless to anyone who copied the image. Least privilege applies not only to what access is granted but to how long and to whom.
5.4 Defence in depth
Several layers: private registry, no secrets in images, scanning before push, limited database permissions, logging. Any one could have reduced the opening case's risk.
In the opening case, the private registry and secret-free images were both missing, scanning did not look for secrets, and logging was off in one account. Only the network restriction on the test database held. Each missing layer is now a separate action with its own owner. Samuel ranks them by how quickly they can be done and how much risk each removes.
5.5 Guidance
CIS Benchmarks give configuration checklists; CSA CCM v4 lists cloud controls; NIST SP 800-190 covers containers. Samuel learns to check the date and scope of guidance before using it.
A CIS Benchmark for an older Kubernetes version might recommend settings that no longer exist or miss new ones. Samuel records the version of each guide he uses and checks that it matches StudyHub's services. Where guidance and StudyHub's setup differ, he notes the difference rather than forcing the guidance to fit.
5.6 Thinking like a defender
Ask what could go wrong, how it would be noticed and how it would be fixed.
For the registry, those questions become concrete: an image could be downloaded by anyone; that would be noticed only through audit logs, which were missing in one account; and it is fixed by disabling anonymous pull and removing secrets. Asking all three for each component exposes gaps in detection as well as prevention. Samuel writes the three answers in a small table for each StudyHub component, and the empty cells become the next term's work.
Reading guidance critically
For each piece of guidance, Samuel asks who wrote it, for which systems, how recent it is and what evidence supports it. A CIS Benchmark for a specific managed Kubernetes version is more useful to StudyHub than a general blog post. Vendor guidance may favour the vendor's products; it is still useful for configuration details, but recommendations about which tools to buy need independent checking.
Worked example
Samuel maps the opening case to defence-in-depth layers and finds that only one layer, network restrictions on the test database, was working. That layer probably prevented harm, which shows why multiple layers matter.
Synthetic case. Case details are synthetic.
Errors and limits
Guidance can be outdated; check versions.
Exercises
- EX013 — Common risks. Name three common cloud risks. Rubric: 3 = storage/registry misconfig, broad identities, leaked creds, unpatched images, missing logs; 2 = two; 1 = one; 0 = none.
- EX014 — Least privilege example. How would least privilege have helped records-api? Rubric: 3 = short-lived identity, no secret; 2 = partial; 1 = vague; 0 = none.
- EX015 — Working layer. Which layer worked? Rubric: 3 = network restrictions on test DB; 2 = partial; 1 = vague; 0 = none.
Synthesis
Core security ideas take specific forms in the cloud.
Continue studying — chapter 05 of 40
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →