Sécuriser un pod Kubernetes avec Regula et Open Policy Agent

Fugue a récemment ajouté la prise en charge de Kubernetes dans Regula, notre moteur de politiques open source qui vérifie l’infrastructure en tant que code. Regula peut non seulement vérifier vos fichiers Terraform et CloudFormation afin de détecter les problèmes de sécurité et de conformité, mais aussi analyser les manifestes YAML Kubernetes !

Dans cet article, nous allons montrer comment exécuter Regula sur un manifeste Kubernetes pour détecter un pod non sécurisé, puis le sécuriser. En bonus, la version finale du manifeste sera conforme au CIS Kubernetes Benchmark v1.6.1, un ensemble de recommandations pour sécuriser les environnements Kubernetes.

Prêts ? C’est parti !

Pour commencer

Commencez par installer Regula. Si vous utilisez Homebrew, exécutez les commandes suivantes :

brew tap fugue/regula
brew install regula

Vous pouvez aussi installer un binaire précompilé pour votre plateforme ou, si vous préférez, exécuter Regula avec Docker.

Pour rédiger cet article, nous avons utilisé Regula v1.5.0.

Ensuite, consultez notre gist GitHub, cliquez sur le bouton Download ZIP, puis extrayez les fichiers. Il y en a deux :

• pod.yaml : un manifeste Kubernetes non conforme et non sécurisé

• pod-compliant.yaml : une version conforme et sécurisée du même manifeste

Au fil des explications sur la correction de chaque problème, vous pouvez suivre les étapes en modifiant manuellement pod.yaml, ou simplement consulter la version sécurisée pod-compliant.yaml.

Examiner le manifeste

Notre manifeste déclare un pod simple nommé hello, qui contient un seul conteneur BusyBox, également nommé hello :

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']

Il ne semble pas dangereux, n’est-ce pas ? Mais lançons Regula pour en avoir le cœur net.

Exécuter Regula

Dans votre terminal, accédez au répertoire contenant les fichiers téléchargés. Nous allons exécuter Regula sur pod.yaml avec l’option --format compact pour réduire la sortie :

regula run pod.yaml --format compact

Voici le résultat :

Aïe ! Notre pod est loin d’être aussi sécurisé qu’il pourrait l’être. Regula a détecté 6 problèmes.

Pas d’inquiétude : nous pouvons tous les corriger ! Examinons chaque problème pour savoir comment y remédier.

Corriger les problèmes

Jetons de compte de service

Le problème : « ‘automountServiceAccountToken’ du compte de service doit être défini sur ‘false’ [Medium] »

Contrôle CIS Kubernetes v1.6.1 : 5.1.6, « Veiller à ce que les jetons de compte de service ne soient montés que lorsque cela est nécessaire »

Pourquoi c’est important : Les jetons de compte de service servent à authentifier les requêtes envoyées par les processus du cluster au serveur d’API Kubernetes. Par défaut, ils sont montés automatiquement dans tous les pods. Cependant, si un acteur malveillant parvient à compromettre un pod, il pourrait utiliser son jeton de compte de service pour lancer une attaque d’élévation de privilèges et prendre le contrôle de l’ensemble du cluster.

Ainsi, si une charge de travail n’a pas besoin de communiquer avec le serveur d’API, mieux vaut éviter le montage automatique d’un jeton de compte de service. Cela respecte le principe de sécurité du moindre privilège.

Comment corriger le problème : définissez automountServiceAccountToken sur false dans la spécification du pod :

spec:
  automountServiceAccountToken: false

Voir la ligne 10 dans pod-compliant.yaml.

Utilisateur root

Le problème : « Les pods ne doivent pas exécuter de conteneurs en tant qu’utilisateur root [Medium] »

Contrôle CIS Kubernetes v1.6.1 : 5.2.6, « Limiter l’admission de conteneurs root »

Pourquoi c’est important : Exécuter un processus en tant que root sans nécessité est presque toujours une mauvaise idée. Si un conteneur s’exécute en tant que root, un attaquant peut obtenir des privilèges root sur le système hôte en cas d’évasion du conteneur.

Comment corriger le problème : définissez runAsUser sur un identifiant utilisateur différent de zéro dans la spécification du pod, car 0 correspond à root :

spec:
  securityContext:
    runAsUser: 1001

Voir les lignes 8-9 dans pod-compliant.yaml.

Vous devez vous assurer que l’utilisateur indiqué ici est défini dans l’image Docker. Souvent, un utilisateur non-root est créé en exécutant la commande Linux useradd dans le Dockerfile, puis son identifiant est spécifié à l’aide de la commande USER.

Capacités Linux

Les deux problèmes suivants sont étroitement liés et, dans notre exemple, peuvent être corrigés de la même manière.

Le problème : « Les pods ne doivent pas exécuter de conteneurs avec la capacité NET_RAW [Medium] »

Contrôle CIS Kubernetes v1.6.1 : 5.2.7, « Limiter l’admission de conteneurs dotés de la capacité NET_RAW »

Le problème : « Les pods ne doivent pas exécuter de conteneurs avec les capacités par défaut [Moyenne] »

Contrôle CIS Kubernetes v1.6.1 : 5.2.9, « Limiter l’admission de conteneurs dotés de capacités »

Pourquoi c’est important : Lorsqu’un conteneur Linux s’exécute, il reçoit un ensemble de capacités par défaut qui confèrent des privilèges root spécifiques aux processus. La capacité NET_RAW est particulièrement dangereuse, car un attaquant peut s’en servir pour espionner le trafic réseau ou générer du trafic IP avec des adresses usurpées.

De nombreux services n’ont pas besoin de toutes les capacités par défaut. Il est donc préférable de toutes les supprimer, puis de rétablir celles qui sont nécessaires. Dans cet exemple, nous n’en rétablissons aucune, mais vous pouvez le faire avec add: ["FOO"].

Comment corriger le problème : définissez un securityContext pour le conteneur et indiquez les capacités à supprimer avec drop: ["ALL"], afin de corriger les deux problèmes à la fois (ou drop: ["NET_RAW"] pour ne corriger que le problème 5.2.7, si vous le souhaitez) :

spec:
  containers:
    - name: hello
      securityContext:
        capabilities:
          drop: ["ALL"]  

Voir les lignes 15-17 dans pod-compliant.yaml.

Profil seccomp

Le problème : « Le profil seccomp du pod doit être défini sur ‘docker/default’ [Medium] »

Contrôle CIS Kubernetes v1.6.1 : 5.7.2, « Veiller à ce que le profil seccomp soit défini sur docker/default dans les définitions de vos pods »

Pourquoi c’est important : Sous Linux, le mode Secure Computing (seccomp) limite les appels système autorisés. Les environnements d’exécution de conteneurs, comme Docker, fournissent généralement un profil seccomp par défaut qui désactive plusieurs appels système et améliore ainsi la sécurité.

Notez que le profil docker/default a été déprécié dans Kubernetes 1.11. Ainsi, malgré les recommandations du CIS Kubernetes v1.6.1, mieux vaut utiliser runtime/default à la place.

Comment corriger le problème : plusieurs méthodes sont possibles selon votre version de Kubernetes. Dans les versions antérieures à la v1.19, vous pouvez utiliser l’annotation seccomp.security.alpha.kubernetes.io/pod dans les métadonnées du pod :

metadata:
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Voir les lignes 5-6 dans pod-compliant.yaml.

Contexte de sécurité

Le problème : « Les pods et les conteneurs doivent appliquer un contexte de sécurité [Medium] »

Contrôle CIS Kubernetes v1.6.1 : 5.7.3, « Appliquer un contexte de sécurité à vos pods et conteneurs »

Pourquoi c’est important : Un contexte de sécurité pour un pod ou un conteneur définit divers paramètres de sécurité liés au contrôle d’accès, aux capacités Linux et aux privilèges. Il est recommandé de définir les paramètres adaptés à votre cas d’usage.

Comment corriger le problème : vous pouvez définir un contexte de sécurité au niveau du pod ou du conteneur. Si des paramètres sont définis aux deux niveaux et se chevauchent, ceux du conteneur prennent le pas sur ceux du pod.

Nous avons déjà défini un securityContext au niveau du pod pour empêcher l’exécution en tant que root, et au niveau du conteneur pour supprimer toutes les capacités. Nous avons donc déjà corrigé ce problème.

Voir les lignes 8-9 et 15-17 dans pod-compliant.yaml.

Exécuter Regula à nouveau

Maintenant que nous avons corrigé les 6 problèmes, voyons ce que Regula pense de notre pod désormais sécurisé. Voici le manifeste mis à jour, que nous avons préparé pour vous dans pod-compliant.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: hello
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default" 
spec:
  securityContext:
    runAsUser: 1001
  automountServiceAccountToken: false
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      securityContext:
        capabilities:
          drop: ["ALL"]

Si vous avez modifié pod.yaml au fil des étapes, exécutez la même commande qu’auparavant :

regula run pod.yaml --format compact

Si vous n’avez pas modifié pod.yaml (aucun jugement !), vous pouvez simplement exécuter Regula sur le manifeste pod-compliant.yaml :

regula run pod-compliant.yaml --format compact

Et voici le résultat :

No problems found. Nailed it.

Et voilà ! Nous avons corrigé avec succès tous les problèmes détectés par Regula dans notre pod non sécurisé. Beau travail !

Et maintenant ?

Maintenant que vous savez comment utiliser Regula pour sécuriser un manifeste Kubernetes, découvrez d’autres bonnes pratiques pour la sécurité Kubernetes.

Pour en savoir plus sur Regula, rendez-vous sur regula.dev. Vous y trouverez la liste de toutes nos règles Kubernetes. Vous pouvez aussi découvrir comment ignorer le résultat d’une règle ou même désactiver complètement une règle si elle n’est pas pertinente pour votre organisation.