Skip to main content
Cluster audit runs a set of static checks against your live K8s state and surfaces failures inline on each affected resource. No CRDs to install, no extra controllers - it’s part of the Radar binary. In the nav rail this view is labelled Checks (g u).

​
What it checks

The check set covers three categories. Defaults skip stylistic checks; they flag misconfigurations only.

​
Security

  • Containers running as root.
  • Containers without readOnlyRootFilesystem.
  • allowPrivilegeEscalation: true.
  • Privileged containers.
  • hostNetwork, hostPID, hostIPC.
  • Missing or wide securityContext.
  • Service accounts with cluster-admin (or wildcards in bindings).
  • Workloads that mount the default ServiceAccount.
  • Secrets with no type or with Opaque and weak keys.
  • Pod Security Admission level inconsistencies.

​
Reliability

  • Missing livenessProbe / readinessProbe.
  • Missing CPU / memory requests and limits.
  • Single-replica Deployments / StatefulSets in production-ish namespaces.
  • Pods without PodDisruptionBudget for replicated workloads.
  • Image tag is latest (or no tag).
  • imagePullPolicy: Always on a digest-pinned image.
  • Anti-affinity not set on multi-replica workloads.
  • HPA min replicas = max replicas.
  • Stuck terminating - resources with metadata.deletionTimestamp set past the cleanup window (warning at 5min, danger at 30min). Most controllers complete cleanup within seconds; minutes-long delays usually mean a finalizer’s owning controller is unhealthy or unable to reach a dependency. Findings name the blocking finalizers and point at the controller (Argo CD’s argocd-application-controller, Flux’s kustomize-controller / helm-controller / source-controller, etc.) to investigate. Same warning / danger thresholds as the per-resource GitOps lifecycle Issue so the two surfaces agree on severity.

​
Efficiency

  • CPU / memory requests way above observed usage (over-requested).
  • Limits with no requests (CPU throttling risk).
  • Workloads with zero replicas left running.
  • Stale ReplicaSets / pods.

​
How to read it

Open Checks in the nav rail. You see:
  • Summary - total findings, broken down by category and severity.
  • By resource - rows of resources sorted by issue count.
  • By check - rows of checks sorted by frequency. Click any check for the rationale, the affected resources, and a remediation snippet.
In the resource browser, every row shows a small audit chip when there are findings. The detail drawer’s Audit tab shows the per-resource breakdown. High-signal findings (a genuinely broken resource - a dangling reference, a Service with no endpoints, a deprecated API) also badge the resource directly on the topology graph and in list views, so you spot them without opening the audit view first.

​
Ignore patterns

Some findings are noise for your specific environment - a sandbox namespace where latest tags are fine, a system DaemonSet that legitimately needs hostNetwork. Ignore them in Settings → Audit: 
# in-cluster Helm value (auth-secured config)
audit:
  ignore:
    # exact resource match
    - kind: DaemonSet
      namespace: kube-system
      name: cilium
      checks: [host_network, privileged]
    # selector match
    - namespaceLabels:
        environment: dev
      checks: [latest_tag, missing_resource_limits]
For local Radar, the same shape lives in ~/.radar/audit-ignore.json.

​
In-app remediation

Most checks come with a one-click “Apply suggested patch” that opens a YAML editor pre-filled with the fix. The editor uses server-side apply so it won’t clobber unrelated managed fields.

​
API + MCP

Audit findings are available programmatically:
  • GET /api/audit - cluster-wide
  • GET /api/audit/resource/{kind}/{namespace}/{name} - single resource
  • MCP tool get_cluster_audit - filterable by category / severity / namespace
That makes it easy to wire findings into CI, dashboards, or AI tools.

​
See also