Agent-based Kubernetes security posture management

Most Kubernetes findings are noise.
Prove which ones are reachable.

KubeDefence correlates exposure, workload, identity and data into attack paths — then shows the single fix that breaks the most paths. Every hop carries the evidence that proves it, collected read-only from your own cluster.

Become a design partner How choke points work

Self-hosted in your account Read-only collection Data stays in-country

Attack path · prod-cluster-01 LIVE GRAPH

94exploitability · critical

Public ingress reaches a running workload whose service account can read a customer-data store.

0.0.0.0/0Public internet

routes to

ingress-nginxIngress · api.example.com/v1/*

forwards to

payments-apiDeployment · 6 replicas running

mounts token of

payments-saServiceAccount · cloud-role annotated

can assume

payments-roleCloud IAM role · unscoped object storage

reads

cust-dataObject storage · classified PII

Choke point: scope that one cloud role and three separate attack paths stop existing.

The problem

Nobody gets breached by a single misconfiguration.

Real compromise is a chain: an exposed entry point, a reachable workload, an over-privileged identity, and data at the end of it. Tools that grade each link in isolation hand you four medium findings and no indication that together they are critical.

A list of findings

1,284 open issues, sorted by severity

Severity describes how bad something is in theory. It says nothing about whether an attacker can reach it in your cluster — so the queue never gets shorter, and eventually the team stops believing it.

Everything looks equally urgent

No link between related issues

Cloud-managed defaults flagged critical

Screenshots and spreadsheets at audit time

A ranked set of paths

14 exploitable paths, 3 fixes that break 11

KubeDefence chains findings into routes an attacker could actually walk, scores them on reachability rather than severity alone, and identifies where one change collapses several paths at once.

Ranked by proven reachability

Every hop carries its own evidence

Managed defaults suppressed, with the reason shown

Evidence an auditor can actually check

What makes us different

Find the one fix that breaks the most attack paths.

Several paths usually pass through the same root cause. KubeDefence computes that intersection and tells you which single change eliminates the largest number of routes — so Monday morning is three fixes instead of three hundred tickets.

Simulate the fix before you make it. Watch which paths disappear, confirm nothing important is left standing, then apply the generated Kyverno, Gatekeeper or NetworkPolicy manifest through your own GitOps pipeline.

Try it on your cluster See the console

Block pod access to the node metadata endpoint

91 LoadBalancer → checkout-api → metadata → node role BROKEN

86 devops-tools pod → metadata → registry push access BROKEN

78 CI runner → node credentials → cloud inventory read BROKEN

74 hostNetwork pod → metadata endpoint BROKEN

61 sidecar egress → metadata token fetch BROKEN

94 Public ingress → payments-api → cloud role → storage BROKEN

79 Secret in ConfigMap → readable in namespace BROKEN

One change at the node pool level.

0 of 7 paths broken

How it works

Collect, correlate, prioritise, prove.

A lightweight DaemonSet collects read-only signals from inside the cluster. Nothing leaves your account, and the agent never needs write access to production.

Collect

Nodes, workloads, images, RBAC, network policy and exposure — gathered read-only, on a schedule and on demand.

Correlate

Findings on the same workload chain into typed paths across network, workload, identity, node and data — every edge labelled with the relationship.

Prioritise

Scoring weights internet reachability, privilege gained, blast radius and whether the workload is actually running — not severity labels alone.

Prove

Each hop exposes the API object, resolved RBAC and computed reachability behind it, plus the fix — retained as an evidence trail.

The console

Built for the questions that come up in a real review.

What is exposed, which workload is reachable, what can that identity do, and what proves the fix. Five screens over one evidence layer.

console.kubedefence.ai/overview

Posture overview. Fleet compliance, critical findings and cluster freshness. When there is no prior scan to compare against, the dashboard says so rather than inventing a trend.

Evidence, not assertions

Every finding traces back to something an auditor can check.

Framework names are easy to put on a website. What matters at audit time is whether each control links to the specific object and scan that produced the result — and whether a manual attestation is clearly labelled as one.

RBI Cyber Security Framework

RBI

Audit-ready evidence for regulated financial workloads: access governance, vulnerability management, monitoring and resilience.

Access governanceVulnerability mgmtMonitoringResilience

PCI DSS 4.0

PCI

Segmentation of cardholder workloads, least privilege, vulnerability remediation and audit logging.

SegmentationLeast privilegeAudit logging

CIS Kubernetes Benchmark

CIS

Control-plane settings, RBAC and service accounts, pod security and network policy — mapped to the resources that fail them.

API serverRBACPod securityNetworkPolicy

SEBI CSCRF

SEBI

Cyber security and resilience expectations for market infrastructure institutions and regulated intermediaries.

GovernanceResilienceEvidence retention

CERT-In directions

CERT-In

Logging and incident-reporting obligations, including retention windows and the evidence needed to answer a query.

Log retentionIncident reporting

NIST SP 800-190

NIST

Container security guidance across images, registries, orchestrator and host, tied back to live cluster state.

ImagesRegistryOrchestratorHost

// evidence attached to one hop of an attack path Node pool worker-prod-a metadata token requirement: optional metadata hop limit: 2 expected: required / 1 ✓ pod network can reach the metadata endpoint ✓ node credentials retrievable without a token ✓ verified read-only, no exploitation performed

Secret values are never collected or transmitted. High-entropy material is reported by location and reason, never by content.

Architecture

Your cluster, your account, your data.

Agentless scanners see what the cloud API exposes. Reachability, running workloads and resolved RBAC need a view from inside the cluster — without handing over write access.

Read-only by design

The agent's ServiceAccount binds to read verbs. Restore and remediation actions stay gated behind product RBAC and explicit approval.

Self-hosted, in-country

API, database and evidence run in your own cloud account and region. Nothing is shipped to a vendor-controlled multi-tenant backend.

Evidence you keep

Scan history, finding lifecycle and full cluster backups land in storage you own, so audit evidence outlives any vendor relationship.

Where we fit

Honest about the category.

Runtime detection, CVE reachability and AI assistants are becoming table stakes — most serious tools will have them. These are the axes we think are actually worth choosing on.

Capability	Broad CSPM suite	Agentless K8s scanner	KubeDefence
Kubernetes depth	One service among hundreds	Good breadth, no in-cluster view	Kubernetes-native, in-cluster agent
Prioritisation	Severity plus cloud context	Severity and CVE score	Proven reachability, path-level
Choke-point analysis	Not offered	Not offered	Core to the workflow
Evidence per finding	Summary reporting	Scan output	Object-level proof, per hop
Deployment	Vendor SaaS	Vendor SaaS	Self-hosted, your own account
Runtime detection	Mature	Varies	Design-partner track, not shipped

Written as fairly as we can manage, but we are the interested party here — evaluate all of it in your own cluster.

Roadmap

What works today, and what does not yet.

We would rather lose a deal than oversell a capability. This is the current state.

Shipping now

Posture, paths and evidence

Agent onboarding and cluster inventory
Grouped findings with affected resources
Attack paths and choke-point analysis
Policy generation: Kyverno, Gatekeeper, native
CSV and PDF reporting, Slack alerting

In progress

Cloud correlation and images

Image scanning hardened for production evidence
Customer-owned cluster backups
Cloud IAM, firewall and endpoint correlation
Drift and audit change signals
Cross-namespace lateral movement paths

Design partners

Runtime defence

Falco and eBPF detections
Container escape and reverse shell indicators
Sensitive file tampering
Unexpected egress
Admission-time enforcement

Pricing

Scales with the surface you protect.

Priced on clusters and nodes, plus how long you need evidence retained. We are early, so design partners get direct access to the team building it.

Pilot

For teams validating KSPM on a small Kubernetes footprint.

Free during pilotUp to 2 clusters · 30-day evidence retention

Posture scans every 5 hours
Inventory and grouped findings
Attack paths and choke points
CSV and PDF export

Start a pilot

Most teams

Fleet

For shared Kubernetes fleets that need attack-path context and audit evidence.

Per cluster, per nodeAnnual, with committed evidence retention

Everything in Pilot
Regulated evidence packs
Image scanning and cluster backup
Policy generation and remediation tracking
Slack alerting and scheduled reports

Talk to us

Regulated

For organisations with data residency and audit obligations.

CustomSelf-hosted in your own cloud account and region

Everything in Fleet
Extended evidence retention
Auditor workflow and export formats
SSO and granular RBAC
Onboarding support

Request details

Questions

The things people ask first.

What access does the agent need?

A ServiceAccount bound to read verbs on cluster resources. It does not need write access and it does not need cluster-admin. The Helm chart shows exactly what it binds to — render it with helm template before installing anything.

Does any cluster data leave our account?

No. The API, database and evidence store run in your own cloud account and region. There is no vendor-side multi-tenant backend receiving your inventory or findings.

Do you collect secret values?

Never. When a credential is found in the wrong object — a token sitting in a ConfigMap, for example — we report the location and why it matters. The value itself is not read into the payload, stored, or transmitted.

How is this different from the CSPM we already have?

Broad CSPM suites treat Kubernetes as one service among hundreds and prioritise by severity. We work inside the cluster, chain related findings into attack paths, and rank by whether a path is reachable. Most teams run both.

Do you flag provider-managed defaults as critical?

We work hard not to. Managed control-plane identities and the CNI's privileges are provider-managed and unavoidable — flagging them as critical destroys trust in the tool. Suppressed findings are still visible, with the reason stated.

Is runtime detection available?

Not yet. Falco and eBPF-based detection is a design-partner track, not a shipped feature. If runtime is your immediate requirement, we are not the right tool today — and we will say so on the first call.

Design partner programme

Run it against your own cluster before you believe any of this.

Install the agent on one non-production cluster, complete a scan, and see whether the paths we surface match what your team already suspects. If it is not useful, tell us why — that feedback is the point of the programme.

Become a design partner Walk through the console

Or email us directly at contact@kubedefence.ai

Most Kubernetes findings are noise.Prove which ones are reachable.