Policies with Kyverno
Developer platforms built on top of Kubernetes promote self-service developer workflows. This huge responsibility shifted left from dedicated operations and security professionals onto developer's everyday workflows.
It is a tall order to expect developers to be specialist in all aspects of software delivery. Developer platforms should always have built-in guardrails to assist developers in adhering to company wide compliance and security requirements.
Policies are one component in Kubernetes based developer platforms that keep applications compliant and secure while not hurting developers' productivity.
Policies are rules that every application deployment must adhere to. Policy engines, like Kyverno, are tools to enforce policies in the software delivery workflow.
Kyverno is a policy engine designed for Kubernetes. With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies. This allows you to use familiar tools, such as kubectl, git, and kustomize, to manage policies. Kyverno policies can validate, mutate, and generate Kubernetes resources.
Kyverno in action
Kyverno runs on your Kubernetes cluster and hooks into the API server's extension points to be able to determine if a resource fits the shape defined by the policies.
Based on the specified policies, it can validate, reject, or even mutate the deployed resources, making it a very powerful tool.
Kyverno uses the standardized extension points of the Kubernetes API server
When you type kubectl apply, the Kubernetes API server gets your request and passes it through a series of steps.
Kubernets provides two extension points
- mutating admission controllers
- and validating admission controllers
Mutating admission controllers - as the name suggests - mutate the resources that you are about to create, while validating admission controllers determine if they are allowed on the cluster.
Kyverno implements both of these extension points and is able to do quite handy stuff, like automatically injecting resource limits or checking if a pod is running as root. If a pod is running as root, Kyverno sends a rejection response in the validating admission webhook response, and the Kubernetes API server turns down your kubectl apply request.
Setting alerts on pods that are violating a policy
If you deploy Kyverno with Gimlet Stack, you deploy a set of default policies in audit mode. This means that your deployments will not be rejected, instead, you can report on deployments that are violating the policies. Thus, the natural next step is to see the pods that are violating policies.
For this purpose, Gimlet Stack includes a Grafana dashboard:
How to set alerts on pods? To do so, duplicate the "Failing Policies" widget on the dash and limit it to the require-run-as-non-root policy with the following query:
sum(increase(kyverno_policy_results_total{rule_result="fail", policy_name="require-run-as-non-root"}[45s])) by (policy_name)
