There are many ways to configure Kubernetes and the workloads that it runs, and unfortunately, many of them are dangerous. It's far too easy to introduce problems related to security, efficiency, or reliability, which is why Kubernetes practitioners have developed a set of Kubernetes best practices for configuring Kubernetes workloads. Fairwinds created Polaris, an open source policy engine for Kubernetes, to help define and enforce these best practices.
Polaris makes it easy to validate and remediate Kubernetes resources to make sure that you’re following best practices for configuring K8s. The open source policy engine:
We continuously make improvements to our open source projects. Please join our Slack Community, which provides users with the opportunity to ask questions, get answers, and make suggestions. Recently, we had some interesting questions about Polaris that we wanted to share.
A Polaris user who was using GitOps (ArgoCD specifically) for deployment asked about a race condition encountered when trying to activate the Polaris validating webhook admission controller. When applying the ValidationWebhookConfiguration at the same time as the polaris-webhook deployment, the polaris-webhook pod is blocked from starting because the apiserver can't connect to the polaris-webhook pod.
When using Helm natively there is the option to use chart hooks, which allow the user to insert logic at various stages of a release’s lifecycle. For example, this user shared that they have in the past used a pre-install hook to check for the polaris-webhook deployment to be in a ready state before applying the webhook configuration.
Another possible workaround they shared is to set webhook.failurePolicy to Ignore. This would cause the API server to ignore failures from the webhook; it would "fail open." This behavior is not ideal if you're trying to use admission control as a security measure.
We weren’t sure if we could tell ArgoCD to deploy things in a specific order, so we decided to look at the ArgoCD webhook annotations. This seemed like the easiest and most elegant solution to the issue, and it would increase our support of various GitOps tools.
The Polaris user decided to submit a pull request for the Polaris helm chart and add an option for adding annotations to the webhook and deployment manifests. That enabled them to add ArgoCD annotations, such as:
webhook:
validation:
annotations:
argocd.argoproj.io/hook: PostSync
mutation:
annotations:
argocd.argoproj.io/hook: PostSync
This annotation allows for customized actions to be run after ArgoCD’s sync process. When used in this way, ArgoCD applies these manifests as part of the post-sync operation. This method enables some control over the order in which manifests are applied.
Our Fairwinds Community is dedicated to the exchange of ideas, enabling people to come together to build and contribute to open source projects, and provide networking opportunities for Kubernetes users. Please get involved by joining the community: chat with us on Slack or join the user group.
And if you are interested in contributing to Polaris or any of our other open source projects, we’d appreciate your help making our open source offerings as helpful to the community as possible. We've fixed some of our installs to support various GitOps tools and appreciate suggestions and contributions from our users and the broader community to continue to make these types of improvements.
If you want to run Polaris in multiple clusters, track results over time, integrate with Slack, Datadog, and Jira, and unlock other functionality to help you run Kubernetes securely, reliably, and cost efficiently at scale, check out Fairwinds Insights.
