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) and appears under the Best practices tab. For version-targeted compatibility analysis, use Upgrade impact.

​
What it checks

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

​
Security

  • Containers running as root, running privileged, allowing privilege escalation, or using a writable root filesystem.
  • Dangerous capabilities such as SYS_ADMIN, plus capabilities that are usually unnecessary and should be dropped.
  • hostNetwork, hostPID, and hostIPC access.
  • Container-runtime socket mounts and sensitive host paths.
  • Values that look like credentials or tokens stored in ConfigMaps instead of Secrets.
  • Automatically mounted ServiceAccount tokens on workloads that may not need Kubernetes API access.

​
Reliability

  • Missing liveness or readiness probes.
  • Image tags that are latest or omitted, and mutable tags used without imagePullPolicy: Always.
  • TLS certificates in kubernetes.io/tls Secrets that expire within 30 days (danger within 7 days or once expired). This reads the stored certificate, not whether a service is serving it or whether renewal is failing.
  • Single-replica Deployments, and multi-replica Deployments or StatefulSets without a PodDisruptionBudget or topology-spread constraints.
  • Deployments whose rolling update allows every replica to be unavailable with no surge, so a rollout can remove all old Pods before replacements are ready.
  • Replicas that are all scheduled on one node, leaving no real node-level redundancy.
  • Services without matching Pods, Ingresses without their referenced Service, and supported Traefik routes or middleware with missing backends.
  • Deprecated Kubernetes API versions.
  • 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.
  • Stuck Crossplane resources - managed resources, composite resources, and claims reporting Ready=False or Synced=False past the same window (warning at 5min, danger at 30min). Findings include the condition’s reason and message, which usually carries the provider’s upstream error. Paused resources are skipped.
  • CloudNativePG clusters with no ScheduledBackup declaring when backups run. This reports what is declared in the cluster, not whether backups exist.
  • When the cluster runs GitOps (at least one Argo CD Application, Flux Kustomization, or Flux HelmRelease exists): top-level workloads that no GitOps controller or Helm manages, and workloads installed with Helm directly instead of through a GitOps controller.

​
Efficiency

  • Missing CPU or memory requests.
  • Missing CPU or memory limits.
  • ConfigMaps and Secrets that are not referenced by a supported workload, Ingress, or controller configuration.

​
How to read it

Open Checks → Best practices in the nav rail. You see:
  • Summary and filters - failing checks and individual findings broken down by severity, with category, framework, and search filters.
  • Remediation queue - one row per failing check, ordered by severity and affected-resource count. Expand a row for the rationale, remediation guidance, upstream references, and affected resources.
The resource browser also shows an audit badge on rows with findings, and workload details include the resource’s audit findings. These use the same scan results as the Best practices queue.

​
Configure the checks policy

Some findings are intentional in a particular environment - for example, a sandbox namespace where latest tags are acceptable or a system DaemonSet that legitimately needs host access. Use the settings button on Checks → Best practices to:
  • hide findings from an entire namespace;
  • enable or disable individual checks globally.
Each check row also has inline actions for disabling that check or all checks in its category. There is no per-resource suppression. The policy applies to everyone using that Radar instance. In Radar Cloud, only owners can change it. Local settings persist in ~/.radar/settings.json. Radar ignores kube-system, kube-node-lease, kube-public, and namespaces matching *-system by default.

​
Remediation guidance

Every check explains why the configuration matters and how to fix it, with upstream references where available. Radar does not apply those changes automatically; make the change through your normal manifest or GitOps workflow, then refresh the scan.

​
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