Résumé

  • Une ValidatingAdmissionPolicyBinding rattache une politique à une portée, à des paramètres éventuels et à des actions déclarées; elle ne constitue pas le procès-verbal d’une requête.
  • La documentation Kubernetes distingue le rapprochement des critères, l’état des paramètres, l’évaluation, le traitement des erreurs et la réponse à la requête.
  • Une gouvernance vérifiable conserve donc la configuration et le résultat observé dans deux enregistrements attribuables.

Une liaison de politique d’admission semble, à première vue, donner une réponse simple. Son nom désigne une politique; son champ d’application sélectionne des ressources; ses actions annoncent Deny, Warn ou Audit. Cette lisibilité est précieuse, mais elle produit une tentation : prendre une déclaration de comportement futur pour la preuve qu’un comportement s’est produit. Le raccourci efface la requête, l’instant, les critères satisfaits, l’état des paramètres et la réponse effective.

La référence d’API Kubernetes décrit une liaison comme le raccord d’une ValidatingAdmissionPolicy à des ressources paramétrées. Elle précise que les matchResources de la liaison sont croisés avec les matchConstraints de la politique. Une requête doit donc déjà correspondre aux contraintes de la politique avant que la liaison ne puisse en préciser la sélection. Cette architecture explique ce qui pourrait être évalué. Elle ne dit pas qu’une ressource concrète a franchi cette intersection. Il peut n’y avoir eu aucune requête pertinente; une requête peut ne pas correspondre; une autre étape peut avoir déterminé la réponse finale.

Les paramètres rendent la frontière encore plus nette. Une liaison peut viser une ressource de paramétrage, mais Kubernetes distingue la référence présente de la référence absente. Une référence manquante peut rendre la liaison mal configurée et faire intervenir la politique de défaillance. Cela ne livre pas à lui seul un résultat d’admission. La politique, la liaison, la ressource de paramètre et le réglage de défaillance forment des objets et des constatations séparés. Les inventorier est utile; les confondre avec un refus ou une autorisation ne l’est pas.

Il faut également refuser de confondre une expression qui vaut faux avec une défaillance d’évaluation. Kubernetes réserve failurePolicy aux erreurs d’analyse, de typage, d’exécution ou de configuration. Le traitement d’une validation fausse relève des validationActions de la liaison. Deny peut conduire au refus de la requête; Warn renvoie un avertissement au client; Audit ajoute l’information de défaillance à l’événement d’audit. Ces mots décrivent des étapes différentes : résultat d’expression, règle de défaillance, action configurée et effet sur une requête. Une phrase telle que « la politique a bloqué le déploiement » n’est justifiée par aucune de ces étapes prise isolément.

La position de l’admission dans le parcours est tout aussi importante. Kubernetes la place après l’authentification et l’autorisation, mais avant la persistance. Les phases de mutation et de validation sont distinctes; un rejet dans l’une ou l’autre met fin à la requête. Une liaison n’indique pourtant ni l’identité qui a présenté la requête, ni l’autorisation qui l’a précédée, ni une mutation éventuelle, ni l’intervention d’un autre contrôleur. Elle ne s’applique pas aux lectures, qui contournent l’admission. Déclarer une liaison ne revient donc pas à décrire tout ce que le cluster accepte, transforme ou conserve.

La bonne conclusion n’est pas de dévaloriser la liaison, mais de lui laisser sa force propre. Un enregistrement de configuration peut conserver le nom, la version observée, les sélecteurs, la référence de paramètre, les actions et la date de collecte. Un enregistrement de résultat doit, lui, joindre une requête identifiable, le moment, le chemin de correspondance, l’état du paramètre, l’expression, l’action et la réponse. Kubernetes documente pour Audit une annotation liée à une requête, qui identifie la politique, la liaison, l’expression échouée et les actions. Cette annotation soutient une affirmation plus étroite, mais plus solide : elle parle d’une requête particulière, non de toutes les requêtes futures ou passées.

Une phrase disciplinée peut donc dire qu’une liaison déclarait Deny pour une portée observée. Elle ne peut pas dire sans autre preuve qu’une charge a été refusée, qu’aucune charge n’a été créée, ou qu’un objectif de sécurité a été atteint. Les trois conclusions demandent respectivement une trace de réponse, une preuve du résultat complet de la requête et une appréciation beaucoup plus large de la couverture et des exceptions. Conserver ces différences protège la mémoire opérationnelle au lieu de transformer une configuration claire en certitude fictive.

Sources

  1. Référence API Kubernetes — ValidatingAdmissionPolicyBinding
  2. Référence API Kubernetes — ValidatingAdmissionPolicy
  3. Tutoriel Kubernetes — Politiques d’admission
  4. Documentation Kubernetes — Contrôleurs d’admission
  5. Documentation Kubernetes — Annotations d’audit