polaris audit: Score Kubernetes Config in CI
polaris audit runs Fairwinds Polaris checks against manifests or a live cluster and, with the right flags, fails CI when dangerous issues are found.
Polaris is a configurable policy engine for Kubernetes best practices. In CI you point polaris audit at your manifests and set an exit-code flag so danger-level findings, or a score below a threshold, break the build.
What it does
polaris audit evaluates resources against a set of checks (security, reliability, efficiency), each classed as warning or danger. It outputs a report with a numeric score. By default it exits 0; you opt into gating with --set-exit-code-on-danger or --set-exit-code-below-score.
Common usage
# audit local manifests and fail on danger findings
polaris audit --audit-path ./manifests \
--set-exit-code-on-danger --only-show-failed-tests
# fail when the overall score drops below 90
polaris audit --audit-path ./manifests --set-exit-code-below-score 90
# use a custom config with your own checks
polaris audit --audit-path ./manifests --config polaris-config.yamlOptions
| Flag | What it does |
|---|---|
| --audit-path <path> | File or directory of manifests to audit |
| -c, --config <file> | Custom Polaris config selecting/tuning checks |
| --set-exit-code-on-danger | Exit non-zero if any danger-level issue is found |
| --set-exit-code-below-score <n> | Exit non-zero if the score is below n |
| --only-show-failed-tests | Suppress passing checks in the output |
| -f, --format <fmt> | Output format: pretty, json, yaml |
In CI
Point --audit-path at rendered manifests and choose one gating flag: --set-exit-code-on-danger for a hard block on dangers, or --set-exit-code-below-score for a graded ramp-up. A vendored --config keeps checks consistent across repos and lets you exempt specific checks deliberately.
Common errors in CI
Without a --set-exit-code flag, polaris audit always exits 0, so a "passing" job may be doing nothing; add the gating flag. "Error: unable to parse config" means the --config YAML is malformed. "no manifests found" means --audit-path is wrong. When a danger fires with --set-exit-code-on-danger, the report lists it and the process exits 3.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes