Utiliser des contrôleurs d’admission pour renforcer la sécurité de Kubernetes

Si vous utilisez Kubernetes, vous connaissez certainement les fonctions de sécurité de base de Kubernetes, comme RBAC et les politiques réseau. Ces outils sont utiles pour appliquer des règles de base sur les actions qui peuvent être exécutées par divers utilisateurs ou services au sein de votre cluster.

Cependant, il arrive parfois que vous ayez besoin d’une plus grande granularité ou de fonctionnalités supplémentaires en matière de politiques que ce que RBAC ou les politiques réseau prennent en charge. Vous pouvez également avoir besoin d’effectuer des contrôles supplémentaires pour valider une ressource avant de l’autoriser à rejoindre votre cluster.

C’est là que les contrôleurs d’admission Kubernetes entrent en scène. Les contrôleurs d’admission offrent une solution très extensible qui permet d’effectuer des contrôles de sécurité qui vont au-delà des règles d’authentification, d’autorisation et de sécurité réseau que vous appliquez par le biais d’autres types de frameworks de politique Kubernetes. Ils jouent également un rôle central dans la création du lien entre Kubernetes et des outils de sécurité externes qui peuvent offrir des fonctions d’analyse et de conformité encore plus avancées.

Les contrôleurs d’admission sont une fonction facultative dont vous n’aurez peut-être pas besoin pour les configurations simples. Ces dernières peuvent être sécurisées correctement par le biais de politiques RBAC ou de politiques réseau de base. Néanmoins, pour sécuriser des clusters complexes et à grande échelle, les contrôleurs d’admission constituent une ressource inestimable.

Dans cet article, nous verrons ce que sont les contrôleurs d’admission Kubernetes, leur fonctionnement et le processus classique pour les utiliser à des fins de sécurité.

Que sont les contrôleurs d’admission dans Kubernetes ?

Un contrôleur d’admission Kubernetes est un code qui évalue les requêtes adressées au serveur API Kubernetes, puis qui détermine s’il faut ou non autoriser la requête en question.

L’évaluation a lieu après que le serveur API a déjà authentifié et autorisé la requête, mais avant que la requête soit accordée et mise en œuvre.

Plus précisément, même si le serveur API a déterminé qu’une requête était valide (ce qu’il ferait en se basant sur les rôles RBAC et les ClusterRoles que vous avez configurés), les contrôleurs d’admission évaluent la requête et décident de l’accepter ou non en se basant sur leur propre ensemble de règles.

Avantages des contrôleurs d’admission

Les contrôleurs d’admission offrent plusieurs avantages importants dans le cadre d’une stratégie de sécurité Kubernetes :

Ils vérifient à deux reprises les requêtes : les contrôleurs d’admission servent en quelque sorte de deuxième ligne de défense contre les demandes non valides qui ont pu échapper à vos contrôles RBAC (peut-être en raison d’une mauvaise configuration d’une politique RBAC, par exemple).
Souplesse des règles : les contrôleurs d’admission peuvent évaluer les requêtes et appliquer des règles en fonction de paramètres que vous ne pouvez pas configurer (du moins pas facilement) via RBAC. Ce point est important, car RBAC définit des règles basées uniquement sur les identités et les actions. Les contrôleurs d’admission offrent plus de nuances, comme la possibilité de limiter les demandes de ressources ou d’empêcher l’exécution de commandes sur un container privilégié.
Intégrations de systèmes tiers : certains contrôleurs d’admission autorisent les webhooks. Vous pouvez utiliser des webhooks pour déclencher des actions dans des systèmes de sécurité tiers. Cela signifie que les contrôleurs d’admission offrent un moyen d’intégrer des outils de sécurité externes dans Kubernetes sans avoir à exécuter ces outils directement dans l’API Kubernetes. C’est sans doute la fonction la plus puissante des contrôleurs d’admission.

Utilisation des contrôleurs d’admission

Voici la procédure à suivre pour utiliser les contrôleurs d’admission dans Kubernetes.

Activer des contrôleurs d’admission dans le cluster

Pour utiliser des contrôleurs d’admission dans Kubernetes, vous devez d’abord vous assurer que la fonction de contrôleur d’admission est activée dans le fichier kube-apiserver.yaml de votre cluster (qui, dans la plupart des cas, sera stocké dans le répertoire /etc/kubernetes/manifests/ sur votre master ou vos nœuds master Kubernetes).

Si l’indicateur –enable-admission-plugins est présent, cela signifie que les contrôleurs d’admission sont activés pour votre cluster.

Choisir des contrôleurs d’admission spécifiques

L’indicateur –enable-admission-plugins peut être suivi d’une liste séparée par des virgules, comme ceci :

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition
,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection
,PersistentVolumeClaimResize,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,RuntimeClass
,ResourceQuota

Cette liste identifie les contrôleurs d’admission spécifiques qui sont activés pour votre cluster. La documentation Kubernetes détaille tous les contrôleurs d’admission disponibles.

Si l’indicateur –enable-admission-plugins est présent mais n’est pas suivi d’une liste, Kubernetes active un ensemble de contrôleurs d’admission par défaut. Dans les versions actuelles de Kubernetes, il s’agit des suivants :

NamespaceLifecycle
LimitRanger
ServiceAccount
TaintNodesByCondition
Priority
DefaultTolerationSeconds
DefaultStorageClass
StorageObjectInUseProtection
PersistentVolumeClaimResize
RuntimeClass
CertificateApproval
CertificateSigning
CertificateSubjectRestriction
DefaultIngressClass
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
ResourceQuota

Ainsi, vous pouvez soit utiliser les contrôleurs d’admission par défaut, soit définir explicitement les contrôleurs d’admission à activer.

Désactiver des contrôleurs d’admission

Si vous le souhaitez, vous pouvez explicitement désactiver des contrôleurs d’admission en utilisant l’indicateur –disable-admission-plugins=… dans le fichier kube-apiserver.yaml.

Cet indicateur est pratique si vous utilisez l’ensemble de contrôleurs par défaut mais que vous souhaitez désactiver certains contrôleurs de cet ensemble.

Vérifier quels contrôleurs d’admission spécifiques sont actifs

Si vous ne savez pas quels contrôleurs d’admission sont activés dans votre cluster, exécutez cette commande pour en obtenir la liste :

kube-apiserver -h | grep enable-admission-plugins

Configurer des contrôleurs d’admission

Kubernetes appliquera automatiquement les contrôleurs d’admission que vous activerez dans votre cluster. Vous n’avez pas besoin de créer de fichiers de politiques supplémentaires (comme vous le feriez avec RBAC, par exemple).

Cependant, pour certains contrôleurs d’admission, vous pourrez avoir besoin de spécifier des détails au niveau de la configuration. Par exemple, pour utiliser le contrôleur EventRateLimit, qui limite le nombre de requêtes que le serveur d’API peut accepter, vous devez créer un fichier de configuration au format YAML et le faire pointer vers le serveur API à l’aide de l’indicateur –admission-control-config-file.

Le fichier de configuration ressemblera à quelque chose comme ceci :

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
- type: Namespace
  qps: 50
  burst: 100
  cacheSize: 2000
- type: User
  qps: 10
  burst: 50

Dans ce fichier, qps signifie requêtes par seconde, et burst définit le nombre de requêtes que le serveur API acceptera avant d’appliquer la limite établie par la valeur qps. Ainsi, une vitesse qps de 50 avec un burst de 100 signifie que le serveur acceptera jusqu’à 100 requêtes avant de commencer à appliquer la limite de qps de 50. Les limites sont définies pour des types de ressources spécifiques (dans l’exemple ci-dessus, les namespaces et les utilisateurs).

Pour obtenir tous les détails sur la configuration de contrôleurs d’admission spécifiques, consultez la documentation de Kubernetes.

Créer des contrôleurs d’admission personnalisés avec des webhooks

Lorsqu’ils sont correctement configurés, les différents contrôleurs d’admission intégrés peuvent améliorer considérablement de nombreux aspects de la sécurité de votre cluster.

Toutefois, comme indiqué ci-dessus, l’aspect le plus puissant des contrôleurs d’admission est leur capacité à s’intégrer à des outils de sécurité externes via des webhooks.

Par exemple, vous pouvez utiliser le contrôleur ImagePolicyWebhook pour vous connecter à un serveur distant. Pour ce faire, vous devez d’abord vous assurer que ImagePolicyWebhook est activé dans kube-apiserver.yaml.

Ensuite, créez un fichier (que nous appellerons admission-config.yaml) qui comprend les détails de configuration de ImagePolicyWebhook que vous utiliserez pour vous connecter au serveur distant. Dirigez le serveur API vers ce fichier avec :

kube-apiserver --admission-control-config-file=admission-config.yaml

Le fichier admission-config.yaml lui-même doit contenir une stanza qui ressemble à ceci :

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
  configuration:
    imagePolicy:
      kubeConfigFile: <path-to-kubeconfig-file>
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: true

Vous aurez également besoin d’un fichier kubeconfig distinct pour configurer le serveur distant, comme :

# clusters refers to the remote service.
clusters:
- name: name-of-remote-imagepolicy-service
  cluster:
    certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
    server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
  user:
    client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
    client-key: /path/to/key.pem          # key matching the cert

Lorsqu’il est correctement configuré, cela permettra au serveur API Kubernetes de se connecter à un service distant (c’est-à-dire le serveur distant que nous avons défini ci-dessus) lors de la prise de décisions sur les admissions. Encore une fois, l’avantage de cette approche est que vous pouvez définir les règles d’admission de manière externe, sans avoir à intégrer le moteur de politique que vous souhaitez utiliser dans le serveur API Kubernetes lui-même (parce que, honnêtement, la configuration du serveur API est suffisamment compliquée en soi).

En résumé, les contrôleurs d’admission Kubernetes constituent une ressource puissante et, du moins selon les normes de Kubernetes, relativement facile à utiliser pour ajouter une autre couche de sécurité à vos clusters. Les contrôleurs d’admission spécifiques que vous choisissez d’activer peuvent varier en fonction de vos workloads, et vous pouvez avoir ou non une raison de définir des contrôleurs personnalisés à l’aide de webhooks.

Mais au minimum, n’hésitez pas à activer au moins les contrôleurs d’admission par défaut pour chaque cluster Kubernetes que vous avez l’intention d’utiliser pour tout type de workload de production.