kubectl only, and reaches no
Komodor backend and no external data source. This page covers the one scope decision that matters
before you install it, the access it needs, and where it stops.
What it does
You name a resource — a kind and a name — and it investigates that resource: reconstructing what changed around it, reading the state of its dependencies, and working through a domain-specific method for whatever it is. It is built from Klaudia’s root-cause knowledge, which is why it knows how to diagnose a Kafka consumer group or a stuck Istio sidecar rather than only reading events. It returns a structured root-cause analysis for that one resource.What it reads
Read-onlykubectl against the cluster it runs in. There is no connection to bind, because the
ServiceAccount’s own permissions are simultaneously its only data source and its only security
boundary.
Before you deploy
The self-hosted install renders a values file that binds the agent’s ServiceAccount to Kubernetes’
own aggregated
view role, plus a supplemental role for the cluster-scoped reads view omits.
Leaning on the built-in role means custom resources are covered as they are installed, rather than
by a list that goes stale.
The one grant that is not read-only
pods/exec is granted cluster-wide, because several domain methods diagnose from inside the pod —
that state exists nowhere else, and at install time nobody knows which namespace an incident will
land in.
It is a separate value from the read access, so you can narrow or remove it:
What may actually run through that grant is decided by the agent itself, not only by RBAC. It admits
a short list of read-only diagnostics and refuses everything else, interactive sessions included.
No database client is on that list, so a Postgres incident that turns on a grant or a row-security
policy is out of reach — and the agent names that as a blind spot rather than approximating.
The
view role excludes Secrets, so Helm release history is unavailable and the change-timeline
method falls back to its other sources. Two grants are deliberately off by default and need an
edit to the values file: reads on custom resource groups that do not aggregate to view, and
cluster-wide Secret reads.Ask it for
This agent takes a resource, not a question. A run’s input names what to investigate:Defaults and limits
The time budget degrades rather than fails. At 70% the agent is nudged to converge; at 100% further
tool calls are refused and it reports what it has.
In a workflow
It is a specialist bound to one cluster, so a workflow step that targets it has already decided which cluster the problem is in. Where a fleet-wide investigation is the starting point, an orchestrator reaches for a multi-cluster investigator first and delegates here once the cluster is known. See Orchestration for how a step delivers work to it.What it will not do
It changes nothing. Its read access is the whole of its reach, and the one non-read grant is confined to a fixed list of diagnostics by the agent’s own classifier. It also sees exactly one cluster and no external context. It has no Komodor backend, no metrics vendor and no cloud provider API — so a cause that lives in any of those is outside what it can observe, and it says so rather than inferring.Next steps
Cluster Investigator
The same cluster knowledge, plus Grafana telemetry and GPU health.
Klaudia Investigator
Kubernetes investigation that spans clusters.
Deploy an agent
Install a self-hosted worker into your cluster.
Agent catalog
Every catalog agent, side by side.