# FairwindsOps Polaris: a Kubernetes policy engine for auditing, admission control and CI

> Polaris checks Kubernetes resource configuration against 30+ built-in policies and can fix what it finds. It ships as a dashboard, an admission controller and a CLI, and since v10.2.0 its images live in a new registry with immutable, signed tags.

**FairwindsOps/polaris** — Validation of best practices in your Kubernetes clusters

- Repository: https://github.com/FairwindsOps/polaris
- Website: https://www.fairwinds.com/polaris
- Stars: 3,389 · Forks: 230
- Language: Go
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/fairwindsops-polaris

## The gap Polaris fills: misconfigured resources, not broken images

A pod can start and still be wrong. No CPU request, no memory limit, no readiness probe, a container running as root, a tag that is not pinned. The scheduler accepts it, the deployment reports healthy, and the bill and the outage arrive later. Polaris exists to catch that class of problem by reading the resource configuration itself rather than the running process. The README describes it as "an open source policy engine for Kubernetes that validates and remediates resource configuration", with more than 30 built-in configuration policies and the option to write custom ones against JSON Schema. The audience is platform and infrastructure teams who own cluster standards and need a way to state them once and apply them in several places. It is not a scanner for CVEs, image contents or network traffic; every check starts from a manifest.

## Three run modes over one policy set

The same policy definitions drive three deployment shapes, which is the main design decision in the project. As a dashboard, Polaris validates Kubernetes resources against policy-as-code and presents the results for a cluster. As an admission controller, it sits in the API server's admission path and, per the README, can "automatically reject or modify workloads that don't adhere to your organization's policies". As a command-line tool, it runs against local YAML files so policy checks can be part of CI/CD before anything is applied. That third mode is the one that changes how a team works: the same rules that block a deployment in a cluster can fail a pull request, so a reviewer does not have to remember the standards. The remediation path is narrower than the detection path. Automatic fixes are described for command-line and mutating webhook operation, and a mutating webhook can only patch what the API server sends it.

## Installing Polaris and running a first audit

The README does not give an install command. It points to the documentation at polaris.docs.fairwinds.com and to the releases page for binaries, so the exact flags for the CLI and the Helm values for the dashboard have to come from there. What the README does state precisely is the image location, and that changed. Starting with v10.2.0, images moved to us-docker.pkg.dev/fairwinds-ops/oss/polaris and quay.io/fairwinds/polaris is deprecated. The required substitution is shown in the README as a diff:

```diff
- quay.io/fairwinds/polaris:<tag>
+ us-docker.pkg.dev/fairwinds-ops/oss/polaris:<tag>
```

If you are pinning images yourself, note that tags are now immutable and the floating tags v10, v10.1 and latest are gone. The README gives two accepted forms, a full version tag and a digest:

```bash
us-docker.pkg.dev/fairwinds-ops/oss/polaris:v<major>.<minor>.<patch>
```

```bash
us-docker.pkg.dev/fairwinds-ops/oss/polaris@sha256:<digest>
```

The published container image is built from alpine:3.24.1, installs ca-certificates, creates a polaris user with UID 1200, copies the binary, sets the working directory to /opt/app and runs CMD ["polaris"]. The Dockerfile label describes the binary as "a cli tool to help discover deprecated apiVersions in Kubernetes", which contradicts the README's broader description of a policy engine. Treat the README and the documentation as the accurate source and the label as stale. Note also that the image runs as UID 1200, so any mounted policy file must be readable by that user.

## Where Polaris is the wrong instrument

Polaris evaluates configuration, so it is silent about anything that only appears at runtime. A container that passes every policy can still crash-loop, leak memory or call a service it should not reach. It also does not tell you whether an image is vulnerable or whether a tag still resolves to the same digest, beyond the pinning checks themselves. The admission controller mode carries a sharper cost. Per the README it can reject workloads, which means a policy mistake or an unavailable webhook can block deployments in the cluster it protects; the README does not document rollback or a failure policy for that path, so how a failed webhook call is handled has to be confirmed in the documentation before you enable rejection rather than mutation. Finally, the dashboard and the admission controller are separate concerns. Running one does not give you the other, and the README does not describe a single component that performs both.

## How Polaris differs from Goldilocks, Pluto and Nova

Fairwinds publishes several Kubernetes tools, and the split is by question asked. Goldilocks right-sizes Deployments by comparing memory and CPU settings against actual usage, so it needs a running cluster and metrics before it has an opinion. Polaris does not measure usage; it compares declared configuration against policy, and it can do that on a YAML file that has never been applied. Pluto detects Kubernetes resources that have been deprecated or removed in future versions, which overlaps with the deprecated apiVersion wording in the Polaris Dockerfile label but is a different check from a configuration policy. Nova looks for updates to Helm charts. The practical consequence: Polaris is the only one of the four that can fail a pull request on resource configuration alone, and the only one that can mutate or reject at admission time. If your problem is that nobody knows what the workloads actually consume, Polaris will not answer it.

## Maintenance, upgrades and the licence

The repository is not archived and the last push was on 2026-09-21, two days before this writing, with v10.2.5 released on 2026-09-18 after v10.2.4 and v10.2.3 earlier the same week. That release cadence is the practical upgrade cost: patch releases arrive often enough that an automated dependency update tool is worth having, and the repository does carry a renovate.json at the top level. The bigger cost sits in the v10.1.8 to v10.2.0 transition. Any manifest, Helm values file or internal chart that still references quay.io/fairwinds/polaris needs editing, and any deployment pinned to v10, v10.1 or latest will fail to pull because those tags are no longer published. Switching to full version tags or digests makes upgrades explicit, which is the point, but it also means an upgrade is now a deliberate edit rather than a re-pull. Polaris is licensed under Apache-2.0, and the Dockerfile sets the corresponding org.opencontainers.image.licenses label. That licence permits commercial use and modification; it also means redistributed modified images carry attribution and notice obligations. This is a description of the licence text, not legal advice.

## Conclusion

Adopt Polaris if you want resource configuration checked before it reaches the cluster, and you can accept that the dashboard and admission controller are two separate deployments. Skip it if your problems are image provenance or runtime behaviour, since Polaris reads manifests, not running containers. Before installing, confirm two things: which registry your manifests point at, because quay.io/fairwinds/polaris is deprecated as of v10.2.0, and whether the helm chart you use pins a mutable tag such as v10, v10.1 or latest, which the project no longer publishes.

## FAQ

### What is Polaris for Kubernetes?

It is an open source policy engine that validates and remediates Kubernetes resource configuration, with more than 30 built-in policies and support for custom policies written as JSON Schema. It runs as a dashboard, an admission controller or a command-line tool.

### Which container registry should Polaris images come from?

Starting with v10.2.0, images moved to us-docker.pkg.dev/fairwinds-ops/oss/polaris, and quay.io/fairwinds/polaris is deprecated. Use a full version tag such as v<major>.<minor>.<patch> or pin by digest, since v10, v10.1 and latest are no longer published.

### Can Polaris reject workloads before they are deployed?

Yes. In admission controller mode the README states it can automatically reject or modify workloads that do not adhere to your organization's policies. The README does not document a rollback path for that mode.

## Sources

- [FairwindsOps/polaris on GitHub](https://github.com/FairwindsOps/polaris)
- [License: Apache-2.0](https://github.com/FairwindsOps/polaris/blob/master/LICENSE)
- [Project website](https://www.fairwinds.com/polaris)
- [README](https://github.com/FairwindsOps/polaris/blob/master/README.md)
- [Releases](https://github.com/FairwindsOps/polaris/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fairwindsops-polaris
