36 best-practice checks. Zero install on your cluster.
Security, reliability, and efficiency checks - inspired by Polaris, Kubescape, Trivy, and the NSA/CISA hardening guide. Runs against Radar's cached cluster state, finishes in under a second.
Three tools, one ops fight, and a cluster you still can't sign off on.
You want the CIS hardening advice. You install Kubescape. You want the reliability and efficiency best-practices. You install Polaris. You want any of it enforced. You add Kyverno. Three tools, three CRD sets, three maintenance surfaces.
And your first output is a YAML report you have to diff against last week's to know if anything got worse.
Radar's audit runs 36 checks spanning all three concerns - security, reliability, efficiency - grouped into one view, with per-check remediation, labeled by which framework originated it(NSA/CISA, CIS, Polaris). No operator to deploy. No CRDs installed. No scan schedule to maintain. The audit runs against Radar's already-cached cluster state, so it finishes in under a second.
Three categories. 36 checks. Zero config.
Inspired by Polaris, Kubescape, Trivy, and the NSA/CISA Kubernetes hardening guide. Categories from the Radar README; example checks below are representative.
Security
- Privileged containers
- Privilege escalation allowed
- Host namespaces shared (hostPID, hostIPC, hostNetwork)
- Container runtime sockets mounted
- Service account tokens auto-mounted
Reliability
- Liveness / readiness probes missing
- Image tagged `:latest`
- Single-replica Deployments (no HA)
- HA risk (all replicas on one node)
- Deprecated APIs still in use
Efficiency
- Resource requests missing
- Resource limits missing
- Orphan ConfigMaps / Secrets
- Overprovisioned limits
Examples above are from the Radar README. The running audit enumerates all 36 with per-finding remediation guidance.
Why the audit is fast.
Runs on cached state
Radar's informer cache already powers the topology and resource views. The audit re-uses it. No extra API calls, no cluster-side scan scheduler.
Framework-labeled findings
Each finding carries labels for the framework it came from - NSA/CISA, CIS, Polaris - so you can filter to the one your auditor cares about or the set your compliance program requires.
Ignore lists
Configurable per-namespace ignore rules for the controllers you already know break the checks on purpose (kube-system, GPU operators, etc.) - so real findings aren't buried by noise.
One install instead of three operators.
| What you want | Typical tool | Radar audit |
|---|---|---|
Security best-practices (NSA/CISA, CIS) | Kubescape operator + Kyverno | Built-in, labeled |
Reliability hygiene (probes, replicas, :latest) | Polaris operator | Built-in |
Efficiency checks (requests/limits, orphans) | Polaris operator or custom kubectl scripts | Built-in |
Per-check remediation guidance | Tool-dependent | In every finding |
Install cost | 3 operators + 3 CRD sets | brew install |
Scan latency | Scheduled CronJob, minutes | Sub-second, on demand |
Container CVE scanning | Trivy | Out of scope - pair with Trivy |
Security best-practices (NSA/CISA, CIS)
- Typical tool
- Kubescape operator + Kyverno
- Radar audit
- Built-in, labeled
Reliability hygiene (probes, replicas, :latest)
- Typical tool
- Polaris operator
- Radar audit
- Built-in
Efficiency checks (requests/limits, orphans)
- Typical tool
- Polaris operator or custom kubectl scripts
- Radar audit
- Built-in
Per-check remediation guidance
- Typical tool
- Tool-dependent
- Radar audit
- In every finding
Install cost
- Typical tool
- 3 operators + 3 CRD sets
- Radar audit
- brew install
Scan latency
- Typical tool
- Scheduled CronJob, minutes
- Radar audit
- Sub-second, on demand
Container CVE scanning
- Typical tool
- Trivy
- Radar audit
- Out of scope - pair with Trivy
Apache 2.0. Yours to inspect, fork, or run in your own cluster.
Radar's source is on GitHub. Every feature on this page is in the binary you install with brew install. No telemetry, no mandatory login, no cluster data out. The one outbound call is an anonymous version check when the UI opens. If we ever change that, you'll see it in a diff first.
Radar Cloud runs the audit across your whole fleet.
Same 36 checks. Same framework labels. Fleet-wide rollup across connected clusters, so you can see which checks are failing where without opening each cluster separately.
See the OSS vs Cloud comparisonQuestions we get about cluster audit.
What frameworks are the 36 checks based on?
Do I need to install an operator or CRDs to run the audit?
Can I ignore known or expected violations?
How long does a scan take?
Can I run the audit across multiple clusters at once?
More of what Radar does in the same binary.
One binary. 36 checks. No operators.
Radar runs the checks the moment it connects. brew install, open the Audit tab, read the list.
Apache 2.0 OSS · Unlimited clusters with Radar OSS · Hosted free tier for up to 3 clusters