|
Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi. |
|
Il s'agit d'une documentation non publiée pour Admission Controller 1.34-dev. |
Rego
|
Le support de Rego est disponible à partir de ces versions :
Les stratégies Rego prennent en charge des données contextuelles à partir de la version SUSE Security Admission Controller 1.9. |
Le langage Rego est un langage spécifique à un domaine permettant de mettre en œuvre des stratégies sous forme de code. Rego est un langage inspiré par Datalog.
Il existe deux manières de rédiger des stratégies Rego pour mettre en œuvre des stratégies sous forme de code dans Kubernetes, Open Policy Agent et Gatekeeper.
Les deux sections suivantes montrent comment les deux frameworks diffèrent, même s’ils utilisent le même langage. Si vous êtes plus intéressé par l’implémentation Admission Controller, vous pouvez directement consulter la documentation spécifique au framework liée ci-dessous.
Un langage, deux frameworks
Open Policy Agent (OPA)
Open Policy Agent est un projet qui vous permet de mettre en œuvre des stratégies sous forme de code dans n’importe quel projet. Vous pouvez utiliser OPA pour toute vérification basée sur des stratégies dont votre application a besoin.
Dans ce contexte, rédiger des stratégies pour Kubernetes revient simplement à utiliser OPA. En utilisant les webhooks d’admission de Kubernetes, il est possible d’évaluer les demandes en utilisant OPA, qui exécute les stratégies écrites en Rego.
OPA a une intégration optionnelle avec Kubernetes via son kube-mgmt sidecar.
Lorsqu’il est déployé sur Kubernetes, et avec le serveur OPA évaluant les stratégies Rego,
il est capable de répliquer les ressources Kubernetes configurées en Rego.
Ainsi, ces ressources Kubernetes sont visibles pour toutes les stratégies.
Avec OPA, vous pouvez définir des stratégies à l’intérieur des objets ConfigMap de Kubernetes.
Vous pouvez en lire davantage sur
sa page de projet.
En examinant les différences
Les stratégies OPA et Gatekeeper utilisent toutes deux Rego pour décrire les stratégies sous forme de code. Chaque solution présente des différences en ce qui concerne l’écriture de stratégies en Rego, comme le montrent les sections suivantes.
Point d’entrée
Le point d’entrée est le nom d’une règle au sein d’un paquet, et c’est la règle invoquée par le composant d’exécution lorsque la stratégie s’exécute.
Limitations actuelles
Stratégies sensibles au contexte
Les stratégies sensibles au contexte sont des stratégies qui n’évaluent pas la demande d’entrée de manière isolée.
Elles prennent d’autres facteurs en compte pour prendre une décision.
Par exemple, une stratégie qui évalue des ressources d’espace de noms,
et utilise une annotation,
sur l’espace de noms parent pour configurer quelque chose dans la stratégie.
Un autre exemple serait une stratégie qui évalue des ressources Ingress,
mais pour prendre une décision, elle a également la liste des ressources Ingress existantes.
L’idée des stratégies sensibles au contexte peut également s’étendre aux ressources personnalisées, donc votre stratégie pourrait vouloir évaluer une demande en fonction des ressources personnalisées actuellement utilisées.
Les deux OPA et Gatekeeper prennent en charge les stratégies sensibles au contexte, à partir de la version Admission Controller 1.9.
Plus de détails sur les stratégies sensibles au contexte sont ici.
Stratégies de mutation
Gatekeeper prend en charge les stratégies de mutation, mais Admission Controller n’a pas encore mis en œuvre de stratégies de mutation avec la compatibilité Gatekeeper. Vous pouvez utiliser des stratégies qui utilisent le SDK Admission Controller pour écrire des stratégies de mutation, mais actuellement, vous ne pouvez pas exécuter des stratégies de mutation Gatekeeper dans Admission Controller.