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.

Actions de

La pile SUSE Security Admission Controller se compose de :

  • Une ou plusieurs ressources ClusterAdmissionPolicy : cela définit des stratégies pour les clusters Kubernetes.

  • Une ou plusieurs ressources PolicyServer : représentant un déploiement d’un Admission Controller PolicyServer. Le Admission Controller PolicyServer charge et évalue les stratégies de votre administrateur.

  • Une ou plusieurs ressources AdmissionPolicy : politiques pour un espace de noms défini.

  • Un déploiement d’un kubewarden-controller : ce contrôleur surveille les ressources ClusterAdmissionPolicy et interagit avec les composants Admission Controller PolicyServer.

Admission Controller décrit ses définitions de ressources personnalisées Kubernetes (CRDs) ici.

Les CRDs Admission Controller mentionnées dans ce tutoriel et dans le reste de la documentation ont des noms courts, qui sont plus faciles à utiliser. Voici les noms courts pour les CRDs :

Ressource shortName

AdmissionPolicies

ap

ClusterAdmissionPolicies

cap

AdmissionPolicyGroups

apg

ClusterAdmissionPolicyGroups

capg

PolicyServers

ps

Installation

Authentification

Vous pouvez récupérer les stratégies Admission Controller depuis le registre de conteneurs GitHub à https://ghcr.io.. Vous avez besoin d’une authentification pour utiliser le dépôt avec la CLI Admission Controller, un token d’accès personnel GitHub (PAT). Leur documentation vous guide pour en créer un si vous ne l’avez pas déjà fait. Ensuite, vous vous authentifiez avec une commande comme :

echo $PAT | docker login ghcr.io --username <my-gh-username> --password-stdin

Déployez la pile Admission Controller en utilisant les charts helm comme suit :

helm repo add kubewarden https://charts.kubewarden.io
helm repo update kubewarden

Installez les charts Helm suivants dans l’espace de noms kubewarden de votre cluster Kubernetes :

  • kubewarden-crds, qui enregistre les définitions de ressources personnalisées ClusterAdmissionPolicy, AdmissionPolicy et PolicyServer. De plus, les définitions de ressources personnalisées {report} utilisées par le scanner d’audit.

  • kubewarden-controller, qui installe le contrôleur Admission Controller et le scanner d’audit.

    Si vous devez désactiver le composant du scanner d’audit, consultez la page de documentation d’installation du scanner d’audit documentation page.

  • kubewarden-defaults, qui crée une ressource PolicyServer nommée default. Il peut également installer un ensemble de politiques recommandées pour sécuriser votre cluster en appliquant des meilleures pratiques bien connues.

helm install --wait -n kubewarden --create-namespace kubewarden-crds kubewarden/kubewarden-crds
helm install --wait -n kubewarden kubewarden-controller kubewarden/kubewarden-controller
helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults

Puisque v0.4.0, une ressource PolicyServer nommée default n’est pas créée en utilisant le chart kubewarden-controller. Maintenant, un chart Helm appelé kubewarden-defaults installe le serveur de stratégie par défaut.

Cela signifie que si vous n’utilisez pas la dernière version de kubewarden-controller lors de la mise à niveau ou de la suppression, votre serveur de stratégie par défaut n’est pas mis à niveau ou supprimé. Ainsi, vous pourriez rencontrer des problèmes si vous essayez d’installer le kubewarden-defaults avec des informations conflictuelles, par exemple, le même nom de serveur de stratégie. Pour installer les futures mises à niveau du chart Helm kubewarden-defaults, supprimez la ressource PolicyServer existante créée par le kubewarden-controller avant d’installer le nouveau chart. Maintenant, vous pouvez mettre à jour votre serveur de stratégie en utilisant les mises à niveau Helm sans conflits de ressources. Lorsque vous supprimez le PolicyServer, vous supprimez également toutes les stratégies qui y sont liées.

Les valeurs de configuration par défaut sont suffisantes pour la plupart des déploiements. Le documentation décrit toutes les options.

Composants principaux

Admission Controller a trois composants principaux avec lesquels vous interagissez :

PolicyServer

Le kubewarden-controller gère un Admission Controller PolicyServer. Vous pouvez déployer plusieurs PolicyServer dans le même cluster Kubernetes.

Un PolicyServer valide les requêtes entrantes en exécutant des stratégies Admission Controller contre elles.

Il s’agit de la configuration PolicyServer par défaut :

apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
  name: reserved-instance-for-tenant-a
spec:
  image: ghcr.io/kubewarden/policy-server:v1.3.0
  replicas: 2
  serviceAccountName: ~
  env:
    - name: KUBEWARDEN_LOG_LEVEL
      value: debug

Vérifiez le dernière version PolicyServer publiée et changez le tag pour qu’il corresponde.

Aperçu des attributs de la ressource PolicyServer :

Requis Espace réservé Description

Y

image

Le nom de l’image du conteneur

Y

replicas

Le nombre d’instances souhaitées

N

serviceAccountName

Le nom du ServiceAccount à utiliser pour le déploiement PolicyServer. S’il n’y a pas de valeur fournie, le ServiceAccount par défaut de l’espace de noms d’installation, de kubewarden-controller, est utilisé.

N

env

La liste des variables d’environnement

N

annotations

La liste des annotations

Modifier l’un de ces attributs entraîne un déploiement PolicyServer avec la nouvelle configuration.

ClusterAdmissionPolicy

La ressource ClusterAdmissionPolicy est le cœur de la pile Admission Controller. Elle définit comment les stratégies évaluent les requêtes.

L’application des stratégies est l’opération la plus courante qu’un administrateur Kubernetes effectue. Vous pouvez déclarer autant de stratégies que vous le souhaitez, chacune ciblant une ou plusieurs ressources Kubernetes (c’est-à-dire, pods, Custom Resource et d’autres). Vous spécifiez également le type d’opérations appliquées aux ressources ciblées. Les opérations disponibles sont CREATE, UPDATE, DELETE et CONNECT.

Configuration par défaut de ClusterAdmissionPolicy :

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities
spec:
  policyServer: reserved-instance-for-tenant-a
  module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.9
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  settings:
    allowed_capabilities:
      - CHOWN
    required_drop_capabilities:
      - NET_ADMIN

Aperçu des attributs de la ressource ClusterAdmissionPolicy :

Requis Espace réservé Description

N

policy-server

Identifie un objet PolicyServer existant. Seule cette instance PolicyServer sert la stratégie. Le serveur de stratégie nommé default sert un ClusterAdmissionPolicy sans PolicyServer explicite.

Y

module

L’emplacement de la stratégie Admission Controller. Les schémas suivants sont autorisés :

N

- registry: Téléchargement de la stratégie depuis un registre de conteneurs conforme à OCI artifacts. Exemple : registry://<OCI registry/policy URL>

N

- http, https: Téléchargement de la stratégie depuis un serveur HTTP(s) régulier. Exemple : https://<website/policy URL>

N

- file: Chargez la stratégie à partir d’un fichier dans le système de fichiers de l’ordinateur. Exemple : file:///<policy WASM binary full path>

Y

resources

Les ressources Kubernetes évaluées par la stratégie

Y

operations

Quelles opérations pour les types précédemment donnés doivent être transmises à cette stratégie d’admission par le serveur API pour évaluation.

Y

mutating

Définissez cette valeur booléenne true pour les stratégies qui peuvent modifier les requêtes entrantes

N

settings

Un objet libre qui contient les valeurs de configuration de la stratégie.

N

failurePolicy

L’action à entreprendre si la demande évaluée par une stratégie entraîne une erreur. Les options suivantes sont autorisées :

N

- Ignore : ignorer une erreur lors de l’appel du webhook et la demande API continue.

N

- Fail : une erreur lors de l’appel du webhook entraîne l’échec de l’admission et le rejet de la demande API.

Le contrôleur enregistre le webhook des ressources ClusterAdmissionPolicy * scope. Cela signifie que les webhooks enregistrés transmettent toutes les demandes correspondant aux ressources resources et operations, qu’elles soient dans un espace de noms ou à l’échelle du cluster.

AdmissionPolicy

AdmissionPolicy est une ressource à l’échelle de l’espace de noms. La stratégie ne traite que les demandes visant l’espace de noms avec le AdmissionPolicy défini. À part cela, il n’y a pas de différences fonctionnelles entre les ressources AdmissionPolicy et ClusterAdmissionPolicy.

AdmissionPolicy nécessite Kubernetes 1.21.0 ou une version ultérieure. C’est parce que Admission Controller utilise l’étiquette kubernetes.io/metadata.name, introduite dans Kubernetes 1.21.0.

La documentation complète de ces ressources personnalisées est ici ou sur docs.crds.dev.

Exemple : Appliquez votre première stratégie

Nous allons utiliser la stratégie pod-privileged. Nous voulons empêcher la création de conteneurs privilégiés dans notre cluster Kubernetes en appliquant cette stratégie.

Définissons un ClusterAdmissionPolicy pour cela :

kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: privileged-pods
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.2
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
EOF

Cela produit la sortie suivante :

clusteradmissionpolicy.policies.kubewarden.io/privileged-pods created

Après l’instanciation d’un ClusterAdmissionPolicy, le statut devient pending, et cela force un déploiement du PolicyServer ciblé. Dans l’exemple, c’est le PolicyServer nommé default. Vous pouvez surveiller le déploiement en exécutant la commande suivante :

kubectl get clusteradmissionpolicy.policies.kubewarden.io/privileged-pods

Vous devriez voir la sortie suivante :

NAME              POLICY SERVER   MUTATING   STATUS
privileged-pods   default         false      pending

Une fois que la nouvelle stratégie est prête, le kubewarden-controller enregistre un objet ValidatingWebhookConfiguration pour le servir.

Le statut ClusterAdmissionPolicy devient active une fois que le déploiement est terminé pour chaque instance PolicyServer. Affichez les ValidatingWebhookConfiguration avec la commande suivante :

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l kubewarden

Vous devriez voir la sortie suivante :

NAME                          WEBHOOKS   AGE
clusterwide-privileged-pods   1          9s

Une fois que le ClusterAdmissionPolicy est actif et que le ValidatingWebhookConfiguration s’enregistre, vous pouvez tester la stratégie.

Tout d’abord, vous pouvez créer un Pod avec un Conteneur non en mode privileged :

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
EOF

Cela produit la sortie suivante :

pod/unprivileged-pod created

Le Pod est créé avec succès.

Maintenant, vous pouvez créer un Pod avec au moins un Conteneur privileged flag :

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      securityContext:
          privileged: true
EOF

La stratégie refuse la création du Pod et vous devriez voir le message suivant :

Error from server: error when creating "STDIN": admission webhook "clusterwide-privileged-pods.kubewarden.admission" denied the request: Privileged container is not allowed

Les deux exemples n’ont pas défini de namespace, ce qui signifie que l’espace de noms default était la cible. Cependant, comme vous avez pu le voir dans le deuxième exemple, la stratégie est toujours appliquée. Comme indiqué précédemment, cela est dû au fait que le champ d’application est à l’échelle du cluster et ne cible pas un espace de noms spécifique.

Uninstall

Vous pouvez supprimer les ressources créées en désinstallant les charts helm comme suit :

helm uninstall --namespace kubewarden kubewarden-defaults
helm uninstall --namespace kubewarden kubewarden-controller
helm uninstall --namespace kubewarden kubewarden-crds

Après la suppression des charts helm, supprimez l’espace de noms Kubernetes utilisé pour déployer la pile Admission Controller :

kubectl delete namespace kubewarden

Admission Controller contient un hook de pré-suppression helm qui supprime tous les PolicyServer et kubewarden-controller. Ensuite, le kubewarden-controller supprime toutes les ressources, il est donc important que kubewarden-controller soit en cours d’exécution lorsque la désinstallation helm s’exécute.

Admission Controller supprime les ValidatingWebhookConfiguration et MutatingWebhookConfiguration. Vérifiez cela avec :

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io -l "kubewarden"

Si ces ressources ne sont pas supprimées automatiquement, supprimez-les manuellement en utilisant la commande suivante :

kubectl delete -l "kubewarden" validatingwebhookconfigurations.admissionregistration.k8s.io
kubectl delete -l "kubewarden" mutatingwebhookconfigurations.admissionregistration.k8s.io

En résumé

ClusterAdmissionPolicy est la ressource noyau que doit gérer un opérateur de cluster. Le module kubewarden-controller s’occupe automatiquement de la configuration des autres ressources nécessaires à l’exécution des stratégies.

Opérations suivantes

Vous êtes maintenant prêt à déployer Admission Controller ! Jetez un œil aux stratégies sur artifacthub.io, sur GitHub, ou réutilisez les stratégies Rego existantes comme indiqué dans les chapitres suivants.

Liste complète des stratégies disponibles sur ArtifactHub