In an earlier blog post, we showed you how to install the policy engine, Polaris, and audit your Kubernetes workloads using the Dashboard, an Admission Controller and the CLI tool. 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.
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!).
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:
webhook:
enableMutation: true
mutatingRules:
- 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.
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 \
--format=pretty
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.
If you have multiple clusters and want to use Polaris to scan them all at once, Fairwinds offers a platform called Insights. Users can centrally manage Polaris across clusters consistently to make sure your Kubernetes workloads are as efficient, reliable and secure as they can be.