Politique on Zwindler's Reflection

Réforme des retraites - lettre ouverte à Bérangère Couillard

Mon, 27 Mar 2023 17:00:00 +0200

Note d’introduction

Une fois n’est pas coutume, je publie sur mon blog une lettre ouverte, postée il y a quelques jours, à une ministre en activité. ce billet a donc un aspect fortement politique.

Je sais d’avance que certains d’entre vous vont râler qu’un tech ne devrait parler que de tech sur son blog.

Réjouissez-vous pas avance, j’ai donc une astuce “purement tech” pour vous ! Si vous cliquez sur l’icône en forme de petite croix sur l’onglet actif de votre navigateur, cette page disparaitra et vous ne me verrez pas parler de politique. Pas mal hein ?

Lettre ouverte

A l’attention de Bérangère Couillard - Secrétaire d’État auprès du ministre de la Transition écologique et de la Cohésion des territoires, chargée de l’Écologie

Chère Madame Couillard,

Avant d’être nommée ministre, vous avez été élue députée de ma circonscription, et je souhaite donc m’adresser à vous, indépendamment de mon vote lors des élections législatives.

Allons droit au but : il est nécessaire que vous fassiez tout ce qui est en votre pouvoir pour empêcher la réforme des retraites (voulue par le gouvernement dont vous faites partie) ne voit le jour. Je vais détailler ici pourquoi.

D’abord, c’est une réforme inutile. C’est l’argument principal mis en avant par la première ministre pour la justifier : “il faudrait réformer le système pour le sauver”.

Cependant, une rapide recherche montre que les divers experts, conseil d’orientation des retraites inclus, montrent que ce n’est pas le cas (1). Selon les hypothèses, le système est faiblement déficitaire (on parle de quelques euros par mois et par actif) et retrouve l’équilibre à moyen terme. L’espérance de vie n’augmente plus et le papy boom prendra fin vers 2035.

Ensuite, la mécanisation, l’automatisation, le numérique, les gains de productivité en tous genres font qu’il y a de moins en moins de travail. Ce n’est pas une fatalité, c’est même souhaitable.

Travailler moins, c’est d’ailleurs travailler mieux. La récente étude sur la semaine de 4 jours en Angleterre en est un bon exemple. Forcer les gens à travailler plus, plus longtemps, c’est aller contre le sens de l’histoire.

Cette réforme va aussi créer de nouveaux problèmes.

Le premier est l’emploi des seniors (ou plutôt son absence) et des coûts supplémentaires pour l’assurance maladie. Aujourd’hui, le taux de chômage chez les seniors en France, même s’il s’améliore, reste catastrophique par rapport à nos partenaires européens.

Pousser l’âge de départ, c’est aggraver ces problèmes, sans apporter de réelles solutions.

Des membres du gouvernement ont également reconnu que la réforme allait pénaliser les femmes, notamment en annulant l’effet positif des trimestres de majoration pour naissance.

Pour rappel, l’objectif affiché de la majoration de trimestre est de réduire les inégalités (actuelles, réelles) à la retraite (future) entre les hommes et les femmes, notamment à cause des impacts négatifs qu’ont pu avoir les naissances d’enfants sur les carrières des femmes (induisant ainsi un revenu inférieur à terme). Il ne semble pas réaliste d’imaginer qu’on trouvera une baguette magique pour effacer rétroactivement les différences de salaires entre les hommes et les femmes.

Les membres du gouvernement ont été incapables de montrer en quoi cette réforme allait apporter des avancées en contrepartie des efforts demandés. Il a été prouvé que les 1200€ ne bénéficieraient qu’à une infime part de retraités. Olivier Dussopt l’a lui-même reconnu. Il n’y a aucun détail sur ce qui est fait pour les carrières hachées. Les seules certitudes sont les reculs sociaux. (2)

Pour toutes ces raisons, j’en appelle à votre responsabilité en tant qu’élue, en tant que membre du gouvernement et peut être même avant tout en tant que femme ?

Vous vous définissez d’ailleurs vous même comme féministe, je suis convaincu que défendre les droits des femmes à vivre dans un monde plus juste vous tient à coeur.

Il est de votre devoir de tout faire pour empêcher que cette réforme, aussi injuste qu’inutile, ne voit le jour.

Dans l’espoir de vous lire, je vous présente, madame la ministre, l’expression de mes salutations distinguées. Denis GERMAIN, ingénieur en informatique, habitant de la septième circonscription de Gironde.

Notes

(1) : post publication de cette lettre ouverte, on m’a fait remarqué que le COR ne dit pas totalement qu’il n’est pas nécessaire de réformer. En revanche, il dit qu’il n’est pas URGENT de réformer, car le système n’est pas sur le point d’imploser

les résultats de ce rapport ne valident pas le bien-fondé des discours qui mettent en avant l’idée d’une dynamique non contrôlée des dépenses de retraite

https://www.cor-retraites.fr/sites/default/files/2023-02/RA_COR2022_def.pdf

Or, c’était bien l’argument matraqué dans les médias par la PM et le reste du gouvernement.

(2): on m’a aussi fait remarquer que le problème des séniors et du chômage était aussi un problème lié à la pénibilité. J’ai effectivement oublié de parler de ce point. Les plus touchés par cette réforme seront ceux dont les métiers sont les plus pénibles, pas les cols blancs (dont Madame Couillard et moi même faisons partie).

Note finale

Si d’aventure j’avais une réponse de Mme Couillard ou de son cabinet, je ne manquerais pas de vous en faire part.

Vos politiques de conformité sur Kubernetes avec Kyverno - part 2

Mon, 05 Sep 2022 06:00:00 +0200

Récap’ de la partie 1

Dans le précédent article, j’ai introduit Kyverno, un outil “cloud native” pour gérer des politiques de conformité sur Kubernetes.

Pour illustrer les capacités de l’outil, j’avais pris un exemple : empêcher deux Ingress d’utiliser la même URL d’entrée. J’avais fait le même exercice avec OPA dans un article précédent (Open Policy Agent (OPA) et de son pendant dans Kubernetes, Gatekeeper) et j’avais comparé à la fin les deux syntaxes (Kyverno vs rego).

J’ai une nette préférence pour la syntaxe de Kyverno, même si OPA est là depuis plus longtemps et n’est pas limité à Kubernetes (Kyverno c’est uniquement pour Kube).

Aller un peu plus loin

Au-delà de mon exemple, j’ai indiqué que Kyverno mettait à disposition un très grand nombre de politiques déjà écrites pour vous (191 au moment où j’écris l’article).

kyverno.io/policies

Par défaut, la plupart des politiques disponibles sont positionnées en mode “audit” dans un premier temps. N’oubliez pas de la passer en mode “enforce” quand vous serez assez mature sur votre cluster.

Évidemment, quand on débute on ne sait pas trop par quoi commencer. Le plus simple dans ce cas-là est de déployer la chart Helm kyverno/kyverno-policies, qui contient l’équivalent des Kyverno des “Pod Security Standards” (les PSP étant officiellement obsolètes depuis la 1.21 je crois, et plus utilisables en 1.25).

helm install kyverno-policies kyverno/kyverno-policies -n kyverno
[...]
Thank you for installing kyverno-policies v2.5.2 😀

We have installed the "baseline" profile of Pod Security Standards and set them in audit mode.

Visit https://kyverno.io/policies/ to find more sample policies.

Voilà ce que ça nous a déployé (la dernière étant déjà là à cause de l’article précédent)

kubectl get clusterpolicy
NAME BACKGROUND ACTION READY
disallow-capabilities true audit true
disallow-host-namespaces true audit true
disallow-host-path true audit true
disallow-host-ports true audit true
disallow-host-process true audit true
disallow-privileged-containers true audit true
disallow-proc-mount true audit true
disallow-selinux true audit true
restrict-apparmor-profiles true audit true
restrict-seccomp true audit true
restrict-sysctls true audit true
unique-ingress-host false enforce true

Avec ça, on va déjà avoir pas mal de pain sur la planche pour éduquer nos utilisateurs (les développeurs) à produire des déploiements Kubernetes sécurisés.

User experience

Un des points ennuyeux de ces deux outils, c’est que de base, ils ne sont pas très user friendly. Moi, faire une commande kubectl get events (voire kubectl get events --field-selector=reason=PolicyViolation dans le cas de Kyverno) pour savoir pourquoi un déploiement a échoué, ça ne m’ennuie pas trop (ça m’amuse, presque).

Mais pour certaines personnes, c’est un peu rebutant et je peux l’entendre.

Mon but c’est de rendre l’infrastructure plus simple à des gens dont qui ce n’est pas le métier et imposer ma façon de travailler n’est pas forcément la meilleure méthode.

Souvent, pour aider à adopter un nouvel outil / usage, le plus simple c’est de lui fournir une interface graphique.

Et ça tombe bien, Kyverno dispose d’un outil pour faire ça.

Kyverno policy reporter

En réalité, l’outil ne sert pas tout à fait à ça, à la base. Mais vous allez voir que c’est même encore mieux.

Historiquement, l’outil s’appelle policy reporter, car les développeurs avaient besoin d’un outil permettant d’exporter facilement et rapidement les PolicyReports dont je parle dans l’article précédent :

kubectl describe policyreport polr-ns-default
Name: polr-ns-default
Namespace: default
Labels: managed-by=kyverno
Annotations: <none>
API Version: wgpolicyk8s.io/v1alpha2
Kind: PolicyReport
[...]
Results:
 Category: Sample
 Message: The Ingress host name must be unique.
 Policy: unique-ingress-host
 Resources:
 API Version: networking.k8s.io/v1
 Kind: Ingress
 Name: ingress2
[...]
Summary:
 Error: 0
 Fail: 2
 Pass: 0
 Skip: 2
 Warn: 0

Le policy reporter a donc pour rôle d’exporter les PolicyReports vers plusieurs sources externes pour les traiter plus facilement :

Grafana Loki
Elasticsearch
Slack
Discord
MS Teams
Policy Reporter UI
S3

Je vais vous en parler de 2 : slack et Policy Reporter UI

Policy Reporter UI

Je commence par l’UI, car c’est le plus simple à configurer. Il suffit juste de déployer la Chart helm de Policy Reporter en oubliant pas de spécifier qu’on veut l’UI :

helm repo add policy-reporter https://kyverno.github.io/policy-reporter
helm repo update
helm install -n kyverno policy-reporter policy-reporter/policy-reporter --set kyvernoPlugin.enabled=true --set ui.enabled=true --set ui.plugins.kyverno=true

kubectl -n kyverno get pods
NAME READY STATUS RESTARTS AGE
kyverno-5f8bfd6fc5-xp6bm 1/1 Running 1 (59m ago) 33d
policy-reporter-74cc9bf4b9-9ggwh 1/1 Running 0 18s
policy-reporter-kyverno-plugin-6b48c4bc5f-5rwfb 1/1 Running 0 18s
policy-reporter-ui-5c9449d58-f9fwf 1/1 Running 0 18s

On peut évidemment ajouter un Ingress mais si on est fénéant comme moi dans cette démo un simple port-forward suffit 🙃.

kubectl port-forward service/policy-reporter-ui 8082:8080 -n kyverno

L’UI en elle-même est assez intuitive. On a notamment :

un Dashboard avec un gros indicateur global pour savoir combien on a de violation de politiques
une page avec nos “policy reports”, dans lequel on peut filtrer par namespace ou par politique
la liste de nos politiques
…

Slack

On voit tout de suite l’intérêt d’alerter les administrateurs dans Slack (ou Teams 😭) si jamais une violation de la politique arrive.

On voit que la configuration est assez triviale, on a juste à ajouter un webhook dans Slack et un petit bout de configuration dans Kyverno

kyvernoPlugin:
 enabled: true
ui:
 enabled: true
 plugins:
 kyverno: true
target:
 slack:
 webhook: "https://hooks.slack.com/services/T0xxxxxxxx"
 minimumPriority: "medium"
 skipExistingOnStartup: true
 sources:
 - kyverno

Et on re-applique tout ça à notre release helm

helm upgrade -n kyverno policy-reporter policy-reporter/policy-reporter -f kyverno-values.yaml

Note: Si vous ne savez pas comment faire, il faut être admin du workspace Slack, créer une application dans https://api.slack.com/apps, activer les Incoming Webhooks et en créer un en lui donnant les droits sur un channel.

Et si on faisait une violation de politique, pour voir ?

Pour faire simple, je suis reparti de l’exemple de l’article précédent. Je repasse ma politique unique-ingress-host en mode audit et je recréé l’ingress problématique :

kubectl edit clusterpolicy unique-ingress-host
kubectl apply -f ingress2.yaml

Instantanément, j’ai bien 2 échecs qui apparaissent dans l’UI de Kyverno, ainsi que des messages dans Slack

Victoire :)

Ressources complémentaires

Vos politiques de conformité sur Kubernetes avec Kyverno

Mon, 01 Aug 2022 06:00:00 +0000

Introduction

Si le titre de cet article vous dit quelque chose, c’est peut-être parce que je l’ai déjà utilisé il y a 2 ans tout pile pour parler d’un autre logiciel de gestion de politiques de conformité : Open Policy Agent (OPA) et de son pendant dans Kubernetes, Gatekeeper.

Et je ne vais pas mentir, je n’ai pas beaucoup refait de l’OPA depuis cet article de 2020…

La première raison est que j’ai changé d’entreprise pile à ce moment-là et que j’avais d’autres priorités dans la nouvelle entreprise qui m’emploie.

La seconde, certainement plus vraie mais peut être aussi moins avouable, c’est qu’OPA c’est quand même pas super user friendly. Notamment à cause du rego, le langage des politiques de conformités.

Depuis, j’ai découvert Kyverno, un petit nouveau dans le “cloud native” game (promu au niveau de “sandbox CNCF” depuis peu) et qui propose des politiques de conformité pour Kubernetes uniquement (contrairement à OPA + rego qui sont généralistes), écrites en YAML.

With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies.

Prends toi ça, rego ;-)

Note : Cet article va rester relativement simple, c’est une introduction. On ira plus loin dans les articles suivants (coder sa propre politique, l’UI, etc).

Je ne vais pas beaucoup innover par rapport à l’article sur OPA et repartir du même cas d’usage : interdire à deux développeurs d’utiliser la même URL pour leur app web déployée dans Kubernetes (car on a vu que c’était assez nul quand ça arrive).

Et vous allez voir que la première marche d’apprentissage est BEAAAAUCOUP plus accessible avec Kyverno que OPA (même si ça va faire râler la moitié de mon Twitter que je parle encore de YAML 🤣).

Prérequis

Même topo que pour OPA / Gatekeeper, il faut la 1.14 de Kube pour utiliser Kyverno. La 1.14 était déjà pas la plus récente en 2020, c’est carrément la préhistoire maintenant ;-).

Your Kubernetes cluster version must be above v1.14 which adds webhook timeouts.

Bien évidemment, il faut également avoir les droits d’accès admin sur le cluster, car on va devoir créer des Validating Admission Webhooks et des CRDs. Là encore, je vous renvoie au précédent article et à la doc officielle si ça ne vous parle pas.

Pour faire bref, on va s’insérer dans le processus de déploiement de Kubernetes pour interdire aux gens de faire des choses qui ne respectent pas vos bonnes pratiques (avec les webhooks) et on va ajouter des APIs supplémentaires pour étendre Kubernetes (les CRDs), de manière à pouvoir décrire qu’est ce qui n’est pas autorisé.

Déploiement

Niveau installation, on reste sur du simple et efficace.

Kyverno propose plusieurs Charts helm :

une pour Kyverno même
une pour Policy Reporter
une contenant un “pack” de règles par défaut, configurées comme “non bloquantes” (en vrai, l’équivalent de ce qu’on pouvait faire avec les Pods Security policies)

Dans le cadre de cet article, je ne m’intéresse qu’à Kyverno même. Mais comme je l’ai dis plus haut, on reparlera des 2 suivantes dans un prochain numéro.

On commence donc par ajouter Kyverno lui-même :

$ helm repo add kyverno https://kyverno.github.io/kyverno/
$ helm repo update
$ helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
 NAME: kyverno
 LAST DEPLOYED: Mon Jul 25 21:55:11 2022
 NAMESPACE: kyverno
 STATUS: deployed
 REVISION: 1
 NOTES:
 Chart version: v2.5.2
 Kyverno version: v1.7.2

 Thank you for installing kyverno! Your release is named kyverno.
 ⚠️ WARNING: Setting replicas count below 3 means Kyverno is not running in high availability mode.

 💡 Note: There is a trade-off when deciding which approach to take regarding Namespace exclusions. Please see the documentation at https://kyverno.io/docs/installation/#security-vs-operability to understand the risks.

Note : vous remarquerez le WARNING à l’install. Par défaut, Kyverno est déployé avec un seul replica. S’il crashe, vous ne pouvez plus rien déployer ou modifier sur votre cluster (ça m’est arrivé). La solution pour s’en sortir est de supprimer les webhooks de Kyverno pour débloquer la situation. Et bien sûr, de lui donner plus d’air (de plus grandes limites, surtout niveau RAM) et surtout 3 réplicas (ou plus)…

Note 2 : Il est probablement préférable d’exclure certains namespaces (kube-system, kyverno, …) du scope de Kyverno pour éviter de mauvaises surprises. Le blogpost Thibault Lengagne de chez Padok en parle aussi (lien en bas de l’article).

Qu’est-ce qu’on a déployé ?

A première vue, pas grande chose. Si on fait un kubectl -n kyverno get all, on trouve juste un Pod (+ReplicaSet +Deplopyment) et deux Services.

Mais en coulisse, on a déployé bien plus que ça ;)

Si on cherche des CRDs, on voit qu’on a pas mal de nouveaux objets à notre disposition.

$ kubectl api-resources --api-group=kyverno.io
 NAME SHORTNAMES APIVERSION NAMESPACED KIND
 clusterpolicies cpol kyverno.io/v1 false ClusterPolicy
 clusterreportchangerequests crcr kyverno.io/v1alpha2 false ClusterReportChangeRequest
 generaterequests gr kyverno.io/v1 true GenerateRequest
 policies pol kyverno.io/v1 true Policy
 reportchangerequests rcr kyverno.io/v1alpha2 true ReportChangeRequest
 updaterequests ur kyverno.io/v1beta1 true UpdateRequest

De même, on a également des nouveaux webhooks

$ kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io
 NAME WEBHOOKS AGE
 kyverno-policy-validating-webhook-cfg 1 8m48s
 kyverno-resource-validating-webhook-cfg 2 8m48s

$ kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io
 NAME WEBHOOKS AGE
 kyverno-policy-mutating-webhook-cfg 1 11m
 kyverno-resource-mutating-webhook-cfg 2 11m
 kyverno-verify-mutating-webhook-cfg 1 11m

A quoi ça sert ? Comment ça marche ?

Pour simplifier, on va décrire ce qu’on ne veut pas autoriser dans notre cluster à l’aide de la CRD ClusterPolicy.

En fonction des règles qu’on aura écrites dedans, les webhooks vont s’insérer dans le processus normal de déploiement de ressources de Kubernetes pour les autoriser ou pas.

Kubernetes Blog - A Guide to Kubernetes Admission Controllers

Exemple des Ingress avec la même URL

Assez de théorie, le plus simple c’est que je vous montre. Je vous l’ai dit au début de l’article, de manière à comparer les deux produits, je vais repartir du même cas d’usage.

Dans mes clusters Kubernetes, je veux interdire à deux applications de créer un Ingress avec la même URL, car dans mon cas personnel, ce n’est pas autorisé. C’est le signe d’une erreur de copié-collé d’une Chart Helm vers une autre (ou tout autre erreur humaine).

La conséquence de cette erreur est un conflit dans le routage des requêtes HTTP entrantes et on se retrouve avec un genre de round robin chelou où la moitié des requêtes tapent le mauvais backend. En prod, ça la fout mal, et on risque de se retrouver avec des clients qui râlent sur Twitter que l’application est down ;-).

Au même titre qu’OPA propose de régler ce problème dans les politiques mises à disposition par la communauté, il existe la même avec Kyverno.

On verra plus en détails dans l’article suivant comment sont construites ces règles. Dans un premier temps, on va juste déployer cette règle en mode “audit” et voir si ça fonctionne.

spec: validationFailureAction: audit

$ kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/unique-ingress-paths/unique-ingress-paths.yaml
 clusterpolicy.kyverno.io/unique-ingress-host created

Si vous avez un cluster kubernetes sous la main, je vous propose donc d’appliquer ces deux Ingress, configurés pour récupérer du trafic depuis la même URL (toto.example.org) :

$ for counter in 1 2; do
cat > ingress${counter}.yaml <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: ingress${counter}
spec:
 rules:
 - host: toto.example.org
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: service${counter}
 port:
 number: 4200
EOF
done

$ kubectl apply -f ingress1.yaml
 ingress.networking.k8s.io/ingress1 created
$ kubectl apply -f ingress2.yaml
 ingress.networking.k8s.io/ingress2 created

Normalement, rien ne se passe. Kyverno ne vous empêche pas de créer ces deux Ingress puisqu’on est en mode “validationFailureAction: audit” (même si les backends n’existent pas derrière, ça n’a pas d’importance).

$ kubectl get ingress
 NAME CLASS HOSTS ADDRESS PORTS AGE
 ingress1 <none> toto.example.org 80 90s
 ingress2 <none> toto.example.org 80 87s

En revanche, en allant lire les Events, vous allez trouver des PolicyViolation :

$ kubectl get events --field-selector=reason=PolicyViolation
LAST SEEN TYPE REASON OBJECT MESSAGE
118s Warning PolicyViolation ingress/ingress1 policy unique-ingress-host/check-single-host fail: The Ingress host name must be unique.
118s Warning PolicyViolation ingress/ingress1 policy unique-ingress-host/check-single-host fail: The Ingress host name must be unique.
118s Warning PolicyViolation clusterpolicy/unique-ingress-host Ingress default/ingress1: [check-single-host] fail
115s Warning PolicyViolation clusterpolicy/unique-ingress-host Ingress default/ingress2: [check-single-host] fail

Le fait qu’on ait 2 Ingress pointant sur la même URL est bien détecté et est remonté dans les Events Kubernetes. Chouette :)

En beaucoup plus verbeux, on pourra également récupérer les PolicyReports, qui disent la même chose en (encore ?) moins lisible.

kubectl describe policyreport polr-ns-default
Name: polr-ns-default
Namespace: default
Labels: managed-by=kyverno
Annotations: <none>
API Version: wgpolicyk8s.io/v1alpha2
Kind: PolicyReport
[...]
Results:
 Category: Sample
 Message: The Ingress host name must be unique.
 Policy: unique-ingress-host
 Resources:
 API Version: networking.k8s.io/v1
 Kind: Ingress
 Name: ingress2
[...]
Summary:
 Error: 0
 Fail: 2
 Pass: 0
 Skip: 2
 Warn: 0

On nettoie pour la suite :

$ kubectl delete ingress ingress1 ingress2

“La loi, c’est moi”

Imaginons que vous avez maintenant bien testé vos politiques, que vos devs ne génèrent plus de manifests ne correspondant pas à vos bonnes pratiques (ex. pas de containers en root, des labels obligatoires présents, limits/requests correctes, etc). Votre cluster est propre !

Vous pouvez passer vos politiques de conformités en mode “enforcing”. Contrairement au mode “audit”, ce mode est bloquant et les manifests qui ne respectent pas les politiques en questions seront refusés par Kubernetes.

$ kubectl patch clusterpolicies.kyverno.io unique-ingress-host --patch '{"spec":{"validationFailureAction":"enforce"}}' --type merge

Oui, je fais un “patch” plutôt qu’un “edit” pour me la péter ;-)

Et on teste à nouveau :

$ kubectl apply -f ingress1.yaml
 ingress.networking.k8s.io/ingress1 created

So far, so good

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

resource Ingress/default/ingress2.yaml was blocked due to the following policies

unique-ingress-host:
 check-single-host: The Ingress host name must be unique.

ET PAF 💥🍫!

Conclusion

Dans cet exemple basique (mais réellement utile), on arrive aussi facilement qu’avec OPA à empêcher les utilisateurs de créer des Ingress ayant la même URL.

On peut alors se demander “pourquoi préférer Kyverno ?”. Au-delà d’autres trucs sympas que nous verrons dans les billets suivants, ma réponse va tenir en une seule image.

Mon point de vue (très personnel), c’est que le rego, c’est illisible et verbeux, et donc pas maintenable. Là encore, c’est personnel, mais je n’ai jamais réussi à m’y mettre.

Sans aller jusqu’à idéaliser le langage de Kyverno*, je trouve que c’est quand même clairement beaucoup plus simple à écrire, mais surtout, à lire. Dans le cas où vous devriez modifier/écrire/maintenir vos propres politiques, cela sera très utile.

(*Oui, il y a un langage, notamment pour le pattern matching… et point irritant, ce n’est pas jsonpath comme pour kubectl, mais JMESPath, similaire mais pas identique…)

Ressources complémentaires

Vos politiques de conformité sur Kubernetes avec OPA et Gatekeeper

Mon, 20 Jul 2020 06:35:00 +0000

Introduction

Un des problèmes que j’ai rencontré en administrant des clusters Kubernetes mutualisés entre plusieurs équipes était que les manifests qui étaient déployés n’étaient pas toujours parfaitement maîtrisés.

Dans certains cas, les manifests étaient copiés/collés d’autres équipes, provoquant parfois de petites surprises (pas de label pour indiquer l’équipe responsable de l’appli, mauvaises infos pour les Ingress…). Une des solutions trouvée a été de maintenir à jour un Chart Helm le plus générique possible, avec seulement des values à rentrer pour les développeurs. Ce Chart est maintenu conjointement par les Ops et les techleads.

Cependant, maintenir ce template est complexe et certaines applis s’éloignent trop du cadre général pour s’y conformer, même en forkant et en modifiant une partie des infos. Et certains problèmes comme la vérification des images ou des registries tournant sur la plateforme n’étaient pas traités par cette solution.

Open Policy Agent / Gatekeeper

https://www.thingiverse.com/thing:1236133

Plutôt que de vouloir unifier à tout prix la façon dont sont déployées les applications dans le cluster (et devoir gérer les exceptions), une autre façon de voir les choses est d’ajouter un outil qui permettrait de vérifier, au moment où on déploie, que ce qui est déployé respecte les bonnes pratiques de l’entreprise en termes de sécurité et de configuration.

Vous l’avez deviné, l’outil pour faire ça, c’est Open Policy Agent (ou OPA). Il s’agit d’un moteur de politiques générique open source (projet CNCF au stade Incubating).

Comme c’est un moteur générique, il existe également un autre projet,Gatekeeper, qui lui permet de gérer l’interaction entre OPA et Kubernetes.

Prérequis

To use Gatekeeper, you should have a minimum Kubernetes version of 1.14, which adds webhook timeouts.

Si vous êtes dans une version antérieure, ça se complique. Il existe un bug, fixé en 1.14, qui pourra faire planter votre OPA/Gatekeeper. Pour cette raison, si vous n’êtes pas en 1.14 (et que vous ne pouvez pas mettre à jour votre plateforme), il faudra se passer de Gatekeeper (via K8s Policy Controller par exemple). C’est un peu plus touchy et hors du scope de ce tutoriel.

La « V2 », sans Gatekeeper, avec Kube-Mgmt et OPA

Bien évidemment, il faut également avoir les droits d’accès admin sur le cluster. Gatekeeper propose de tester que vous avez des droits adéquats simplement en essayant de vous attribuer à vous-même les droits admins.

wait for it

kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole cluster-admin \
--user [votre user]

Petite astuce, si vous ne connaissez pas le nom du compte d’accès que vous utilisez actuellement, vous pouvez lancer cette commande :

kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}'
Current user: clusterUser_zwindlerk8s_rg_zwindlerk8s

Installation

Je me suis donc créé pour l’occasion un petit cluster sur AKS en version 1.14 et j’ai déployé la version prépackagée de Gatekeeper.

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

Tadam ! Et hop, Gatekeeper est installé dans votre cluster. Note : La documentation officielle donne les étapes pour construire vous-même votre image.

Ya quoi dans mon cluster ?

En se penchant de plus près sur ce que fait le manifest, voici ce que vous déployez lorsque vous lancez la commande ci-dessus :

un Namespace gatekeeper-system
un ServiceAccount gatekeeper-admin, associé à un Role et un ClusterRole gatekeeper-manager-role via (respectivement) un RoleBinding et ClusterRoleBinding gatekeeper-manager-rolebinding
un Deployment gatekeeper-controller-manager et gatekeeper-audit
un Service gatekeeper-webhook-service
un Secret gatekeeper-webhook-server-cert qui contient un certificat

Jusque-là rien d’exceptionnel. Là où ça commence à devenir intéressant c’est :

deux CRD (Custom Resource Definition) configs.config.gatekeeper.sh et constrainttemplates.templates.gatekeeper.sh
un validating webhook configuration gatekeeper-validating-webhook-configuration

Validating Webhook

Le validation webhook d’abord. La première fois que j’ai entendu parler de validating webhooks, c’était lors du talk 101 Ways to “Break and Recover” Kubernetes Cluster à la Kubecon 2018.

Les problèmes de ces employés de Oath (ex-Yahoo) étaient identiques aux miens. Certaines équipes, en récupérant (aka copiant/collant) des manifests provenant d’autres équipes, oubliaient de changer les URL des Ingress. On se retrouvait ainsi avec des requêtes d’utilisateurs qui se retrouvaient distribuées de manière aléatoires vers 2 services totalement différents.

La solution proposée à cette conf était d’utiliser des Validating/Mutating Admission Webhooks de Kubernetes (à peu près stable depuis la 1.11).

En 2018, en creusant le sujet, j’ai trouvé assez peu de documentation là-dessus, au-delà de la doc officielle (j’en ai trouvé un peu plus depuis). Autre problème, les Admissions webhooks nécessitent de développer son propre Controller, ce qui n’était pas très accessible (cf les liens en fin d’article).

Heureusement pour nous, Gatekeeper et OPA vont s’occuper de ça pour nous.

Custom Resource Definition

Pour ceux qui ne connaissent pas les CRD, il s’agit pour faire simple des extensions de l’API de Kubernetes. Le gros avantage des CRDs est que ces objets sont un moyen pour les éditeurs tiers d’ajouter de la logique qui leur est propre dans Kubernetes. J’ai déjà un peu parlé de CRD dans cet article sur Rook qui permet de gérer de manière automatisée des clusters Ceph (et pas que !) via le CRD CephCluster. Toutes les tâches d’administration courantes sont intégrées à Kubernetes (alors que de base Kube n’en a aucune connaissance), gérées par un Controller inclus dans Rook et configurées via des CRDs.

Gatekeeper va donc ajouter 3 composants à notre Kubernetes :

un objet Config
un objet ConstraintTemplate
un objet Constraint

Config

Le principe de Gatekeeper, comme on le voit dans le schéma suivant, est qu’il se branche sur l’API server de votre Kubernetes et qu’il “synchronise” les événements de création de nouveaux objets, à la recherche d’objets qui ne respecteraient pas vos politiques de conformité.

Source : kubernetes.io/blog

Par défaut, si vous ne lui dites rien, Gatekeeper n’écoute les événements d’aucuns objets Kubernetes… il ne fera donc… rien du tout !

On change ça tout de suite en disant à Gatekeeper d’écouter tous les événements sur les Ingress :

cat gatekeeper/demo/basic/sync.yaml
apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
name: config
namespace: "gatekeeper-system"
spec:
sync:
syncOnly:
- group: "extensions"
version: "v1beta1"
kind: "Ingress"
- group: "networking.k8s.io"
version: "v1beta1"
kind: "Ingress"

ConstraintTemplate

Before you can define a constraint, you must first define a ConstraintTemplate, which describes both the Rego that enforces the constraint and the schema of the constraint.

L’idée ici, c’est qu’avant de commencer à créer des contraintes sur le cluster, il va falloir créer des templates de contraintes. Il faut voir ces templates comme l’objet qui va relier d’un côté la fonction (le code en rego d’OPA) d’un côté et des paramètres de l’autre.

Cette étape supplémentaire nous permettra éventuellement de réutiliser le même template pour plusieurs contraintes différentes.

Votre premier template

Pour la première fois, on peut se contenter d’utiliser les templates fournis en exemple sur le Github de OPA/Gatekeeper et qui permet d’imposer la présence d’un label dans un type d’objet Kube donné, car il est plus simple (k8srequiredlabels_template.yaml)

Cependant, depuis tout à l’heure, je vous parle d’empêcher les équipes d’utiliser le même FQDN dans des Ingress pour plusieurs services. Car si ça venait à arriver, je le rappelle, on aurait un genre de loadbalancer chelou qui redirigerait la moitié des requêtes des utilisateurs sur une application ou sur l’autre pour une même URL.

Et ça tombe bien, ce template va nous permettre de nous en assurer !

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8suniqueingresshost
spec:
crd:
spec:
names:
kind: K8sUniqueIngressHost
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8suniqueingresshost
identical(obj, review) {
obj.metadata.namespace == review.object.metadata.namespace
obj.metadata.name == review.object.metadata.name
}
violation[{"msg": msg}] {
input.review.kind.kind == "Ingress"
re_match("^(extensions|networking.k8s.io)$", input.review.kind.group)
host := input.review.object.spec.rules[_].host
other := data.inventory.namespace[ns][otherapiversion]["Ingress"][name]
re_match("^(extensions|networking.k8s.io)/.+$", otherapiversion)
other.spec.rules[_].host == host
not identical(other, input.review)
msg := sprintf("ingress host conflicts with an existing ingress <%v>", [host])
}

Au premier abord, c’est quand même assez touffu. Bon après, j’ai pas pris l’exemple le plus simple non plus, et si vous re-regardez la vidéo Kubecon 2019 | Intro: Open Policy Agent - Rita Zhang, Microsoft & Max Smythe, Google, c’est en fait assez simple à comprendre.

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/dryrun/k8suniqueingresshost_template.yaml
constrainttemplate.templates.gatekeeper.sh/k8suniqueingresshost created
kubectl get constrainttemplate
NAME AGE
k8suniqueingresshost 23m

Et une Constraint

Maintenant qu’on a notre template, on peut donc simplement l’instancier avec les variables qui nous intéressent.

Pour rester dans l’exemple en démo, on s’assure que dans tout le cluster, il n’existe pas 2 fois la même URL pour 2 Ingress différents en instanciant cette contrainte :

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sUniqueIngressHost
metadata:
name: unique-ingress-host
spec:
enforcementAction: dryrun
match:
kinds:
- apiGroups: ["extensions", "networking.k8s.io"]
kinds: ["Ingress"]

Je vais un tout petit peu modifier cette Contrainte car comme vous pouvez le voir, elle définie une enforcementAction: dryrun, qui n’a pas d’effet immédiat (ça logue juste une erreur pour un audit futur). C’est une super feature qui permet de monter en compétence sur OPA, mais pour ma démo c’est moins fun…

Donc j’applique le fichier et je modifie l’enforcementAction

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/dryrun/unique-ingress-host.yaml
kubectl patch K8sUniqueIngressHost.constraints.gatekeeper.sh unique-ingress-host -p '{"spec":{"enforcementAction":"deny"}}' --type=merge

Et enfin, on essaye

Normalement on a tout maintenant. Gatekeeper écoute sur l’API server tous les événements des objets de type Ingress (via la Config). On a un ContraintTemplate avec du code rego qui va vérifier qu’on a pas déjà une autre URL identique dans les Ingress existant et une Constraint qui définie ce qu’on doit faire (dryrun) et sur quels objets (Ingress).

On peut donc dérouler la démo :D

# Creation du namespace qui contiendra les objets de la demo
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/bad_resources/namespace.yaml
namespace/production created
# Creation d'un Ingress avec une URL qui n'existe pas encore
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/dryrun/existing_resources/example.yaml
ingress.extensions/ingress-host created
# Creation d'un second Ingress avec la MEME URL
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/dryrun/bad_resource/duplicate_ing.yaml

Et paf !

[denied by unique-ingress-host] ingress host conflicts with an existing ingress <example-host.example.org>

Conclusion

Je l’expliquais en introduction, ajouter des politiques de conformités et des contraintes sur un cluster Kubernetes n’était pas trivial.

Sans aller jusqu’à dire que ça devient simple, OPA et Gatekeeper facilitent le travail (plus besoin de développer puis d’héberger soi-même un microservice pour chaque Admission/validation Webhook). Il reste est nécessaire de s’approprier un nouveau langage (rego) pour commencer à faire des choses sympa, mais pour autant, rien qu’avec les templates par défaut, il y a déjà de quoi faire.

Un autre point vraiment intéressant avec OPA, c’est la possibilité de loguer et d’auditer toutes les erreurs de conformités avec le mode dryrun à la place du deny, sans bloquer.

kubectl get K8sUniqueIngressHost.constraints.gatekeeper.sh unique-ingress-host -o yaml
[...]
- enforcementAction: dryrun
kind: Ingress
message: ingress host conflicts with an existing ingress <example-host.example.org>
name: ingress-host2
namespace: default

Politique on Zwindler's Reflection

Réforme des retraites - lettre ouverte à Bérangère Couillard

Note d’introduction

Lettre ouverte

Notes

Note finale

Vos politiques de conformité sur Kubernetes avec Kyverno - part 2

Récap’ de la partie 1

Aller un peu plus loin

User experience

Kyverno policy reporter

Policy Reporter UI

Slack

Et si on faisait une violation de politique, pour voir ?

Ressources complémentaires

Vos politiques de conformité sur Kubernetes avec Kyverno

Introduction

Prérequis

Déploiement

Qu’est-ce qu’on a déployé ?

Exemple des Ingress avec la même URL

“La loi, c’est moi”

Conclusion

Ressources complémentaires

Vos politiques de conformité sur Kubernetes avec OPA et Gatekeeper

Introduction

Open Policy Agent / Gatekeeper

Prérequis

Installation

Ya quoi dans mon cluster ?

Validating Webhook

Custom Resource Definition

Config

ConstraintTemplate

Votre premier template

Et une Constraint

Et enfin, on essaye

Conclusion

Sources