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.

Stratégies conscientes du contexte

Les développeurs peuvent créer des stratégies qui récupèrent des informations d’un cluster Kubernetes à l’exécution. Ce sont des stratégies conscientes du contexte. Les stratégies conscientes du contexte peuvent déterminer si un AdmissionRequest est acceptable en utilisant des informations provenant des ressources déployées dans le cluster.

Les stratégies conscientes du contexte ne sont disponibles que dans les versions SUSE Security Admission Controller ≥ v1.6.0.

Le contrôle des ressources auxquelles une stratégie peut accéder dans le cluster est assuré par le Compte de service du serveur de stratégie. Un administrateur de cluster contrôle ce à quoi une stratégie peut accéder via les règles RBAC de Kubernetes. Les stratégies conscientes du contexte n’ont qu’un accès lecture aux ressources demandées.

Pour des raisons de sécurité, seules les stratégies ClusterAdmissionPolicy peuvent récupérer des informations du cluster Kubernetes. C’est parce que les utilisateurs non privilégiés peuvent déployer des ressources AdmissionPolicy.

Si un utilisateur non privilégié déploie une stratégie consciente du contexte en tant que AdmissionPolicy, le système :

  • Bloque toutes les tentatives d’accès aux ressources Kubernetes.

  • Les signale à l’administrateur de cluster.

Par défaut, Admission Controller bloque toutes les ressources du cluster. Un administrateur SUSE Security Admission Controller définit quelles ressources Kubernetes chaque stratégie consciente du contexte peut lire. contextAwareResources pour ce faire.

L’exemple suivant déploie une stratégie qui nécessite un accès aux ressources Deployment et Pod :

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: context-aware-policy
  namespace: default
spec:
  policyServer: default
  module: "registry://ghcr.io/kubewarden/policies/context-aware-policy:v1.0.0"
  settings: {}
  contextAwareResources:
    - apiVersion: "apps/v1"
      kind: "deployment"
    - apiVersion: "v1"
      kind: "pod"
  rules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      resources: ["deployment"]
      operations:
        - CREATE
        - UPDATE
  mutating: false

Une fois déployée, cette stratégie peut lire les données des ressources deployment et pod.

Les auteurs de stratégies fournissent des listes de ressources Kubernetes pour leur stratégie consciente du contexte. Les auteurs de stratégies le font en annotant la stratégie. Les administrateurs SUSE Security Admission Controller consultent les métadonnées de la stratégie en utilisant la commande kwctl inspect. Ils peuvent obtenir une liste des ressources auxquelles la stratégie doit avoir accès. Un administrateur utilise cette liste pour remplir la définition ClusterAdmissionPolicy.

Pour prévenir les abus du système, les administrateurs SUSE Security Admission Controller doivent examiner les ressources auxquelles la stratégie accède.

Par exemple, une stratégie évaluant les objets d’ingress aurait de bonnes raisons de lire les ressources Ingress définies dans le cluster. La même stratégie ne peut pas justifier d’avoir accès aux ressources Secret.

Les stratégies devraient avoir le minimum d’accès nécessaire pour fonctionner correctement.

L’identification des ressources Kubernetes utilise apiVersion et kind.

En général, apiVersion est une chaîne au format <api>/<version>. Les ressources du groupe d’API core (Pod, Service, et autres) ne devraient pas définir le nom du groupe, <api>. Elles devraient seulement définir le <version> (par exemple, v1).

Pour une ressource noyau, le premier ne fonctionnera pas, le second fonctionnera.

- apiVersion: "core/v1"
  kind: "pod"
- apiVersion: "v1"
  kind: "pod"

Toutes les autres ressources Kubernetes ont besoin de la définition complète : <api>/<version>.

Lectures supplémentaires

Vous pouvez trouver des informations plus détaillées sur les stratégies conscientes du contexte dans cette section de la documentation de référence.