Contrôleur d'entrée Citrix ADC

Prise en charge des webhooks du contrôleur d’admission

Lescontrôleurs d’admission sont de puissants outils permettant d’intercepter les demandes adressées au serveur d’API Kubernetes avant la persistance de l’objet. À l’aide des contrôleurs d’admission Kubernetes, vous pouvez définir et personnaliser ce qui est autorisé à s’exécuter sur votre cluster. Il s’agit donc d’outils utiles aux administrateurs de cluster pour déployer des contrôles de sécurité préventifs sur votre cluster. Mais vous devez compiler les contrôleurs d’admission dans le kube-apiserver binaire et ils offrent une flexibilité limitée.

Pour surmonter cette limite, Kubernetes prend en charge les contrôleurs d’admission dynamiques qui peuvent être développés en tant qu’extensions et exécutés en tant que webhooks configurés lors de l’exécution.

À l’aide des webhooks du contrôleur d’admission, les administrateurs de cluster Kubernetes peuvent créer des plug-ins supplémentaires pour la chaîne d’admission du serveur API sans les recompiler. Les webhooks du contrôleur d’admission peuvent être exécutés chaque fois qu’une ressource est créée, mise à jour ou supprimée.

Vous pouvez définir deux types de webhooks du contrôleur d’admission :

  • webhook d’admission validant
  • webhook d’admission mutant

Les webhooks d’admission mutants sont invoqués en premier, et ils peuvent modifier les objets envoyés au serveur d’API pour appliquer des valeurs par défaut personnalisées. Une fois que toutes les modifications de l’objet sont terminées et que l’objet entrant est validé par le serveur API, les webhooks d’admission de validation sont invoqués. La validation des hooks d’admission traite les demandes et accepte ou rejette les demandes pour appliquer des politiques personnalisées.

Le schéma suivant explique le fonctionnement du webhook du contrôleur d’admission :

admission-control-webhook

Voici quelques scénarios dans lesquels les webhooks d’admission sont utiles :

  • Pour imposer une base de sécurité raisonnable sur l’ensemble d’un espace de noms ou d’un cluster mandataire. Par exemple, interdire l’exécution de conteneurs en tant que root ou s’assurer que le système de fichiers racine du conteneur est toujours monté en lecture seule.
  • Pour appliquer le respect de certaines normes et pratiques relatives aux étiquettes, aux annotations ou aux limites de ressources. Par exemple, appliquez la validation des étiquettes sur différents objets afin de garantir que les étiquettes appropriées sont utilisées pour divers objets.

  • Pour valider la configuration des objets en cours d’exécution dans le cluster et empêcher toute erreur de configuration évidente d’atteindre votre cluster. Par exemple, pour détecter et corriger les images déployées sans balises sémantiques.

Comment appliquer les contrôleurs d’admission

L’écriture d’un contrôleur d’admission pour chaque cas d’utilisation spécifique n’est pas évolutive et il est utile de disposer d’un système qui prend en charge plusieurs configurations couvrant différents types de ressources et champs. Vous pouvez utiliser Open Policy Agent (OPA) et Gatekeeper pour implémenter un webhook d’admission personnalisable pour Kubernetes.

OPA est un moteur de politique à usage général open source qui unifie l’application des politiques à travers la pile. Gatekeeper est un webhook de validation personnalisable qui applique les politiques basées sur CRD exécutées par OPA.

Gatekeeper( créditd’image)

Gatekeeper introduit les fonctionnalités suivantes

  • Une bibliothèque de politiques extensible et paramétrée
  • CRD Kubernetes natifs pour instancier la bibliothèque de stratégies (contraintes)
  • CRD Kubernetes natifs pour étendre la bibliothèque de stratégies (modèles de contraintes)
  • Fonctionnalité d’audit

Rédaction et déploiement d’un webhook de contrôleur d’admission

Conditions préalables

  • Kubernetes 1.14.0 ou version ultérieure avec l’API admissionregistration.k8s.io/v1beta1 activée.
    Vous pouvez vérifier si l’API est activée à l’aide de la commande suivante :

     kubectl api-versions | grep admissionregistration.k8s.io/v1beta1
    

    La sortie suivante indique que l’API est activée :

     admissionregistration.k8s.io/v1beta1
    
  • Le webhook d”admission mutant et les contrôleurs d”admission du webhook d”admission de validation d”admission doivent être ajoutés et répertoriés dans le bon ordre dans l”indicateur de contrôle d”admission de kube-apiserver.

Avec Minikube, vous pouvez effectuer cette tâche en démarrant Minikube avec la commande suivante :

    minikube start --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook`
  • Vérifiez que vous disposez des autorisations d’administrateur de cluster.

     kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user <YOUR USER NAME>
    

Configuration du webhook d’admission mutant

Pour plus d’informations sur la modification de la configuration du webhook d’admission, consultez la section webhook d’admission d’entrée.

Les cas d’utilisation suivants sont abordés dans l’exemple de webhook d’admission mutant :

  • Mettre à jour le port dans une entrée en fonction du nom d’entrée
  • Activer le back-end sécurisé en fonction d’un espace de noms

Validation de la configuration du webhook d’admission en utilisant Gatekeeper

Gatekeeper utilise un CRD qui vous permet de créer des contraintes en tant que ressources Kubernetes. Ce CRD est appelé ConstraintTemplate Gatekeeper. Le schéma de la contrainte permet à un administrateur d’affiner le comportement d’une contrainte, comme pour les arguments d’une fonction. Les contraintes sont utilisées pour informer Gatekeeper que l’administrateur souhaite qu’un modèle de contrainte soit appliqué, et comment.

Vous pouvez appliquer différentes stratégies à l’aide de modèles de contraintes. Différents exemples sont répertoriés dans la bibliothèque Gatekeeper.

Déploiement d’un exemple de stratégie

Effectuez les étapes suivantes pour déployer en HttpsOnly tant qu’exemple de stratégie à l’aide de Gatekeeper. La HttpsOnly stratégie autorise uniquement une configuration d’entrée avec HTTPS.

  1. Installez Gatekeeper à l’aide de la commande suivante.

    Remarque :

    Au cours de cette étape, Gatekeeper est installé à l’aide d’une image prédéfinie. Vous pouvez installer Gatekeeper à l’aide des différentes méthodes mentionnées dans l’installation de Gatekeeper.

    # kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
    

    Vous pouvez vérifier l’installation à l’aide de la commande suivante.

    kubectl get crd | grep -i constraintsonstrainttemplates.templates.gatekeeper.sh  
    

    Vous pouvez vérifier tous les modèles de contraintes à l’aide de la commande suivante :

     kubectl get constrainttemplates.templates.gatekeeper.sh
    
  2. Appliquez le modèle de httpsonly contrainte.

     kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/template.yaml
    
  3. Appliquez une contrainte pour appliquer la httpsonly stratégie.

     kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/constraint.yaml
    
  4. Déployez un exemple d’entrée qui enfreint la stratégie pour vérifier la stratégie. Il devrait afficher une erreur lors de la création de l’entrée.

    kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/bad-example-ingress.yaml
    
    Error from server ([denied by ingress-https-only] Ingress must be https. tls configuration is required for test-ingress): error when creating "ingress.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by ingress-https-only] Ingress must be https. tls configuration is required for test-ingress
    
  5. Maintenant, déployez une entrée qui possède la section TLS requise dans Ingress.

     # kubectl apply -f  https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/good-example-ingress.yaml
           
     ingress.networking.k8s.io/test-ingress created
    
  6. Nettoyez l’installation à l’aide des commandes suivantes une fois que vous avez terminé la vérification des stratégies de Gatekeeper.

    Uninstall all packages and template installed.
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/good-example-ingress.yaml
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/constraint.yaml
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/template.yaml
    kubectl delete -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
    

Plus d’exemples de cas d’utilisation

Plusieurs cas d’utilisation sont répertoriés dans le répertoire webhook. Les étapes sont similaires à celles spécifiées dans l’exemple et peuvent être résumées comme suit :

  1. Appliquez le modèle de fichier YAML indiqué dans chaque répertoire de cas d’utilisation.
  2. Appliquez le fichier YAML de contraintes.
  3. Vérifiez en appliquant des exemples de fichiers YAML mauvais ou bon pour valider le cas d’utilisation.

Pour d’autres cas d’utilisation, consultez la bibliothèque Gatekeeper.

Prise en charge des webhooks du contrôleur d’admission