Security posture. Short, specific, testable.
KubeHero reads your whole cluster — logs, profiles, network flows, spend — and can, when you arm it, change workloads. Those are exactly the reasons to be precise about what it can and cannot do. Each commitment below is an engineering property you can verify, not a slogan.
Collection is read-only.
The collector's Kubernetes RBAC is get/list/watch on pods, nodes, services and their owners, get on nodes/proxy for kubelet stats, and one namespaced Lease for leader election. It cannot create, patch or delete anything in your cluster.
eBPF privileges, stated plainly.
With eBPF on (the default) the collector runs privileged with hostPID: loading BPF programs, opening perf events and attaching to the root cgroup require it, and /proc is how CPU stacks get symbolised. The programs only observe — cgroup_skb hooks always pass the packet; nothing is dropped, rewritten or redirected. Set collector.ebpf.enabled=false and it runs unprivileged: read-only root filesystem, every capability dropped except DAC_READ_SEARCH to read pod logs.
Only the operator writes — only when armed.
RightsizingPolicy, CeilingPolicy and BudgetPolicy are inert until a human arms them. Steps are bounded per change and per day, dry-run first; every action records the previous spec so kubehero undo restores it inside the cooldown.
Agents can’t act.
The advisor runs under a ServiceAccount with no role bindings and calls only read RPCs. Every proposal, from any brain, is validated against a CRD whitelist and becomes a change only through the operator’s arming flow.
Your data stays in your infrastructure.
No telemetry leaves. The single, optional exception is the advisor’s LLM brain: with your Anthropic key set, the snapshot and tool results it reasons over — which can include capped samples of log lines — go to Anthropic’s API under your key. Leave the key unset and nothing leaves. Air-gap capable.
Auth on by default.
API keys with roles (owner, admin, auditor, member, viewer), per-cluster enrollment tokens stored only as SHA-256 hashes, OIDC with JWKS signature verification and group → role mapping, SCIM 2.0 provisioning. The chart generates the tokens and requires auth on every RPC.
An audit log you can prove.
Every policy change, arming, enforcement and apply writes an append-only row signed with an HMAC key, so a downstream SIEM can detect tampering.
Supply chain you can check.
Images are cosign-signed (keyless), carry SPDX SBOM attestations and are Trivy-scanned on release. The chart ships network policies and restricted security contexts for every component.
Ask the API server, not us.
The guarantees live in RBAC and in the chart, so kubectl can check them against a running install.
# the collector cannot write
kubectl auth can-i patch deployments -A \
--as=system:serviceaccount:kubehero-system:kubehero-collector # no
# the advisor has no Kubernetes permissions at all
kubectl auth can-i list pods -A \
--as=system:serviceaccount:kubehero-system:kubehero-advisor # no
# only the operator can patch workloads — and only for armed policies
kubectl auth can-i patch deployments -A \
--as=system:serviceaccount:kubehero-system:kubehero-operator # yesYour cluster, your boundary.
Found something? Tell us directly.
Email the security team with reproduction steps. We aim to acknowledge within 2 business days and keep you updated through to a fix. Public credit where you want it, in the repository’s hall of fame once patched.
please don’t open public GitHub issues for security-sensitive reports.