Guest post by Robert Brennan, VP of product development, Fairwinds

Polaris is an open source policy engine that runs dozens of checks to ensure that your Kubernetes pods and controllers are configured using best practices in cluster security, efficiency, and reliability

Polaris is a powerful tool that validates and remediates Kubernetes resources. It includes 30+ built in configuration policies and the ability to write custom policies using an intuitive JSON syntax. As a Kubernetes policy management tool, Polaris can automatically remediate any issues based on policy criteria. 

You can use it in three different ways. The first is as a dashboard to visualize issues with workloads currently running in your cluster. The second is as an admission controller, so you can automatically reject workloads that do not adhere to your organization’s policies. The third is as a command-line tool, so you can test local YAML files on your computer, or as part of a CI/CD process. 

In this tutorial, we go beyond simply seeing your Kubernetes efficiency, reliability, and security issues, and show you how to use Polaris to automate any fixes it finds. 

Update Your Infrastructure as Code with the Polaris CLI Tool

Polaris can do more than just audit files from the command line. Using the polaris fix command, it can automatically revise the YAML manifest of any issues it finds. For example, to fix any problems inside the deploy directory, run:

polaris fix –files-path ./deploy/ –checks=all

Polaris may leave comments next to some changes (e.g. liveness and readiness probes) prompting the user to set them to something more appropriate given the context of their application.

Not all issues can be automatically fixed, Currently only raw YAML manifests can be mutated. Helm charts still need to be changed manually (feature updates are coming soon on this front!).

Mutating Webhook

By default, the Polaris validating webhook will either block or allow a deployment, but you can configure Polaris to operate as a mutating webhook which will automatically alter a deployment when an issue is found, instead of terminating the operation. 

For instructions on how to use Helm to install the validating webhook, see the Polaris documentation.

To enable the mutating webhook, you will set the webhook.mutate flag to true. The full command is this: 

helm upgrade –install polaris fairwinds-stable/polaris –namespace demo –create-namespace –set webhook.enable=true –set webhook.mutate=true –set dashboard.enable=false

By default, the only issue that the Polaris mutating webhook will alter is pullPolicyNotAlways. If you would like to activate other mutations, you can define them through the webhook.mutatingRules flag, or you can you can edit the mutatingRules section of your Polaris configuration:


  enableMutation: true


  - cpuLimitsMissing

  - cpuRequestsMissing

  - dangerousCapabilities

  - deploymentMissingReplicas

  - hostIPCSet

  - hostNetworkSet

  - hostPIDSet

  - insecureCapabilities

  - livenessProbeMissing

  - memoryLimitsMissing

  - memoryRequestsMissing

  - notReadOnlyRootFilesystem

  - priorityClassNotSet

  - pullPolicyNotAlways

To get a more in-depth look at this feature, check out our blog post Kubernetes Mutations with Polaris: How it Works.

The polaris fix command and the mutating webhook are an excellent option for people manually deploying workloads to a Kubernetes cluster, but if you validate your code and infrastructure changes through a continuous integration system, you can also use Polaris. 

Add Polaris to Your Continuous Integration Pipeline 

Polaris can be installed and run inside a continuous integration system like GitLab CI, Jenkins, CircleCI, or CodeShip. Polaris will force your deployment process to exit on any conditions you set. For example, you can set an exit code if Polaris detects certain problems with your infrastructure-as-code YAML files or Helm charts, any danger-level issues, or if the overall score drops below 75%. You can configure Polaris to only show your failed tests, and pretty print the results so they are easier for a human to read. For this set of conditions, the Polaris configuration in your CI pipeline would look like this: 

polaris audit --audit-path ./deploy/ \

  	--set-exit-code-on-danger \

  	--set-exit-code-below-score 75 \

	--only-show-failed-tests true \


This method does not automatically fix the issues Polaris discovers, but it will show the errors in the logs of the CI system.

Polaris can also be set up in GitHub Actions using the instructions in the Polaris Documentation.