Appliquer une gestion des politiques sur OVHcloud Managed Kubernetes avec Kyverno

Objectif

Kyverno (du grec « gouverner ») est un moteur de politiques conçu spécifiquement pour Kubernetes.

Avec Kyverno, les politiques sont gérées comme des ressources Kubernetes et aucun nouveau langage n'est requis pour les écrire (contrairement à OPA Gatekeeper, qui utilise le langage de programmation Rego). Cela permet d'utiliser des outils familiers comme kubectl, git et kustomize pour gérer les politiques.

Les politiques Kyverno peuvent valider, muter et générer des ressources Kubernetes.

Kyverno s'exécute comme un contrôleur d'admission dynamique dans un cluster Kubernetes. Kyverno reçoit des rappels HTTP de webhook d'admission de validation et de mutation depuis l'API-Server de Kubernetes, et applique les politiques correspondantes pour renvoyer des résultats qui appliquent les politiques d'admission ou rejettent les requêtes.

Les politiques Kyverno peuvent cibler des ressources en fonction du type de ressource, du nom et de sélecteurs de labels. Les caractères génériques sont pris en charge dans les noms.

Les politiques de mutation et de validation peuvent être écrites sous forme d'overlays (à la manière de Kustomize).

L'application des politiques est capturée via des événements Kubernetes. Kyverno signale également les violations de politiques pour les ressources existantes.

Concrètement, lorsque vous appliquez une ressource sur le cluster Kubernetes, le manifeste envoyé à l'API Kubernetes doit passer par plusieurs étapes avant d'être créé en tant que ressource souhaitée. Deux étapes nous intéressent particulièrement : l'Admission de mutation et l'Admission de validation.

Parmi les nombreuses fonctionnalités de Kyverno, on retrouve :

• la validation et la mutation via des overlays (à la manière de Kustomize) ;
• la synchronisation des configurations entre les namespaces ;
• l'analyse des workloads existants et la génération de rapports d'audit ;
• le blocage des ressources non conformes via des contrôles d'admission, ou le signalement des violations de politiques ;
• le test des politiques et la validation des ressources avec la CLI kyverno, dans votre pipeline CI/CD, avant de les appliquer à votre cluster.

Pour en savoir plus sur Kyverno.

Sécuriser un cluster Kubernetes est important. Grâce à Kyverno, vous pouvez vérifier plusieurs bonnes pratiques de sécurité, par exemple :

• configurer les sondes Readiness et Liveness ;
• configurer les quotas de ressources ;
• ne pas utiliser de tags d'image mutables (latest) ;
• restreindre les registres d'images ;
• configurer la sécurité des pods ;
• appliquer un RBAC précis (fine-grained).

Chez OVHcloud, nous tenons à vous fournir les meilleurs produits et services, et la sécurité est pour nous une priorité. C'est pourquoi nous avons souhaité vous faire découvrir Kyverno, qui vous aidera à sécuriser votre OVHcloud Managed Kubernetes grâce à la gestion des politiques.

Dans ce guide, vous allez :

• installer Kyverno ;
• écrire et déployer plusieurs politiques ;
• tester leur comportement.

Vous pouvez utiliser la fonction Réinitialiser le cluster dans la section Public Cloud de l'OVHcloud Control Panel pour réinitialiser votre cluster avant de suivre ce tutoriel.

Prérequis

Ce tutoriel suppose que vous disposez déjà d'un cluster OVHcloud Managed Kubernetes fonctionnel, ainsi que de connaissances de base sur son fonctionnement. Pour en savoir plus sur ces sujets, consultez la documentation Déployer une application Hello World.

En pratique

Installation de la CLI Kyverno

Vous pouvez installer la CLI via Krew ou en compilant la CLI depuis les sources, par exemple.

Pour ce tutoriel, vous allez installer la CLI depuis les sources :

git clone https://github.com/kyverno/kyverno
cd kyverno
make cli
cp ./cmd/cli/kubectl-kyverno/kyverno /usr/local/bin/kyverno

Vous devriez obtenir des résultats similaires à ceux-ci :

$ git clone https://github.com/kyverno/kyverno
Cloning into 'kyverno'...
remote: Enumerating objects: 64593, done.
remote: Counting objects: 100% (984/984), done.
remote: Compressing objects: 100% (496/496), done.
Receiving objects:   6% (3876/64593), 876.01 KiB | 1.60 MiB/s
Receiving objects:   6% (4222/64593), 876.01 KiB | 1.60 MiB/s
remote: Total 64593 (delta 531), reused 832 (delta 483), pack-reused 63609
Receiving objects: 100% (64593/64593), 55.81 MiB | 3.43 MiB/s, done.
Resolving deltas: 100% (35868/35868), done.

$ cd kyverno

$ make cli
GOOS=darwin go build -o /Users/avache/git/github.com/kyverno/kyverno/cmd/cli/kubectl-kyverno/kyverno -ldflags="-s -w -X github.com/kyverno/kyverno/pkg/version.BuildVersion=v1.5.0-rc1-223-gf0359f82 -X github.com/kyverno/kyverno/pkg/version.BuildHash=main/f0359f8272a181923db0704696803d44a43f69f8 -X github.com/kyverno/kyverno/pkg/version.BuildTime=2022-01-19_12:10:05" /Users/avache/git/github.com/kyverno/kyverno/cmd/cli/kubectl-kyverno/main.go
go: downloading k8s.io/klog v1.0.0
go: downloading github.com/spf13/cobra v1.2.1
go: downloading sigs.k8s.io/controller-runtime v0.10.3
go: downloading k8s.io/apiextensions-apiserver v0.22.4
go: downloading k8s.io/apimachinery v0.22.4
go: downloading k8s.io/klog/v2 v2.10.0
go: downloading sigs.k8s.io/yaml v1.3.0
go: downloading github.com/fatih/color v1.12.0
go: downloading github.com/go-git/go-billy/v5 v5.0.0
go: downloading github.com/go-git/go-git/v5 v5.2.0
go: downloading github.com/go-logr/logr v0.4.0
go: downloading github.com/kataras/tablewriter v0.0.0-20180708051242-e063d29b7c23
go: downloading github.com/lensesio/tableprinter v0.0.0-20201125135848-89e81fc956e7
go: downloading k8s.io/api v0.22.4
go: downloading k8s.io/cli-runtime v0.22.4
go: downloading github.com/evanphx/json-patch v4.11.0+incompatible
go: downloading k8s.io/client-go v0.22.4
go: downloading github.com/googleapis/gnostic v0.5.5
go: downloading github.com/kyverno/json-patch/v5 v5.5.1-0.20210915204938-7578f4ee9c77
go: downloading github.com/orcaman/concurrent-map v0.0.0-20190826125027-8c72a8bb44f6
go: downloading gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b
go: downloading k8s.io/kube-openapi v0.0.0-20211115234752-e816edb12b65
go: downloading github.com/distribution/distribution v2.7.1+incompatible
...
go: downloading github.com/dimchansky/utfbom v1.1.1

$ cp ./cmd/cli/kubectl-kyverno/kyverno /usr/local/bin/kyverno

Après l'installation, vérifiez que la CLI kyverno fonctionne :

kyverno version

Vous devriez obtenir un résultat similaire à celui-ci :

$ kyverno version
Version: v1.5.0-rc1-223-gf0359f82
Time: 2022-01-19_12:10:05
Git commit ID: main/f0359f8272a181923db0704696803d44a43f69f8

L'interface en ligne de commande (CLI) Kyverno est conçue pour valider et tester le comportement des politiques avant de les ajouter à un cluster.
La bonne pratique consiste donc à utiliser la CLI kyverno dans vos pipelines CI/CD afin d'accompagner le processus de rédaction des ressources et de garantir leur conformité aux standards avant leur déploiement.

Installation de Kyverno

Pour ce tutoriel, nous utilisons le chart Helm Kyverno.

Ajoutez le dépôt Helm Kyverno :

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

Ces commandes ajoutent le dépôt Helm Kyverno à votre dépôt local de charts Helm et mettent à jour les dépôts de charts installés :

$ helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
"kyverno" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "nvidia" chart repository
...
...Successfully got an update from the "kyverno" chart repository
...
Update Complete. ⎈Happy Helming!⎈

Installez la dernière version de Kyverno avec la commande helm install :

helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace

Cette commande installe la dernière version de Kyverno et crée un nouveau namespace kyverno :

$ helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
NAME: kyverno
LAST DEPLOYED: Wed Jan 19 11:41:15 2022
NAMESPACE: kyverno
STATUS: deployed
REVISION: 1
NOTES:
Thank you for installing kyverno v2.1.6 😀

Your release is named kyverno, app version v1.5.4

Vous pouvez vérifier que le pod Kyverno s'exécute correctement :

$ kubectl get pods -n kyverno
NAME                       READY   STATUS    RESTARTS   AGE
kyverno-554ffb4c96-f2lvs   1/1     Running   0          50s

Et vous pouvez vérifier que Kyverno a installé plusieurs webhooks sur votre cluster :

$ kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
NAME                                                                                                  WEBHOOKS   AGE
validatingwebhookconfiguration.admissionregistration.k8s.io/kyverno-policy-validating-webhook-cfg     1          52s
validatingwebhookconfiguration.admissionregistration.k8s.io/kyverno-resource-validating-webhook-cfg   2          52s

NAME                                                                                              WEBHOOKS   AGE
mutatingwebhookconfiguration.admissionregistration.k8s.io/kyverno-policy-mutating-webhook-cfg     1          52s
mutatingwebhookconfiguration.admissionregistration.k8s.io/kyverno-resource-mutating-webhook-cfg   2          52s
mutatingwebhookconfiguration.admissionregistration.k8s.io/kyverno-verify-mutating-webhook-cfg     1          52s

Créer et déployer des politiques

Kyverno s'exécute sur votre cluster OVHcloud Managed Kubernetes, vous pouvez donc désormais créer et déployer des politiques avec les règles que vous souhaitez mettre en place dans votre cluster.

Dans ce guide, nous allons vous montrer comment créer plusieurs politiques qui vont :

• refuser le déploiement de ressources dans le namespace default ;
• créer automatiquement une ConfigMap dans tous les namespaces sauf kube-system, kube-public et kyverno ;
• ajouter automatiquement un label aux Pods, Services, ConfigMaps et Secrets d'un namespace donné.

Politique 1 : interdire les déploiements dans le namespace default

Pour notre premier exemple, nous souhaitons interdire le déploiement de ressources dans le namespace default.

Pourquoi ? Parce qu'il est recommandé d'isoler les workloads/applications à l'aide de namespaces. Un namespace par projet/équipe/...
Ainsi, si plusieurs équipes déploient des applications différentes dans le namespace default, elles ne seront pas isolées.

Cette politique va valider si de nouvelles ressources peuvent être déployées ; nous allons donc créer une politique validate.

Créez une nouvelle politique dans un fichier policy-disallow-default-namespace.yaml :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-default-namespace
spec:
  validationFailureAction: enforce
  rules:
  - name: validate-namespace
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Using \"default\" namespace is not allowed."
      pattern:
        metadata:
          namespace: "!default"
  - name: require-namespace
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "A namespace is required."
      pattern:
        metadata:
          namespace: "?*"
  - name: validate-podcontroller-namespace
    match:
      resources:
        kinds:
        - DaemonSet
        - Deployment
        - Job
        - StatefulSet
    validate:
      message: "Using \"default\" namespace is not allowed for pod controllers."
      pattern:
        metadata:
          namespace: "!default"
  - name: require-podcontroller-namespace
    match:
      resources:
        kinds:
        - DaemonSet
        - Deployment
        - Job
        - StatefulSet
    validate:
      message: "A namespace is required for pod controllers."
      pattern:
        metadata:
          namespace: "?*"

Pour déployer la politique Kyverno dans le cluster, exécutez la commande suivante afin d'appliquer le fichier YAML :

kubectl apply -f policy-disallow-default-namespace.yaml

Après avoir appliqué la politique, vérifiez qu'elle a bien été appliquée sur le cluster :

$ kubectl apply -f policy-disallow-default-namespace.yaml
clusterpolicy.kyverno.io/disallow-default-namespace created

$ kubectl get clusterpolicy
NAME                         BACKGROUND   ACTION     READY
disallow-default-namespace   true         enforce    true

Vous allez maintenant essayer de déployer une application simple dans le namespace default.
Pour cela, créez un fichier nommé my-pod.yaml avec le contenu suivant :

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: hello-world
    image: ovhplatform/hello
    ports:
    - containerPort: 80

Appliquez-le sans définir de namespace (le namespace est default par défaut) :

kubectl apply -f my-pod.yaml

$ kubectl apply -f my-pod.yaml
Error from server: error when creating "my-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/my-pod was blocked due to the following policies

disallow-default-namespace:
  validate-namespace: 'validation error: Using "default" namespace is not allowed.
    Rule validate-namespace failed at path /metadata/namespace/'

Parfait, vous ne pouvez plus déployer de Pod/Deployment/ReplicaSet/Job/StatefulSet dans le namespace default.

Politique 2 : créer une ConfigMap dans tous les namespaces sauf kube-system, kube-public et kyverno

Pour notre second exemple, nous souhaitons créer une politique generate qui créera une nouvelle ConfigMap nommée zk-kafka-address dans tous les nouveaux namespaces, sauf kube-system, kube-public et kyverno.

Créez une nouvelle politique dans un fichier policy-generate-cm.yaml :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: zk-kafka-address
spec:
  rules:
  - name: k-kafka-address
    match:
      resources:
        kinds:
        - Namespace
    exclude:
      resources:
        namespaces:
        - kube-system
        - kube-public
        - kyverno
    generate:
      synchronize: true
      kind: ConfigMap
      name: zk-kafka-address
      # generate the resource in the new namespace
      namespace: "{{request.object.metadata.name}}"
      data:
        kind: ConfigMap
        metadata:
          labels:
            somekey: somevalue
        data:
          ZK_ADDRESS: "192.168.10.10:2181,192.168.10.11:2181,192.168.10.12:2181"
          KAFKA_ADDRESS: "192.168.10.13:9092,192.168.10.14:9092,192.168.10.15:9092"

Pour déployer la politique Kyverno dans le cluster, exécutez la commande suivante afin d'appliquer le fichier YAML :

kubectl apply -f policy-generate-cm.yaml

Après avoir appliqué la politique, vérifiez qu'elle a bien été appliquée sur le cluster :

$ kubectl apply -f policy-generate-cm.yaml
clusterpolicy.kyverno.io/zk-kafka-address created

$ kubectl get cpol -A
NAME                         BACKGROUND   ACTION    READY
disallow-default-namespace   true         enforce   true
zk-kafka-address             true         audit     true

La règle generate est déclenchée lors de l'opération API CREATE, donc dans le cas de cette politique, lors de la création d'un nouveau namespace.

Pour tester le comportement de cette politique, vous allez créer un nouveau namespace test2 :

kubectl create ns test2

Puis vérifiez que la nouvelle ConfigMap apparaît dans le nouveau namespace test2 :

kubectl get cm -A

Vous devriez obtenir des résultats similaires à ceux-ci :

$ kubectl create ns test2
namespace/test2 created

$ kubectl get cm -A
NAMESPACE         NAME                                 DATA   AGE
default           kube-root-ca.crt                     1      7d20h
kube-node-lease   kube-root-ca.crt                     1      7d20h
kube-public       kube-root-ca.crt                     1      7d20h
kube-system       canal-config                         5      7d20h
kube-system       coredns                              1      7d20h
kube-system       extension-apiserver-authentication   6      7d20h
kube-system       kube-dns-autoscaler                  1      7d20h
kube-system       kube-proxy                           1      7d20h
kube-system       kube-root-ca.crt                     1      7d20h
kyverno           kube-root-ca.crt                     1      7d19h
kyverno           kyverno                              2      7d19h
kyverno           kyverno-metrics                      1      7d19h
test              kube-root-ca.crt                     1      7d16h
test2             kube-root-ca.crt                     1      2m28s
test2             zk-kafka-address                     2      2m27s

Comme vous pouvez le constater, la ConfigMap zk-kafka-address a bien été créée dans le nouveau namespace test2.

Politique 3 : ajouter le label app: my-awesome-app aux Pods, Services, ConfigMaps et Secrets d'un namespace donné

L'objectif de cette politique est d'ajouter automatiquement le label app=my-awesome-app aux Pods, Services, ConfigMaps et Secrets du namespace team-a.

Pour cela, nous allons vous montrer comment déployer une politique mutate.

Créez une nouvelle politique dans un fichier policy-add-label.yaml :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-label    
spec:
  rules:
  - name: add-label
    match:
      resources:
        kinds:
        - Pod
        - Service
        - ConfigMap
        - Secret
        namespaces:
        - team-a
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            app: my-awesome-app

Pour déployer la politique Kyverno dans le cluster, exécutez la commande suivante afin d'appliquer le fichier YAML :

kubectl apply -f policy-add-label.yaml

Après avoir appliqué la politique, vérifiez qu'elle a bien été appliquée sur le cluster :

$ kubectl apply -f policy-add-label.yaml
clusterpolicy.kyverno.io/add-label created

$ kubectl get cpol -A
NAME                         BACKGROUND   ACTION    READY
add-label                    true         audit
disallow-default-namespace   true         enforce   true
zk-kafka-address             true         audit     true

Vous pouvez maintenant créer un nouveau namespace team-a, y déployer un nouveau Pod, puis vérifier que le nouveau label a bien été ajouté automatiquement :

kubectl create ns team-a
kubectl apply -f my-pod.yaml -n team-a
kubectl get pod my-pod -n team-a --show-labels

Vous devriez obtenir les résultats suivants :

$ kubectl create ns team-a
namespace/team-a created

$ kubectl apply -f my-pod.yaml -n team-a
pod/my-pod created

$ kubectl get pod my-pod -n team-a --show-labels
NAME     READY   STATUS    RESTARTS   AGE   LABELS
my-pod   1/1     Running   0          29s   app=my-awesome-app

Débogage/validation

Plus haut dans ce guide, nous vous avons montré comment installer la CLI kyverno. Avec cette CLI, vous pouvez appliquer, tester et valider des politiques.

Dans ce tutoriel, nous voulons vous montrer que cette CLI est idéale pour un usage sur votre machine locale (pour des usages de développement/test) et dans vos pipelines CI/CD, afin de tester et valider que les politiques que vous souhaitez déployer en production sont correctes.

Vous pouvez par exemple vérifier que les politiques créées sont valides avec la commande kyverno validate :

kyverno validate *.yaml

Vous devriez obtenir des résultats similaires à ceux-ci :

$ kyverno validate *.yaml
----------------------------------------------------------------------
Policy disallow-default-namespace is valid.

----------------------------------------------------------------------
Policy add-label is valid.

----------------------------------------------------------------------
Policy zk-kafka-address is valid.

Dépannage

Si vous rencontrez un problème avec Kyverno, par exemple si vous avez déployé une politique et ne comprenez pas pourquoi elle ne fonctionne pas, vous pouvez consulter la page de dépannage de Kyverno.

Et ensuite ?

Vous disposez désormais d'une gestion des politiques sur votre cluster Kubernetes, et vous avez déployé plusieurs politiques pour tester le comportement de Kyverno.
Pour voir davantage d'exemples de politiques, consultez le dépôt de politiques Kyverno. Ce dépôt contient des politiques Kyverno pour un large éventail d'usages sur diverses ressources et sujets de l'écosystème Kubernetes.

Si vous avez des questions ou rencontrez des difficultés avec Kyverno, vous pouvez également consulter la communauté Slack Kyverno.

Disposer d'une gestion des politiques est une bonne pratique à suivre. Cela vous aidera à garder votre cluster propre et sécurisé.
Un prochain tutoriel vous présentera une nouvelle méthode pour sécuriser vos clusters OVHcloud Managed Kubernetes.

Suppression (nettoyage)

Pour commencer, supprimez les ClusterPolicies déployées dans ce guide :

kubectl delete cpol --all

Pour désinstaller Kyverno, puisque vous l'avez installé via Helm, vous pouvez utiliser la commande helm uninstall afin de supprimer le chart Helm installé de Kyverno :

helm uninstall kyverno kyverno/kyverno --namespace kyverno

Aller plus loin

• Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

• Échangez avec notre communauté d'utilisateurs.