> ## Documentation Index
> Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Cluster audit

> Built-in best-practices scan covering security, reliability, and efficiency. Inspired by Polaris and the NSA / CISA Kubernetes hardening guide. Configurable ignore patterns. No extra installs.

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](/docs/features/gitops#lifecycle-awareness-terminating-doesnt-lie-about-state) 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](/docs/features/topology) 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**:

```yaml theme={null}
# 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

* [Resource browser](/docs/features/resources) - the inline audit chip per row.
* [AI via MCP](/docs/features/mcp) - have an AI explain or remediate findings.
* [Fleet checks](/docs/cloud/fleet-views) - audit findings rolled up across all clusters in your org (Cloud).