Principes fondamentaux de la sécurité des conteneurs : orchestration

Si vous découvrez cette série, nous vous conseillons de commencer par le début :
Principes de base de la sécurité des conteneurs : introduction
Principes de base de la sécurité des conteneurs : pipeline

Selon le rapport 2019 de Tripwire sur l’état de la sécurité des conteneurs, près d’une organisation sur trois (32 %) exploite actuellement plus de 100 conteneurs en production. Une proportion plus faible (13 %) en exploite plus de 500. Et 6 % des organisations ayant adopté cette technologie avec le plus d’enthousiasme en gèrent actuellement plus de 1 000. Peu d’organisations exploitent des conteneurs à grande échelle sans système d’orchestration pour les y aider.

La couche d’orchestration de la sécurité des conteneurs se concentre sur l’environnement chargé de leur fonctionnement quotidien. D’après les données actuellement disponibles, si vous utilisez des conteneurs, vous avez presque certainement recours à Kubernetes comme orchestrateur.

Il est important de noter qu’il existe d’autres orchestrateurs, mais que la plupart d’entre eux s’appuient également sur des composants et des concepts issus de Kubernetes. Nous nous concentrerons donc sur la sécurité de Kubernetes et de ses composants.

L’environnement Kubernetes

Kubernetes se compose de nombreux éléments interdépendants. Sa sécurisation est donc plus complexe, non seulement en raison du nombre de composants concernés, mais aussi de la manière dont ils interagissent. Certains communiquent via une API, d’autres via le système de fichiers de l’hôte. Tous constituent des points d’entrée potentiels dans l’environnement d’orchestration et doivent être pris en compte.

Environnement Kubernetes de base

Un aperçu rapide des principaux composants nécessitant une attention particulière :

• Serveur d’API et kubelet
• Pods
• Etcd

Autrement dit, prenez une tasse de café : il vous faudra un peu plus de temps pour en venir à bout.

1. L’authentification n’est pas facultative

Les lecteurs avisés remarqueront que cela leur semble familier. Vous en avez peut-être entendu parler sous le nom de deuxième règle de sécurité, aussi appelée « Verrouillez la porte ». C’est un thème récurrent sur lequel nous continuerons d’insister, car il est souvent négligé. Une authentification forte est indispensable. Nous avons constaté que le nombre d’incidents de sécurité dus à de mauvaises pratiques en matière de sécurité des conteneurs continue d’augmenter. L’une des causes courantes est l’absence d’authentification, généralement lors d’un déploiement dans le cloud public.

Exigez des identifiants robustes et renouvelez-les régulièrement. L’accès au serveur d’API (via des consoles non sécurisées) peut conduire à une situation où « la partie est terminée », car il permet de contrôler l’ensemble de l’environnement d’orchestration. Il devient alors possible de déployer des pods, de modifier des configurations et d’arrêter ou de démarrer des conteneurs. Dans un environnement Kubernetes, le serveur d’API est « l’API unique pour les gouverner toutes » qu’il faut impérativement tenir hors de portée des acteurs malveillants.

Comment sécuriser le serveur d’API et Kubelet
Il est important de noter que ces recommandations reposent sur le modèle d’autorisation actuel de Kubernetes. Consultez toujours la documentation la plus récente correspondant à la version que vous utilisez.

• Activez le mTLS partout
  - Dédiez une autorité de certification à chaque service – k8s, etcd, applications
  - Renouvelez les certificats et faites attention aux autorisations des clés privées sur le disque
  
• Lier uniquement aux adresses sécurisées
  - Faites attention aux paramètres de configuration de l’API « insecure-bind-address » et « insecure-port »
  - Appliquez cette règle à _tous_ les services (SSH, Vault, etcd)
  
• Désactiver l’« authentification anonyme »
  - L’« authentification anonyme » vous semble-t-elle être une bonne idée ?
  - Désactivée par défaut depuis la version 1.5, elle peut être activée manuellement avec « --anonymous-auth=True »
  
• Activer l’autorisation
  - N’utilisez pas « --authorization-mode=AlwaysAllow »
  - Le serveur d’API doit utiliser « --authorization-mode=RBAC,Node »
  - Le kubelet doit utiliser « --authorization-mode=Webhook »
  - Limiter le kubelet afin qu’il puisse uniquement accéder aux ressources de son propre nœud.
  

Il est important de noter que ces recommandations reposent sur le modèle d’autorisation actuel de Kubernetes. Consultez toujours la documentation la plus récente correspondant à la version que vous utilisez.

• Référence sur l’autorisation Kubernetes
• Référence sur l’authentification et l’autorisation de Kubelet

2. Pods et privilèges

Les pods sont des ensembles de conteneurs. Ils constituent le plus petit composant de Kubernetes et, selon le plug-in Container Network Interface (CNI) utilisé, tous les pods peuvent être en mesure de communiquer entre eux par défaut. Certains plug-ins CNI peuvent utiliser des « politiques réseau » afin d’imposer des restrictions à ce comportement par défaut. Il est important de le souligner, car les pods peuvent être planifiés sur différents nœuds Kubernetes (comparables à des serveurs physiques). Les pods montent aussi couramment des secrets, qui peuvent contenir des clés privées, des jetons d’authentification et d’autres informations sensibles. D’où leur appellation de « secrets ».

Cela signifie que les pods soulèvent plusieurs préoccupations en matière de sécurité. Chez F5, lorsque nous commençons à modéliser les menaces, nous partons toujours du principe qu’un pod est compromis. En effet, c’est dans les pods que sont déployées les charges de travail applicatives. Comme celles-ci sont les plus susceptibles d’être exposées à des accès non fiables, elles constituent le point de compromission le plus probable. Cette hypothèse conduit à se poser quatre questions fondamentales afin de déterminer comment atténuer les menaces potentielles.

1. Que pourrait voir ou faire un attaquant sur d’autres pods s’il avait accès à un pod ?
2. Un attaquant peut-il accéder à d’autres services du cluster ?
3. Quels secrets sont montés automatiquement ?
4. Quelles autorisations ont été accordées au compte de service du pod ?

Les réponses à ces questions mettent en évidence des risques qui pourraient être exploités si un attaquant accédait à un pod au sein du cluster. L’atténuation des menaces liées à la compromission d’un pod nécessite une approche multidimensionnelle faisant appel à des options de configuration, au contrôle des privilèges et à des restrictions au niveau du système. N’oubliez pas que plusieurs pods peuvent être déployés sur un même nœud (physique ou virtuel) et partagent donc l’accès au système d’exploitation, généralement Linux.

Comment atténuer les menaces liées aux pods
Kubernetes comprend une ressource Pod Security Policy qui contrôle les aspects sensibles d’un pod. Elle permet aux opérateurs de définir les conditions dans lesquelles un pod doit fonctionner pour être autorisé dans le système et impose une configuration de référence pour le Security Context du pod. Ne partez jamais du principe que les paramètres par défaut sont sécurisés. Mettez en œuvre des configurations de référence sécurisées et vérifiez qu’elles répondent aux attentes afin de vous prémunir contre les menaces liées aux pods.

Les options spécifiques d’une Pod Security Policy doivent couvrir les points suivants :

• Éviter les conteneurs privilégiés
  • Recherchez le paramètre « —allow-privileged » sur kube-api et/ou kubelet
  • Recherchez « privileged: true » dans la spécification du pod.
  • Réduisez les risques de sécurité avec « --allow-privileged=false »
• L’utilisateur par défaut du conteneur avec Docker est root
  • Évitez d’exécuter une quelconque charge de travail en tant que root
  • La stratégie de sécurité des pods peut utiliser « runAsUser », « runAsGroup » et « runAsNonRoot: true »
  • Des options similaires peuvent être définies dans un Dockerfile
• Interdire l’élévation de privilèges au sein d’un conteneur
  • « allowPrivilegeEscalation: false »
• Utilisez SELinux / AppArmor
  • SELinux utilisera la sécurité multicatégorie (MCS) pour isoler les conteneurs les uns des autres
  • Laissez-le activé et traitez les refus
  • La désactivation ou le passage en mode permissif réduit considérablement la sécurité
• Prévenir les attaques par liens symboliques / points d’entrée
  • Les attaquants peuvent écraser le binaire du point d’entrée ou créer des liens symboliques malveillants
  • Évitez cela en définissant « readOnlyRootFilesystem: true »
• Évitez les options de configuration host*
  • Les attaquants ayant accès aux ressources de l’hôte sont plus susceptibles d’étendre leur compromission à l’hôte et/ou aux conteneurs adjacents
  • Évitez les options telles que hostPID, hostIPC, hostNetwork et hostPorts
• Montages hostPath en lecture seule
  • S’il est nécessaire de configurer un accès en lecture/écriture à l’hôte, soyez prudent lors du déploiement et n’en faites surtout pas une pratique par défaut.
  • Utilisez « readOnly » sur tous les allowedHostPaths afin d’éviter les attaques
• Profils Seccomp
  • Réduisez la surface d’attaque en limitant les appels système autorisés
  • Le profil par défaut de Docker réduira certains risques, mais il s’agit d’un profil générique
  • Les profils spécifiques à l’application offriront le niveau de sécurité le plus élevé

3. Etcd

Etcd est le magasin de données utilisé pour la configuration et les secrets. Sa compromission peut permettre l’extraction de données sensibles ou l’injection de données malveillantes. Aucune de ces situations n’est souhaitable. Pour atténuer les menaces pesant sur etcd, il faut en contrôler l’accès. Le meilleur moyen d’y parvenir consiste à imposer le mTLS. Les secrets sont stockés par Kubernetes dans etcd sous forme de données encodées en base64. Envisagez d’utiliser une fonctionnalité alpha, « encryption provider », afin de bénéficier d’options plus robustes pour stocker les secrets sensibles, ou envisagez d’utiliser HashiCorp Vault.

Lisez l’article suivant de la série :
Principes de base de la sécurité des conteneurs : charges de travail