Kubernetes attack path analysis
Attack path analysis traces the reachable chains an attacker could follow from an entry point (an internet-exposed pod, a leaked credential, a compromised image) to a high-value target (cluster-admin, production secrets, customer data). It does this by building a graph of every cluster resource and relationship, then running path queries. Instead of a flat list of CVEs, the output is the small number of actual routes an attacker could take, plus the fix that breaks each one.
How attack path analysis works
A Kubernetes cluster can be modelled as a graph. Pods connect to ServiceAccounts, which connect to RoleBindings, which connect to ClusterRoles, which connect to verbs on resources. Pods run Images that contain Packages that have CVEs. Services expose Pods to the internet. Network policies (or the absence of them) control which namespaces can talk to which.
Attack path analysis loads that graph into a graph database and runs reachability queries:
- "From any internet-exposed pod, can I reach a ServiceAccount bound to
cluster-admin?" - "From any pod with a critical unpatched CVE, can I reach a Secret in the
productionnamespace?" - "If this RoleBinding is compromised, what workloads, secrets, and namespaces are in the blast radius?"
Every hit is an attack path: an ordered chain of nodes where each hop is a real capability in the cluster.
Why attack paths complement CVSS
CVSS ranks a CVE in isolation. It does not know whether the vulnerable package is loaded at runtime, whether the pod is on the internet, or whether that pod has meaningful permissions.
Attack path analysis ranks findings by position on a real chain to a high-value target. A medium-severity CVE on a pod that reaches cluster-admin may be more urgent than a critical CVE on an unused sidecar in an isolated namespace. Graph-based prioritization lets a team focus on the small number of findings that actually sit on a reachable path, without dropping genuinely severe issues.
Entry points Juliet tracks
- Internet exposure. Services of type LoadBalancer or NodePort, Ingresses with public endpoints.
- Compromised images. Known-malicious digests (see the axios npm compromise and the Trivy supply chain attack).
- Credential leaks. Service account tokens, cloud credentials, or kubeconfigs found in env vars or mounted secrets.
- Weak admission. Privileged pods, hostPath mounts, containers running as root.
Blast radius: the inverse of an attack path
Given a resource, blast radius asks "if this is compromised, what else can the attacker reach?" Attack path asks "what can reach this?" Both are the same graph traversal run in opposite directions.
Juliet computes both for every critical resource in the cluster. When an upstream dependency such as axios or Trivy gets compromised, blast radius returns the affected pods, namespaces, clusters, and customers in one query. See blast radius analysis.
Frequently asked about kubernetes attack path analysis
What graph database do attack path tools use?
Most use Neo4j or a similar property graph store. Juliet uses a dedicated per-customer Neo4j instance. The property-graph model maps naturally to Kubernetes: nodes are resources, edges are "runs", "assumes", "binds", "exposes", and so on.
Is attack path analysis the same as lateral movement detection?
Related but not identical. Attack path analysis is proactive: find the paths before an attacker does. Lateral movement detection is reactive runtime observation of an attacker traversing the graph. A full Kubernetes security program usually does both.
How long does attack path analysis take to run on a large cluster?
Once the graph is loaded, queries return in milliseconds. That is the point of a graph database. Initial graph construction on a hundred-node cluster typically takes a couple of minutes.
Can attack path analysis see across clusters?
If the security platform ingests all clusters into a single tenant graph, yes. Juliet supports cross-cluster paths, which matter for shared container registries, shared Vault instances, and leaked tokens that work against multiple control planes.
Does attack path analysis generate false positives?
Fewer than flat CVE lists, but not zero. A reachability match assumes the attacker can successfully chain every hop. Some capabilities are gated by network policy, runtime controls, or admission rules that a static graph may not see. Good platforms weight paths by exploitability and let operators close or suppress paths that are mitigated out of band.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.