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.

Métadonnées de la stratégie

Le fichier de métadonnées SUSE Security Admission Controller, metadata.yaml, est un fichier de configuration contenant des informations et des paramètres importants liés aux stratégies utilisées dans Admission Controller. Cette documentation est un aperçu de l’objectif et de l’utilisation du fichier de métadonnées.

Le fichier de stratégie metadata.yaml a des valeurs par défaut pour la stratégie, ainsi que des métadonnées telles que l’auteur et la description, définies par l’auteur de la stratégie. La commande kwctl annotate utilise le fichier pour annoter le fichier .wasm contenant la stratégie. Par conséquent, toutes les informations pertinentes nécessaires à l’exécution de la stratégie sont disponibles. Plus d’informations sur la façon d’annoter la stratégie se trouvent dans le guide Distribution des stratégies.

Lorsque les utilisateurs de la stratégie souhaitent utiliser une stratégie, ils génèrent un manifeste YAML en utilisant kwctl scaffold. Cette commande lit les métadonnées de la stratégie intégrées dans le module Wasm expédié, effectue des vérifications et renvoie un manifeste YAML que l’auteur peut utiliser tel quel ou modifier.

En tant qu’auteur de stratégie, vous pouvez adapter le fichier metadata.yaml fourni lors de la création de votre stratégie.

Reportez-vous à l’exemple suivant d’un metadata.yaml :

rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations: ["CREATE"]
mutating: false
contextAwareResources: []
executionMode: kubewarden-wapc
policyType: kubernetes
backgroundAudit: true
annotations:
  # kubewarden specific:
  io.kubewarden.policy.title: My policy
  io.kubewarden.policy.version: 0.1.0 # should match the OCI tag
  io.kubewarden.policy.description: Short description
  io.kubewarden.policy.author: myself
  io.kubewarden.policy.url: https://github.com/yourorg/my-policy
  io.kubewarden.policy.source: https://github.com/yourorg/my-policy
  io.kubewarden.policy.license: Apache-2.0
  # The next two annotations are used in the policy report generated by the
  # Audit scanner. Severity indicates policy check result criticality and
  # Category indicates policy category. See more here at docs.kubewarden.io
  io.kubewarden.policy.severity: medium
  io.kubewarden.policy.category: Resource validation
  # artifacthub specific: (optional, to release in Artifact Hub)
  io.kubewarden.policy.ociUrl: ghcr.io/myorg/my-policy
  io.artifacthub.displayName: Policy Name
  io.artifacthub.resources: Pod
  io.artifacthub.keywords: pod, cool policy, kubewarden

Activation des vérifications d’audit en arrière-plan

Le fichier de métadonnées inclut un indicateur, backgroundAudit, qui active les vérifications d’audit en arrière-plan pour une stratégie spécifique. Par défaut, cet indicateur est défini sur true.

Il existe des stratégies qui, en raison de leur fonctionnement ou du type d’événements qui les concernent, devraient avoir ce champ défini sur false. Vous pouvez trouver plus d’informations dans la documentation du scanner d’audit, dans la section des limitations.

Définir les ressources Kubernetes auxquelles les stratégies peuvent accéder

Dans le fichier de métadonnées, en utilisant le champ contextAwareResources, les utilisateurs peuvent définir les ressources Kubernetes auxquelles la stratégie peut accéder. Par exemple, si la stratégie a besoin d’accéder à la ressource Namespace. L’auteur de la stratégie peut définir le contextAwareResources comme suit :

[...]
contextAwareResources:
  - apiVersion: v1 kind: Namespace
[...]

Spécifier les stratégies comme mutantes ou non mutantes

Le fichier de métadonnées a un indicateur, mutating, qui permet aux utilisateurs de configurer une stratégie comme mutante ou non mutante. Une stratégie mutante modifie les requêtes entrantes ou les ressources gérées. Une stratégie non mutante observe et impose des restrictions sans apporter de modifications. Cette distinction est cruciale pour déterminer comment les stratégies interagissent avec les ressources Kubernetes et leur impact sur le cluster.

Spécifiez le type de stratégie comme Kubernetes ou brut

Le fichier de métadonnées a un indicateur, policyType, qui permet aux utilisateurs de marquer une stratégie comme kubernetes ou raw. Une stratégie Kubernetes est une stratégie qui valide les ressources Kubernetes. Une stratégie brute est une stratégie qui valide des documents JSON arbitraires. Par défaut, si cela n’est pas spécifié par l’utilisateur, ce champ est défini sur kubernetes lors de l’annotation d’une stratégie. Référez-vous à la section Stratégies brutes pour plus d’informations.

Définir les cibles de type de ressource

Le fichier de métadonnées offre aux utilisateurs la possibilité de définir les règles dans le champ rules, qui détermine les types de ressources auxquels la stratégie s’applique. Cette fonctionnalité permet aux utilisateurs d’exercer un contrôle précis sur l’application de la stratégie, garantissant que les stratégies ne sont appliquées qu’aux types de ressources prévus. Avec ce contrôle granulaire, les utilisateurs peuvent garantir que les stratégies sont ciblées avec précision, en s’alignant sur leurs exigences spécifiques et en évitant toute application non intentionnelle des stratégies à des types de ressources non liés.