Kyverno is a policy engine built for Kubernetes:

• policies as Kubernetes resources (no new language to learn!)
• validate, mutate, or generate any resource
• match resources using label selectors and wildcards
• validate and mutate using overlays (like Kustomize!)
• generate and synchronize defaults across namespaces
• block or report violations
• test using kubectl

NOTE : Your Kubernetes cluster version must be above v1.14 which adds webhook timeouts. To check the version, enter kubectl version.

Install Kyverno:

kubectl create -f https://raw.githubusercontent.com/nirmata/kyverno/master/definitions/release/install.yaml

You can also install Kyverno using a Helm chart.

Add the policy below. It contains a single validation rule that requires that all pods have a app.kubernetes.io/name label. Kyverno supports different rule types to validate, mutate, and generate configurations. The policy attribute validationFailureAction is set to enforce to block API requests that are non-compliant (using the default value audit will report violations but not block requests.)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: enforce
  rules:
  - name: check-for-labels
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "label `app.kubernetes.io/name` is required"
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?*"

Try creating a deployment without the required label:

kubectl create deployment nginx --image=nginx

You should see an error:

Error from server: admission webhook "nirmata.kyverno.resource.validating-webhook" denied the request:

resource Deployment/default/nginx was blocked due to the following policies

require-labels:
  autogen-check-for-labels: 'Validation error: label `app.kubernetes.io/name` is required;
    Validation rule autogen-check-for-labels failed at path /spec/template/metadata/labels/app.kubernetes.io/name/'

Create a pod with the required label. For example from this YAML:

kind: "Pod"
apiVersion: "v1"
metadata:
  name: nginx
  labels:
    app.kubernetes.io/name: nginx
spec:
  containers:
  - name: "nginx"
    image: "nginx:latest"

This pod configuration complies with the policy rules, and is not blocked.

Clean up by deleting all cluster policies:

kubectl delete cpol --all

As a next step, browse the sample policies and learn about writing policies. You can test policies using the Kyverno cli. See docs for complete details.

• Getting Started
• Writing Policies
  • Selecting Resources
  • Validating Resources
  • Mutating Resources
  • Generating Resources
  • Variable Substitution
  • Preconditions
  • Auto-Generation of Pod Controller Policies
  • Background Processing
• Testing Policies
• Policy Violations
• Kyverno CLI
• Sample Policies
• API Documentation

Apache License 2.0

To attend our next monthly community meeting join the Kyverno group. You will then be sent a meeting invite and get access to the agenda and meeting notes.

• For feature requests and bugs, file an issue.
• For discussions or questions, join the #kyverno channel on the Kubernetes Slack or the mailing list.

Thanks for your interest in contributing!

• Please review and agree to abide with the Code of Conduct before contributing.
• We encourage all contributions and encourage you to read our contribution guidelines.
• See the Wiki for developer documentation.
• Browse through the open issues

• Introducing Kyverno - blog post
• CNCF Video and Slides
• 10 Kubernetes Best Practices - blog post
• VMware Code Meetup Video
• Virtual Rejekts Video
• TGIK Video

Open Policy Agent (OPA) is a general-purpose policy engine that can be used as a Kubernetes admission controller. It supports a large set of use cases. Policies are written using Rego a custom query language.

k-rail provides several ready to use policies for security and multi-tenancy. The policies are written in Golang. Several of the Kyverno sample policies were inspired by k-rail policies.

Polaris validates configurations for best practices. It includes several checks across health, networking, security, etc. Checks can be assigned a severity. A dashboard reports the overall score.

Tools like Kustomize can be used to manage variations in configurations outside of clusters. There are several advantages to this approach when used to produce variations of the same base configuration. However, such solutions cannot be used to validate or enforce configurations.

See Milestones and Issues.