Drill 47 — The God-Mode Service Account

Theme: Security & Trust Boundaries · Format: 20-min drill · Difficulty: core

The story

Years ago, someone created svc-platform with admin rights across the warehouse, the model registry, the feature store, and the ERP integration — "temporarily, to unblock the migration." It was too useful to kill; a dozen services now authenticate with it. Then a developer laptop is compromised, and on it: svc-platform's credential in a local config file. The attacker doesn't need to escalate privileges — there are no more privileges to escalate to.

⏸ Stop here and ask the room: the laptop is the entry point, not the failure. What's the failure?

Run it — facilitator script

Timing for a 20-minute session: 2 min story · 10 min staged questions · 3 min reveal · 5 min transfer.

How would you even scope the investigation — what couldn't this credential have touched?

Listen for: the honest answer — nothing — followed by the structural insight: forensic scoping by elimination requires scoped identities and per-identity audit trails to exist before the incident. The blast radius was set years ago, at design time; the investigation just reads it out.
Weak signal: "check the access logs." With one shared credential behind twelve services, the logs show svc-platform doing what svc-platform always does — the attacker's traffic is camouflaged inside legitimate traffic by construction.

Why do god-accounts accrete, and what makes killing them so hard?

Listen for: temporary-plus-useful equals permanent; each new consumer takes minutes to add and makes removal a bigger project; nobody owns the account, everybody depends on it; and the dependency graph was never written down, so decommissioning means archaeology. The accretion is an incentive structure, not an accident.
Weak signal: "someone was lazy" — a character diagnosis for a systems problem. The next migration under deadline pressure will produce the next god account unless the incentives change.

What's the migration path out?

Listen for: a stepwise decomposition — inventory consumers from credential-usage logs, mint per-service workload identities with minimal scopes, migrate consumers one at a time, shrink the old account's permissions as each one moves, then revoke. The sequence matters: scope shrinks behind the migration, so nothing breaks by surprise.
Weak signal: "just delete it and see what breaks" — which converts a security project into an outage, teaches the organization that decomposition is dangerous, and guarantees the next god account survives forever.

The reveal

The incident review's worst finding: with one credential holding everything, the forensic question "what did the attacker access?" is unanswerable by elimination — the answer is "potentially all of it," and the disclosure obligations follow from that word, potentially.

Why this happens — the mechanics

God accounts accrete because "temporary" plus "useful" equals permanent. The account was born from a real need with a deadline — unblock the migration — and once it existed, it became the path of least resistance for the next integration, and the next. Its scope never grew by decision; it grew by adoption. Nobody ever chose to build a skeleton key — they just kept finding one that already fit.

The cost asymmetry locks it in. Adding a consumer takes minutes and pays off immediately; removing the account is a quarter-long project whose benefit is invisible — until the laptop. Every quarter it survives, more services adopt it and the removal cost climbs, so the rational short-term choice is always "next quarter." That's how a temporary unblock outlives the migration it unblocked, the team that created it, and sometimes the person who remembers why.

Shared credentials also destroy the meaning of the audit trail. Twelve services and one attacker authenticate identically, so per-request logs can't separate them — the question "what did the attacker access?" becomes unanswerable by elimination, and disclosure law fills every unanswerable with the maximum: potentially all of it. The failure mode isn't just wide access — it's the loss of the ability to bound the damage after the fact, which is what turns one stolen laptop into a client-base-wide notification.

Diagrams

Problem — how the failure unfolds:

sequenceDiagram
    autonumber
    participant AT as Attacker
    participant LP as Dev laptop
    participant SVC as svc-platform
    participant ALL as Everything
    Note over SVC: Created with admin rights<br/>everywhere - temporarily
    Note over LP: Credential sits in a local<br/>config file (silent)
    AT->>LP: Laptop compromised
    LP-->>AT: svc-platform credential<br/>harvested (silent)
    AT->>SVC: Authenticates - no<br/>escalation needed,<br/>none left
    SVC->>ALL: Warehouse, registry,<br/>feature store, ERP<br/>all reachable
    Note over ALL: Forensics cannot scope<br/>what was touched
    Note over AT,ALL: Disclosure letter must say -<br/>potentially all of it

Solution — where the guardrails go:

flowchart TD
    A["Each service gets its own<br/>workload identity"] --> B["Minimal scopes per<br/>identity — no shared or<br/>god accounts"]
    B --> C["Segmentation: one<br/>compromise cannot cascade<br/>laterally"]
    D["Developer laptop compromised"] --> E["Stolen credential opens<br/>one narrow scope"]
    E -.-> M["Behavioral detection:<br/>service account calling<br/>from a laptop IP"]
    M -.-> AL["Alert fires on the first<br/>anomalous call"]
    AL --> F["Credential revoked — blast<br/>radius is one service"]
    C --> G["Forensics can answer<br/>exactly what was touched"]
    F --> G

What good looks like

Workload identity per service — platform-issued, automatically rotated identities (cloud IAM roles, SPIFFE-class systems) instead of static shared secrets; there is nothing to paste into a laptop config file.
Scopes that fit on a screen — each identity's permission list short enough to review in one sitting, with a named owner who can explain every line on it.
Usage-based pruning — quarterly recertification drops any permission unused in 90 days, so scope decays unless defended instead of accreting unless attacked.
Per-identity behavioral baselines — a service account authenticating from a laptop IP, a new network, or outside its normal call pattern pages immediately; that call is a scream, not a whisper.
Trust-zone segmentation — warehouse, model registry, feature store, and ERP (Enterprise Resource Planning) in separate zones, so no single identity can span them, whatever its scopes claim.
A break-glass path that isn't a god account — emergency admin access that is separate, time-boxed, audited per use, and alarmed loudly enough that using it is always a conversation.
The decomposition playbook, running — consumers inventoried from usage logs, per-service identities minted, one consumer migrated at a time, the old account's scope shrunk behind each move, revocation celebrated in the changelog.

The lesson

Blast radius is designed long before any attack: per-service identities with minimal scopes, no shared credentials, segmentation so one compromise doesn't cascade laterally, and unusual-usage detection per identity (a service account calling from a laptop's IP is a scream, not a whisper). Convenience accounts are the attacker's infrastructure, pre-built.

Named concepts: least privilege, lateral movement, workload identity, segmentation, behavioral detection on service accounts.

Real-world echoes

Capital One, 2019 — an attacker reached an over-permissioned cloud role through an SSRF (Server-Side Request Forgery) flaw in a misconfigured web application firewall, and used its credentials to read roughly 100 million credit applications from cloud storage. The entry point was one appliance; the blast radius had been designed years earlier, when the role's permissions were scoped far wider than its job required — this drill's lesson at production scale.

Transfer

Which single credential in our stack, if stolen tonight, forces the word "potentially all of it" into a disclosure letter? That's this quarter's decomposition project.

Make it a ticket: Pull the usage logs for our widest-scoped service account, list its consumers, and mint the first per-service identity off it this sprint — the deliverable is one consumer migrated and one permission removed from the old account.

Drill 42 — The Notebook on GitHub — the same rotation-is-scary finding one credential earlier, and the same silent accumulation of consumers nobody recorded.
Drill 48 — The Logs That Remembered Everything — "every engineer with log access, which is all of them" is a god-scope in miniature, pointed at data instead of infrastructure.
Drill 28 — The Friday Flag, theme 5 — the same "temporary" with no expiry mechanism: a flag left on there, an account left alive here, both waiting for their incident.