Generate polices ! Make Kubernetes life hassle free with Kyverno - Part 2

28.09.2020 — kubernetes, kyverno — 1 min read

In the last blog post, we discussed the basics of a Kyverno generate policy and synchronization feature for managing resources across namespaces. The last demo was limited because at that time Kyverno only supported the create resource trigger for generate policies.

last Friday Kyverno roll out a new release with some exciting features. Let's explore generate policy with some use cases. We will also discuss the best practices before upgrading. Don't worry this release is backward compatible

Kyverno generates resources based on a given set of conditions or triggers (read more about match/exclude). A Kyverno generate policy supports two types of rules. In my last blog I described these two types in detail Generate polices ! Make Kubernetes life hassle free with Kyverno

With the new release users can now users can add selector to policy for creating a trigger.

In our first use case, we will generate resources based on adding a namespace label.

As an example, we will use Velero which is a tool from VMware for managing backups of Kubernetes configuration and state. Take a look at this TGIK session on Velero - it's an interesting tool

Here we will create a trigger on namespace labels. The namespace owner owner can enable or disable Velero backup by adding or removing the label i.e. nirmata.io/auto-backup: enabled

1apiVersion: kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4  name: add-velero-autobackup-policy
5spec:
6  background: false
7  rules:
8    - generate:
9        apiVersion: velero.io/v1
10        data:
11          metadata:
12            labels:
13              nirmata.io/backup.type: auto
14              nirmata.io/namespace: '{{request.object.metadata.name}}'
15          spec:
16            schedule: 0 0 * * *
17            template:
18              includedNamespaces:
19                - '{{request.object.metadata.name}}'
20              snapshotVolumes: true
21              storageLocation: default
22              ttl: 168h0m0s
23        kind: Schedule
24        name: '{{request.object.metadata.name}}-auto-schedule'
25        namespace: velero
26        synchronize: true
27      match:
28        resources:
29          kinds:
30            - Namespace
31          selector:
32            matchLabels:
33              nirmata.io/auto-backup: enabled
34      name: add-velero-autobackup-policy
35  validationFailureAction: audit

As another example we can write a policy that enable Prometheus, a CNCF metrics and alerting tool, for a namespace. Here we will create a trigger on namespace labels. The namespace owner request a service account for Prometheus by adding or removing the label i.e. nirmata.io/monitoring: enabled

1apiVersion: kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4  name: add-serviceaccount
5spec:
6  background: false
7  rules:
8  - match:
9      resources:
10        kinds:
11        - Namespace
12        selector:
13          matchLabels:
14            nirmata.io/monitoring: enabled
15    name: add-sa-policy
16    validationFailureAction: audit
17    generate:
18      apiVersion: v1
19      kind: ServiceAccount
20      name: "prometheus-alertmanager"
21      namespace: "{{request.object.metadata.name}}"
22      synchronize: true
23      data:
24        metadata:
25          labels:
26            app: "prometheus-alertmanager"
27            heritage: "Tiller"
28            app.kubernetes.io/name: "prometheus"
29            chart: "prometheus-operator-9.3.0"
30            release: "prometheus"

Let's see a demo, but before demo let's provide Kyverno specific permissions for both use cases. Also create a namespace velero because our policy will create schedule in velero.

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: kyverno:generatecontroller
5rules:
6  # process generate rules to generate resources
7  - apiGroups:
8      - "*"
9    resources:
10      - namespaces
11      - serviceaccounts
12      - schedules
13    verbs:
14      - create
15      - delete
16      - get
17      - list
18      - patch
19      - update
20      - watch
21  # dynamic watches on trigger resources for generate rules
22  # re-evaluate the policy if the resource is updated
23  - apiGroups:
24      - '*'
25    resources:
26      - namespaces
27    verbs:
28      - watch

Let's see in action

Note : we advise you to use a generate policy with a selector. If you are using generate policy without selector then it will work fine because we have backward compatibility. we will deprecate older functionality in the next major release.

Check out the Kyverno v1.1.12 GitHub page to learn more about the new feature added in Kyverno like Kustomize support for patches,Namespaced policies and some cli improvment for local testing. Find more about Kyverno in the previous post Kubernetes Policy Management with Kyverno..