|
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. |
Création d’une nouvelle stratégie Rego pour Gatekeeper
Pour ce tutoriel, vous allez mettre en œuvre la même stratégie que vous avez écrite avec Open Policy Agent.
À savoir, une stratégie qui rejette une ressource si elle cible l’espace de noms default.
|
Il existe un modèle de dépôt que vous pouvez utiliser comme base pour porter une stratégie existante. |
La stratégie
Les stratégies de Gatekeeper doivent retourner aucun ou plusieurs objets de violation. Si aucune violation n’est signalée, la demande est acceptée. Si une ou plusieurs violations sont signalées, la demande est rejetée.
Créez un nouveau répertoire, nommé rego-policy.
À l’intérieur, créez un fichier policy.rego avec le contenu suivant :
package policy
violation[{"msg": msg}] {
input.review.object.metadata.namespace == "default"
msg := "it is forbidden to use the default namespace"
}
Dans ce cas, le point d’entrée est policy/violation, et en raison du fonctionnement de Rego, la stratégie peut avoir les résultats suivants :
-
Retourner 1 violation : l’objet examiné cible l’espace de noms par défaut.
-
Retourner 0 violations : l’objet examiné est conforme à la stratégie.
Prenez un moment pour comparer cette stratégie avec celle écrite dans la section Open Policy Agent.
Celle-ci devait construire l’ensemble de la réponse AdmissionReview, et les entrées étaient légèrement différentes.
Dans le mode Gatekeeper, l’objet AdmissionRequest est fourni avec l’attribut input.review.
Tous les attributs de AdmissionRequest sont lisibles avec object.
Maintenant, vous pouvez créer les requêtes à évaluer dans la section suivante.
Vous devez d’abord créer un fichier default-ns.json avec le contenu suivant dans le répertoire data :
{
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"request": {
"uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
"operation": "CREATE",
"object": {
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "nginx",
"namespace": "default",
"uid": "04dc7a5e-e1f1-4e34-8d65-2c9337a43e64"
}
}
}
}
Maintenant, créez un autre objet AdmissionReview qui, cette fois, cible un espace de noms différent de celui de default.
Nommez ce fichier other-ns.json.
Il a le contenu suivant :
{
"apiVersion": "admission.k8s.io/v1",
"kind": "AdmissionReview",
"request": {
"uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
"operation": "CREATE",
"object": {
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "nginx",
"namespace": "other",
"uid": "04dc7a5e-e1f1-4e34-8d65-2c9337a43e64"
}
}
}
}
Vous pouvez voir que cela simule une autre demande de création de pod, cette fois sous un espace de noms appelé other.