Chapter 4 — Data models | Technologist 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.

Chapter 4 — Data models

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 What to record"]
  N2["4.2 Consistent names"]
  N3["4.3 Identifiers"]
  N4["4.4 Tables and files"]
  N5["4.5 Keeping data current"]
  N6["4.6 Sensitive fields"]
  N7["Checking the model"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 What to record"]
  N2["4.2 Consistent names"]
  N3["4.3 Identifiers"]
  N4["4.4 Tables and files"]
  N5["4.5 Keeping data current"]
  N6["4.6 Sensitive fields"]
  N7["Checking the model"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 What to record]
    |
    v
[4.2 Consistent names]
    |
    v
[4.3 Identifiers]
    |
    v
[4.4 Tables and files]
    |
    v
[4.5 Keeping data current]
    |
    v
[4.6 Sensitive fields]
    |
    v
[Checking the model]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) model hosting assets as records; (2) choose fields that answer security questions; (3) keep records consistent.

4.1 What to record

To answer "which clients use this image?", Cobalt needs records linking client, cluster, workload and image. Priya drafts a simple model with those four fields plus an owner. Each field in the model answers part of a real question. Client and workload say what is affected, cluster says where to look, image says what runs, and owner says who must act on a finding. During the advisory, the missing piece was the link between image and client: staff could name the images in use but not which clients ran them. Priya keeps the model small on purpose, since every extra field is one more value someone must keep correct, and a field nobody maintains soon becomes misleading.

4.2 Consistent names

Two staff wrote the same image as "node14" and "node:14". Inconsistent names break searches. Priya proposes always recording the full image reference, including registry and tag. The two spellings looked obvious to the people who typed them, yet a search for node:14 missed every record written as node14. A full reference such as docker.io/library/node:14 also records where the image came from, which matters because public images are treated differently from Cobalt's own builds. Priya adds a rule that references are copied from the cluster rather than typed, which removes the chance of a new spelling appearing. Later she records digests as well, since tags alone can be moved.

4.3 Identifiers

Each record needs a unique identifier, so updates change the right row. Workload names alone are not unique because two clients both have a workload called web. Priya's identifiers combine client and workload name, so the two web workloads become distinct records that can be updated separately. Without that, an update meant for one client's web workload could silently overwrite the other's image, and an advisory answer could name the wrong client. Identifiers should also stay stable when details change: if a workload moves to a new image, its identifier stays the same and only the image field changes, so its history remains easy to follow.

4.4 Tables and files

Records can live in a spreadsheet, a CSV file or a database. For now Cobalt uses a CSV file kept in its configuration repository, so changes are reviewed. A CSV file is plain text, so the repository can show exactly which line changed, who changed it and when. That is enough for a company of Cobalt's size, and the file opens in any spreadsheet program for staff who prefer tables. A database would make sense later if many tools needed to query the records at once. Priya notes one limit of the CSV approach: two people editing at the same time can produce conflicting changes, which review catches but does not prevent.

4.5 Keeping data current

A model is useful only if it is updated. Priya suggests generating the records from the clusters automatically each night rather than typing them. Typed records go stale the moment someone deploys a new workload and forgets to update the file. A nightly export reads the workloads and images directly from each cluster and rewrites the CSV, so the records describe what actually ran that night. Any difference from the previous night appears as a change in the repository, which is itself useful: a new workload or image shows up for review the next morning. The export needs read-only access to the clusters and nothing more.

4.6 Sensitive fields

The model avoids storing secrets or patient data; it describes systems, not people. Keeping secrets and patient data out of the model has two benefits. The inventory file can be shared with any engineer who needs it and stored in the configuration repository without becoming a target or a privacy problem. If Riverside Dental's patient details appeared in it, the file would need the same protection as the booking database. Priya checks her draft for fields that might carry sensitive values by accident, such as environment variables copied from a deployment, and removes them. The owner field names a team rather than a person's contact details, so the model records responsibility without personal information.

Checking the model

Priya tests her model by asking it three real questions: which clients use a given image, which workloads belong to one owner, and which clusters hold a client's systems. If a question cannot be answered from the fields, the model needs another field. The test shows that she also needs the namespace, because two clients share one cluster, so she adds it.

Worked example

Priya builds the CSV for three clients and finds that the same name "web" appears twice. She adds a client prefix to make identifiers unique, then re-runs her script, which now reports each client's images correctly.

Synthetic case. Records are synthetic.

Errors and limits

A model that tries to capture everything becomes too hard to maintain; start with fields that answer real questions.

Exercises

EX010 — Model fields. List the fields in Priya's first model. Rubric: 3 = client, cluster, workload, image, owner; 2 = three or four; 1 = fewer; 0 = none.
EX011 — Naming problem. What naming problem did Priya find? Rubric: 3 = node14 vs node:14; use full image reference; 2 = partial; 1 = vague; 0 = none.
EX012 — Unique ids. How were duplicate workload names resolved? Rubric: 3 = client prefix; 2 = partial; 1 = vague; 0 = none.

Synthesis

Model only what answers real questions, and keep names and identifiers consistent.

Continue studying — chapter 04 of 30

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