A living model of a cloud estate

By Kyle Kilmetis · Google Cloud Certified · Cloud Computing Principal Altitude

A reference model for moving posture management from a queue of findings to a queryable representation of the estate, so that exposure paths, architectural patterns and evidence are questions you can ask rather than archaeology you have to do.

GCPsecurity posturegraphevidenceautomationinfrastructure as code

The shift

Security tooling is very good at producing findings and very bad at producing understanding. A posture platform will tell you that a bucket is public. It will not tell you whether that bucket sits behind three layers of a topology that make the finding irrelevant, or whether it is the one exposure that matters this quarter.

This reference model is designed to move posture management from isolated findings to a queryable model of the estate: a representation that a person and a machine can both query, drawn from the underlying inventory and posture sources, and enriched with the architecture-specific context that no scanner can infer.

What the model holds

  • Assets and their relationships. Projects, networks, workloads, identities, pipelines, data stores and the edges between them: who can reach what, who can assume what, what deploys what, what publishes to what.
  • Exposure paths, precomputed. Not "this is public" but "from the internet, through this load balancer, to this workload, with this service account, to this dataset." A path is a first-class object with a severity that comes from what is at the end of it.
  • Architectural patterns, tagged. A workload that matches the standard landing pattern gets a tag. One that does not gets a different tag and a question.
  • Evidence, collected on a schedule. Screenshots decay. Queries do not. Every control represented by the reference estate is a query that runs on a schedule and stores its result with a timestamp. Audit season becomes a report, not a scramble.

How it is used

  1. Triage by path, not by finding. Findings collapse into far fewer paths, and the paths get owners.
  2. Design review with the model open. A proposed architecture is checked against the patterns the estate already has. Novelty is allowed; unexamined novelty is not.
  3. Policy in code, checked before deploy. The same rules that produce findings after the fact are expressed as checks in the delivery pipeline, so most findings never happen. This is the whole point of shifting quality left: the model tells you which rules are worth encoding.
  4. Diagrams generated, never drawn. Architecture pictures are produced from the model, so they are right on the day you read them.

What I would say at a conference

Visibility is the precondition for reliability, not just for security. A model built to answer "what is exposed" is the same model that answers "what depends on this" and "what breaks if that fails." Once security and platform stakeholders query the same graph, the argument about whose problem it is gets shorter.