◇ OpenCyber Academy
Doctoral research · Chapter 2 · English

Chapter 2 — Cloud and container security: research frontier

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — Cloud and container security: research frontier

Lesson map

Lesson 02 published. Map, example, EX008.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Foundations"]
  N2["2.2 Shared responsibility"]
  N3["2.3 Configuration as code"]
  N4["2.4 Isolation and multi-tenancy"]
  N5["2.5 Access control and zero trust"]
  N6["2.6 The gap"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX008"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Foundations"]
  N2["2.2 Shared responsibility"]
  N3["2.3 Configuration as code"]
  N4["2.4 Isolation and multi-tenancy"]
  N5["2.5 Access control and zero trust"]
  N6["2.6 The gap"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]

[Learning outcomes]
    |
    v
[2.1 Foundations]
    |
    v
[2.2 Shared responsibility]
    |
    v
[2.3 Configuration as code]
    |
    v
[2.4 Isolation and multi-tenancy]
    |
    v
[2.5 Access control and zero trust]
    |
    v
[2.6 The gap]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX008]

Learning outcomes

You will (1) map current research and practice on cloud configuration risk; (2) separate established findings from open problems; (3) locate the gap the study fills; (4) read sources critically.

2.1 Foundations

Mell and Grance (2011) define cloud computing by on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Self-service and elasticity are why configuration changes are frequent and why errors spread quickly. Armbrust et al. (2010) described the economics that made this model dominant.

For Meridian, self-service means every product team can deploy workloads without a ticket, and elasticity means a risky pod specification can run on many nodes within minutes. A daily scan sees such a configuration hours after it went live, which is the exposure window Amara sets out to measure.

2.2 Shared responsibility

AWS, Microsoft and Google all publish shared responsibility models: the provider secures the underlying infrastructure, the customer secures what they configure, including identities, network rules and workloads. Google's "shared fate" framing adds that providers should offer secure defaults and guidance. Most incidents studied in practice involve the customer's side.

Pod security settings sit firmly on Meridian's side of every provider's model: the managed Kubernetes service runs the control plane, but whether a team's pod runs privileged is Meridian's choice. That is why Amara's study can change the outcome at all, and why "shared fate" defaults matter for the clusters that have not yet switched.

2.3 Configuration as code

Rahman, Parnin and Williams (2019) found recurring security smells in infrastructure-as-code scripts, such as hard-coded secrets and overly permissive settings, showing that configuration errors are common and detectable by static checks. Shu, Gu and Enck (2017) found that many container images on a public registry contained known vulnerabilities, so what runs inside containers also matters.

Both findings motivate admission control from different directions. Rahman et al. show that risky settings in configuration files are common and visible to static checks, which is what admission enforcement does at deployment time. Shu et al. are a reminder of what admission checks of pod specifications cannot see: vulnerabilities inside the image, which Amara's study leaves to image scanning and lists as out of scope.

2.4 Isolation and multi-tenancy

Ristenpart et al. (2009) showed that co-residence in shared clouds raised information-leakage concerns, which pushed providers to strengthen isolation. For Amara's study it is a reminder that some risks sit with providers and are outside a customer's configuration choices.

For Amara's study this sets a boundary: admission enforcement can stop a team running a privileged container on a shared node, but it cannot fix a flaw in the provider's hypervisor. Her thesis states that exposure is measured only for risks under Meridian's control, so readers do not take a shorter exposure window as evidence that the whole cluster is safer.

2.5 Access control and zero trust

NIST SP 800-210 gives access control guidance for cloud systems and SP 800-207 describes zero trust architecture, where every request is evaluated by policy. Admission control is a policy enforcement point in this sense.

In Meridian's clusters the admission controller evaluates each pod specification against the Pod Security Standards before it is admitted, which is the policy decision point in zero-trust terms. Daily scanning, by contrast, evaluates what is already running. The difference between deciding before and detecting after is exactly what the exposure measure captures.

2.6 The gap

Studies show misconfigurations are common and detectable; guidance recommends preventive controls; but there is little published measurement of how much admission-time enforcement shortens exposure in real clusters, or what it costs in failed deployments. That is the gap.

Amara's literature matrix of 34 sources supports this statement: only four report any measured exposure time, and none compares admission control with scanning in the same organisation. Prof. Lund accepted the gap only after she removed one claim that rested on a vendor blog without data, so the gap statement rests on sources that report their method.

Worked example

Amara builds a literature matrix of 34 sources with columns for claim, method, data, setting and limitation. The method and data columns are what let her separate the four sources with measured exposure times from the rest.

Synthetic case. The matrix counts are synthetic.

Errors and limits

Vendor reports can be useful leads but are not evidence unless methods and data are shown.

Exercises

Synthesis

Map what is known, what is claimed and what is missing.

Continue studying — chapter 02 of 08

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →