|
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. |
Distribuer une stratégie OPA avec SUSE Security Admission Controller
Vous avez écrit, construit et exécuté votre stratégie Rego. Il est maintenant temps de distribuer la stratégie.
Les stratégies doivent être annotées, afin qu’elles puissent s’exécuter dans le policy-server.
La policy-server est la partie qui exécute les stratégies, lorsqu’elle s’exécute dans un cluster Kubernetes.
Annoter la stratégie
Annoter une stratégie est un processus qui enrichit les métadonnées de la stratégie avec des informations pertinentes. Des informations telles que l’auteur, la licence, l’emplacement du code source, les règles, qui décrivent quels types de ressources cette stratégie comprend et évalue.
Pour annoter votre stratégie, vous devez écrire un fichier metadata.yaml :
rules:
- apiGroups: [""]
apiVersions: ["*"]
resources: ["*"]
operations: ["CREATE"]
mutating: false
contextAware: false
executionMode: opa
annotations:
io.kubewarden.policy.title: no-default-namespace
io.kubewarden.policy.version: 0.1.0 # should match the OCI tag
io.kubewarden.policy.description: This policy will reject any resource created inside the default namespace
io.kubewarden.policy.author: The SUSE Security Admission Controller Authors
io.kubewarden.policy.url: https://github.com/kubewarden/some-policy
io.kubewarden.policy.source: https://github.com/kubewarden/some-policy
io.kubewarden.policy.license: Apache-2.0
io.kubewarden.policy.usage: |
This policy is just an example.
You can write interesting descriptions about the policy here.
Vous pouvez voir plusieurs détails :
-
Règles: Quelles ressources cette stratégie cible.
-
Mutante : Si cette stratégie est mutante. Dans ce cas, elle se contente de valider.
-
Consciente du contexte : Si cette stratégie nécessite un contexte du cluster pour évaluer la demande.
-
Mode d’exécution : Puisqu’il s’agit d’une stratégie Rego, il est obligatoire de spécifier quel mode d’exécution elle attend,
opaougatekeeper. Cette stratégie est écrite dans le styleopa, retournant un objetAdmissionReviewcomplet. -
Annotations : Métadonnées stockées dans la stratégie elle-même.
Allez-y et annotez votre stratégie :
$ kwctl annotate policy.wasm --metadata-path metadata.yaml --output-path annotated-policy.wasm
Vous pouvez maintenant inspecter la stratégie en exécutant kwctl inspect annotated-policy.wasm.
Pousser la stratégie
Maintenant que la stratégie est annotée, vous pouvez la pousser vers un registre OCI.
$ kwctl push annotated-policy.wasm registry.my-company.com/kubewarden/no-default-namespace:v0.0.1
Policy successfully pushed
Votre stratégie Rego, ciblant le cadre OPA,
a tout ce dont elle a besoin pour être déployée en production,
en créant un ClusterAdmissionPolicy.
Vous pouvez également préparer cela.
Tout d’abord, vous devez tirer la stratégie dans le magasin local kwctl :
$ kwctl pull registry://registry.my-company.com/kubewarden/no-default-namespace:v0.0.1
pulling policy...
Créez un ClusterAdmissionPolicy à partir de cela.
Cette opération prend en compte les métadonnées qu’elle a sur la stratégie :
$ kwctl manifest registry://registry.my-company.com/kubewarden/no-default-namespace:v0.0.1 --type ClusterAdmissionPolicy
---
apiVersion: policies.kubewarden.io/v1alpha2
kind: ClusterAdmissionPolicy
metadata:
name: generated-policy
spec:
module: "registry://registry.my-company.com/kubewarden/no-default-namespace:v0.0.1"
settings: {}
rules:
- apiGroups:
- ""
apiVersions:
- "*"
resources:
- "*"
operations:
- CREATE
mutating: false
Vous pouvez maintenant utiliser ce ClusterAdmissionPolicy comme base pour cibler les ressources que vous souhaitez,
ou déployer sur Kubernetes tel quel.