Threat modeling

Four questions

Lesson 1 was a list of what's wrong. A list doesn't say what to fix first, or what's missing from it. Threat modeling does, by starting from the other side: what would someone want from this, and how would they get it? Adam Shostack's version is four questions:

1. What are we working on? Draw the system: its parts, its data, and how they talk.
2. What can go wrong? Walk the drawing, part by part, with a checklist so nothing is skipped.
3. What are we going to do about it? For each threat: fix it, reduce it, accept it, or hand it to someone else.
4. Did we do a good job? Check the fixes worked, and redo the model when the system changes.

It's not a document for an audit. Done well, it's an hour with a whiteboard before building something, and again when something big changes. Done here, it's for a system that already exists, which is the common case.

What are we working on?

Three kinds of fact go into the drawing: what's worth protecting, the ways in, and the data flows. The script for this lesson, security02.sh, gathers them, read-only.

The assets

Every Secret in the cluster, by name and type, never the values:

kubectl get secrets -A -o json | jq -r '.items[] | [.metadata.namespace, .metadata.name, .type, (.data // {} | length), (if ([.metadata.ownerReferences[]? | select(.kind=="SealedSecret")] | length) > 0 then "sealed" else "-" end)] | @tsv'

• .data // {} | length counts the keys in each Secret without printing them.
• ownerReferences ... SealedSecret: the Sealed Secrets controller marks each Secret it makes as owned by its SealedSecret.

argocd       argocd-notifications-secret                     Opaque                               0  -
argocd       argocd-redis                                    Opaque                               1  -
argocd       argocd-secret                                   Opaque                               5  -
bookshop     bookshop-db                                     Opaque                               1  sealed
kube-system  bootstrap-token-abcdef                          bootstrap.kubernetes.io/token        6  -
kube-system  sealed-secrets-keygzzt8                         kubernetes.io/tls                    2  -
monitoring   alertmanager-heartbeat                          Opaque                               1  sealed
monitoring   alertmanager-slack                              Opaque                               1  sealed
monitoring   grafana-admin                                   Opaque                               2  sealed
monitoring   monitoring-kube-prometheus-prometheus-token     kubernetes.io/service-account-token  3  -
...

(20 in all; the rest are Prometheus's and Alertmanager's generated settings and certificates.) Four are sealed: their encrypted form is in Git, in a public repository. They're safe exactly as long as one Secret stays safe: sealed-secrets-keygzzt8, the controller's private key. Whoever has it can decrypt every SealedSecret in the repository's history, forever. That makes it the cluster's crown jewel.

Two more worth knowing. argocd-secret holds Argo CD's admin password hash and the key it signs logins with. bootstrap-token-abcdef is the token new nodes use to join the cluster; kind uses the same, publicly documented token on every cluster it makes, which is harmless when the API is only on 127.0.0.1, and something no real cluster should ever have.

And on the laptop:

Files on this laptop that unlock things, by name and permissions only:
  .argocd-admin                -rw-------
  .sealed-secrets-key.yaml     -rw-------
  .grafana-admin               -rw-------
  .slack-webhook               -rw-------
  .healthchecks-ping           -rw-------
  .healthchecks-api            -rw-------
  /Users/mayowababatola/.kube/config -rw-------

(of 6 secret files in the repo folder, how many Git is ignoring)
6

All readable only by you, and all six in the repository folder ignored by Git. That's right. But look at what's together in one place: the kubeconfig, which is cluster-admin; the backup of the Sealed Secrets key; and every other password and address. One laptop is every asset at once.

The ways in

What can change what runs in the cluster? Every Argo CD Application, and how it syncs:

alloy              default  grafana.github.io/helm-charts                1.15.0   auto  prune
blackbox-exporter  default  prometheus-community.github.io/helm-charts   11.20.2  auto  prune
bookshop           default  github.com/Kwamib/gitops-practice.git        main     auto  prune
bookshop-staging   default  github.com/Kwamib/gitops-practice.git        main     auto  prune
guestbook          default  github.com/argoproj/argocd-example-apps.git  HEAD     auto  prune
loki               default  grafana-community.github.io/helm-charts      21.0.0   auto  prune
monitoring         default  prometheus-community.github.io/helm-charts   92.18.0  auto  prune
monitoring-config  default  github.com/Kwamib/gitops-practice.git        main     auto  prune
root               default  github.com/Kwamib/gitops-practice.git        main     auto  prune
sealed-secrets     default  bitnami.github.io/sealed-secrets             2.22.0   auto  prune

Every one applies changes by itself, and deletes what's removed from Git. That's the point of GitOps, and it means whoever can change those sources changes the cluster. Every one is in Argo CD's default project, the setting that limits what an Application may deploy from and to:

{"sourceRepos":["*"],"destinations":[{"namespace":"*","server":"*"}],"clusterResources":[{"group":"*","kind":"*"}]}

No limits at all: any repository, any namespace, any cluster-wide resource, ClusterRoleBindings included. And Argo CD's controller can do it:

$ kubectl auth can-i '*' '*' --all-namespaces --as=system:serviceaccount:argocd:argocd-application-controller
yes

$ kubectl auth can-i create clusterrolebindings --as=system:serviceaccount:argocd:argocd-application-controller
yes

(Ignore the warning printed with the second: clusterrolebindings aren't in a namespace, so kubectl notes the namespace doesn't apply.) So the real question is: who can change the sources? The repository:

$ gh api repos/Kwamib/gitops-practice --jq '{visibility, default_branch, allow_forking}'
{"allow_forking":true,"default_branch":"main","visibility":"public"}

branch protection: Branch not protected

$ gh api repos/Kwamib/gitops-practice/collaborators --jq '.[] | "\(.login) \(.role_name)"'
Kwamib admin

rulesets: 0

• branches/main/protection asks GitHub for the branch's rules: required reviews, required checks, no force-pushes. None are set.
• collaborators: only one account can push, the owner.

Public is fine, and intended: it's a teaching repository, and anyone can read it but only Kwamib can push. But nothing stands between a push to main and the cluster: no pull request required, no check, no review. Every lesson's script has merged its own pull requests, which works because nothing is required. So the account, and anything holding its token, such as the gh login on the laptop, is a way in. And one more source, not yours:

$ gh api repos/argoproj/argocd-example-apps --jq '{full_name, visibility, pushed_at}'
{"full_name":"argoproj/argocd-example-apps","pushed_at":"2026-05-19T15:14:21Z","visibility":"public"}

$ git ls-remote https://github.com/argoproj/argocd-example-apps.git HEAD | cut -c1-12
8088f4c0d970

The guestbook deploys whatever is at HEAD of someone else's repository, today commit 8088f4c0d970. It's Argo CD's own, well looked after, and last changed in May. But if anyone ever pushed something malicious to its guestbook folder, Argo CD would apply it here within minutes, and the default project would let it create anything, anywhere in the cluster.

The data flows

What Prometheus collects, by job:

1  apiserver
3  bookshop
2  bookshop-banner
3  bookshop-up
2  coredns
1  kube-state-metrics
6  kubelet
1  monitoring-grafana
2  monitoring-kube-prometheus-alertmanager
1  monitoring-kube-prometheus-operator
2  monitoring-kube-prometheus-prometheus
2  node-exporter

Logs: every container's, through the Kubernetes API, to Loki:

  role = "pod"
    url = "http://loki.monitoring.svc:3100/loki/api/v1/push"

What leaves the cluster, from Alertmanager's settings:

  heartbeat: webhook_configs
  bookshop-team: slack_configs
  bookshop-team: webhook_configs
  api_url_file: /etc/alertmanager/secrets/alertmanager-slack/url
  url_file: ""
  url_file: /etc/alertmanager/secrets/alertmanager-heartbeat/url

Alerts to Slack and the in-cluster receiver, and the heartbeat to Healthchecks.io, both addresses read from mounted Secrets. (The empty url_file is the in-cluster receiver's, whose plain address is set directly.) And what comes in, everything the cluster fetches from:

   1   bitnami.github.io
   5   github.com
   1   grafana-community.github.io
   1   grafana.github.io
   2   prometheus-community.github.io
   14 docker.io
    1 gcr.io
    1 ghcr.io
    1 public.ecr.aws
   16 quay.io
    9 registry.k8s.io

Eleven outside places: five hosts for Git and Helm charts, six image registries. Each is trusted to send exactly what was asked for. Chart versions and image tags are pinned, so a change on their side shouldn't arrive by itself, but a tag or a chart version can be republished with different contents (Lesson 6 is about knowing when that happens).

The drawing

All of that, as a data-flow diagram: the parts, the stores of data, the flows between them, and the trust boundaries, the lines where control changes hands:

The numbered markers are the threats from the rating below, placed where each one lives. Every arrow that crosses a red dashed line crosses a trust boundary, and that's where threats live. Five boundaries here: the laptop, GitHub, the outside sources, the cluster, and the outside services. Inside the cluster there's no boundary at all, which is Lesson 1's NetworkPolicy finding, drawn.

What can go wrong? STRIDE

Staring at a diagram asking "what could go wrong?" finds the obvious threats and misses the rest. STRIDE, from Microsoft, is a checklist: six kinds of threat, each the opposite of something you want.

The method: take each part and each arrow of the diagram, and ask all six. Most cells are empty or minor; a few aren't. Here are the ones that aren't, for the parts that matter:

• The laptop. Spoofing: its gh login can push as you; its kubeconfig is you, as cluster-admin. Information disclosure: the Sealed Secrets key backup decrypts every SealedSecret in a public repository's history. One piece of malware, one stolen unlocked laptop, or one bad git add -f is everything at once.
• main on GitHub. Tampering: a push, from you or from anything holding your token, deploys itself within minutes: no pull request, no check. Repudiation: commits aren't signed, so a commit "from you" proves nothing.
• The guestbook's repository. Tampering, then elevation of privilege: a commit there becomes resources here, and the default project allows any of them, cluster-wide.
• Argo CD. Elevation of privilege: it can do anything, so anything that can tell it what to do, any source repository, can too. That's why its sources matter more than its pods.
• A bookshop pod (Lesson 1). Elevation of privilege: nginx runs as root. Information disclosure and tampering: from it, every metric, every log, and alerts silenced.
• Monitoring. Tampering: a silence hides the alert that would have caught the rest. Repudiation: no audit log of who made it.
• The outside sources. Tampering: a chart or image republished under the same version.

Rating them

Not every threat is worth the same effort. A simple rating: likelihood (how easily, how often) times impact (how much it would hurt), each from 1 to 3. It's rough on purpose; the point is the order, not the numbers.

The order changed. Lesson 1's findings were all inside the cluster, because that's where a first look looks. The threat model puts the laptop at the top, tied with a compromised pod, and puts two of the quickest fixes in the whole track, branch protection and removing the guestbook, right behind. Neither appeared in Lesson 1 at all.

Why the laptop scores a 2 for likelihood: it's where you browse, install tools and open attachments, and it's the one machine holding every key. Why a push to main scores a 1: your GitHub account has two-factor authentication, and only you can push. A 1 isn't a 0, and the impact is the whole cluster.

What are we going to do about it?

Four kinds of answer, for every threat:

• Remove the thing that's at risk. The guestbook was a first-lesson example, and nothing depends on it.
• Reduce the likelihood or the impact. Most of the list.
• Transfer it to someone better placed: a managed service, an insurer, a vendor's contract.
• Accept it, on purpose, and write down why. A pod filling a laptop's node is acceptable; the same in production isn't.

Three are quick enough to do before the next lesson:

1. Remove the guestbook. Delete argocd/guestbook.yaml in a pull request; the root Application prunes it, and the guestbook namespace's contents go with it.
2. Protect main. In the repository's settings, a ruleset for main: require a pull request, block force-pushes and deletion. With one person, the review rule has to allow you to merge your own; the value is that nothing reaches the cluster without passing through a pull request, where checks can run.
3. Move the Sealed Secrets key backup off the laptop's repository folder. Into the password manager, or an encrypted file somewhere else. It's ignored by Git today; the point is that one mistake shouldn't be enough to publish it.

The rest are the track: Lesson 5 for secrets and encryption at rest, Lesson 6 for images and charts, Lesson 9 for the compromised pod, Lesson 10 for the audit log.

Did we do a good job?

Two checks, after the fixes: does the threat model still match the system (a new app, a new outside service, a new person with access each mean redrawing), and did each fix actually work, tested the way the first look tested the problems. For the guestbook, kubectl get ns guestbook should say it's gone; for branch protection, a direct push to main should be refused. A threat model that's never checked is a drawing.

Spot the problem

Work out what's wrong before you read the explanation.

"The repository's public, but the secrets are sealed, so it's fine." A team keeps their cluster's configuration in a public GitHub repository, with every Secret sealed. That's the textbook way. One of them keeps the backup of the Sealed Secrets private key in the repository's folder, in .sealed-secrets-key.yaml, ignored by Git, just like this one. A year later, someone tidies up the .gitignore file and removes the line. The next git add . picks up the key. What does that cost? Every secret the repository has ever held. Sealing protects a secret with one key; with the key public, anyone can decrypt every SealedSecret in the repository's history, including ones rotated long ago that may still work somewhere. Deleting the commit doesn't help: public repositories are copied by forks and by automated scanners within minutes. The model's answer is that the key's location was the threat, not the .gitignore line: one ordinary change was enough to publish it. Keep the key's backup somewhere one git add can't reach, and if it ever leaks, treat every sealed secret as leaked: make a new key, re-seal, and change every value.

Where you are now

You can model a system's threats: draw it, walk it with STRIDE, rate what you find, and decide what to do about each. The practice setup's model put the laptop and the deploy path at the top, ahead of everything inside the cluster, and gave three quick fixes. The next lesson goes to the most common target of all, an ordinary Linux server, and hardens one from scratch: logins by key only, a firewall, automatic security updates, and the least access for every user.

Check yourself

Key terms

• Threat modeling: working out what an attacker would want, how they'd get it, and what to do about it, before or after building.
• Asset: anything worth protecting: data, secrets, access, availability.
• Data-flow diagram: a drawing of a system's parts, data stores and flows, with its trust boundaries.
• Trust boundary: a line where control changes hands, such as between GitHub and the cluster.
• Attack surface: every way in to a system, together.
• STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
• Non-repudiation: being able to prove who did something.
• AppProject: Argo CD's limit on what an Application may deploy, from which repositories, to where.
• Branch protection: GitHub's rules for a branch, such as requiring a pull request before changes reach it.
• Risk response: removing, reducing, transferring or accepting a risk.

Go deeper

• Adam Shostack's Threat Modeling Manifesto (opens in a new tab), written with others who do this for a living, and his book Threat Modeling: Designing for Security.
• OWASP's Threat Modeling Cheat Sheet (opens in a new tab).
• Argo CD's documentation on projects (opens in a new tab), and GitHub's on rulesets (opens in a new tab).
• Try: draw a data-flow diagram for something of your own, such as a website you run, and do STRIDE on every flow that crosses a boundary. Which of your threats isn't about the code at all?
• Try: the three quick fixes from this lesson, then check each worked: the guestbook namespace gone, and a direct git push to main refused.