Sécurité Kubernetes : erreurs courantes et meilleures pratiques

Pourquoi la sécurité Kubernetes est-elle importante ?

La sécurité dans Kubernetes est un enjeu crucial en raison des nombreuses menaces qui planent sur les clusters et les pods. Notamment :

• Acteurs malveillants

• Malwares dans les conteneurs

• Images de conteneurs corrompues

• Utilisateurs compromis ou négligents

Sans contrôles efficaces, un acteur malveillant qui pénètre dans une application peut prendre le contrôle de l’hôte ou du cluster tout entier.

Où se situe Kubernetes dans le processus de développement global ?

Le diagramme ci-dessous schématise le rôle joué par la sécurité Kubernetes dans le cycle de vie du développement logiciel (SDLC). Le code est testé après l’étape de build pour confirmer l’absence de failles avant sa publication dans l’environnement de production Kubernetes. Les équipes de déploiement et de sécurité de l’infrastructure cloud suivent ensuite l’exécution des applications et rapportent leurs conclusions aux développeurs, créant ainsi une boucle de rétroaction vertueuse entre le code et le cloud.

La sécurité Kubernetes dans le cycle du développement logiciel

Les grands écueils de la sécurité Kubernetes

Parmi les problèmes que peut soulever la sécurité Kubernetes, voici les trois plus critiques :

1. Configurer les contrôles de sécurité Kubernetes : lorsque vous déployez Kubernetes par vous-même à partir de ressources open source, les contrôles de sécurité préconfigurés sont inexistants. Il revient à l’opérateur de cerner leur fonctionnement et de les configurer de façon à garantir votre sécurité.

2. Déployer les charges de travail en toute sécurité : que vous optiez pour une distribution Kubernetes avec contrôles de sécurité préconfigurés ou que vous préfériez bâtir un cluster et sa sécurité par vos propres soins, les développeurs et leurs équipes dédiées aux applications qui ne sont pas familiers avec les rouages de Kubernetes peuvent avoir du mal à sécuriser les charges de travail.

3. Composer avec un manque de sécurité intégrée : Kubernetes propose des contrôles des accès et des fonctionnalités pour faciliter la création d’un cluster sécurisé. Pour autant, sa configuration par défaut n’est pas 100 % sûre. Votre organisation doit ajuster comme il se doit la configuration de l’infrastructure, des réseaux, des charges de travail et des clusters pour garantir que les clusters et les conteneurs Kubernetes sont entièrement sécurisés.

Les défis de la sécurité Kubernetes et leurs solutions

Si les solutions de sécurité intégrées de Kubernetes ne couvrent pas tous les problèmes potentiels, il en existe de nombreuses autres dans son écosystème.

Pamir les points clés de Kubernetes qui nécessiteront des outils de sécurité additionnels :

1. La sécurité des charges de travail : la majorité des charges de travail de Kubernetes prennent la forme de conteneurs exécutés sur des moteurs comme containerd, cri-o ou Docker. Le code et les autres paquets qui se trouvent dans ces conteneurs doivent être exempts de vulnérabilités.

2. La configuration des charges de travail : que vous utilisiez les manifestes Kubernetes, les graphiques Helm ou les outils de templating, la configuration du déploiement de vos applications dans Kubernetes est généralement réalisée sous forme de code. Ce code affecte les contrôles de sécurité Kubernetes qui déterminent l’exécution d’une charge de travail et ce qui peut – ou ne peut pas – avoir lieu en cas de faille. Par exemple, limiter la disponibilité du processeur, de la mémoire et des réseaux à l’usage maximum attendu pour chaque charge de travail permettra de contenir toute faille éventuelle et d’éviter que d’autres services soient compromis.

3. La configuration des clusters : différents outils, comme Sysdig, Falco ou encore Prometheus sont disponibles pour évaluer la sécurité Kubernetes de vos clusters en cours d’exécution. Ces solutions utilisent notamment les journaux d’audits et des indicateurs intégrés de Kubernetes pour vérifier le respect des meilleures pratiques de sécurité édictées Kubernetes et des autres benchmarks de sécurité pertinents, comme les critères CIS.

4. Le réseau Kubernetes : sécuriser le réseau est essentiel avec Kubernetes. Les communications des pods, l’entrée, la sortie, la découverte de service et – si nécessaire – les maillages de service (p. ex. Istio) doivent tous entrer en ligne de compte. En cas de violation d’un cluster, chaque service et chaque machine du réseau est en danger. Aussi, il est crucial que la communication entre vos services soit limitée au strict minimum pour les isoler les uns des autres. Cette stratégie, couplée à l’utilisation de cryptographie pour garantir le caractère confidentiel de vos machines et de vos services, peut aider à contenir les menaces et prévenir les failles de réseau à grande échelle.

5. La sécurité de l’infrastructure : une application distribuée étant exécutée sur plusieurs serveurs (via un réseau et un stockage virtuels ou physiques), il est essentiel de sécuriser votre infrastructure Kubernetes, en particulier les nœuds maîtres, les bases de données et les certificats. Si un acteur malveillant parvient à entrer dans votre infrastructure, il peut potentiellement mettre la main sur tous les éléments requis pour accéder à votre cluster et à vos applications.

Tous ces défis peuvent être résolus grâce à des outils de sécurité disponibles dans l’écosystème Kubernetes. Le partenariat entre Snyk et Sysdig assure un meilleur alignement entre les développeurs et les équipes SecOps en proposant des outils axés sur le développement pour chaque aspect de la sécurité Kubernetes, des conteneurs aux clusters. Snyk propose des outils de sécurité orientés développeurs qui sont utiles tout au long du cycle du développement logiciel, comme Snyk Container et Snyk Open Source. En combinant ces workflows tournés vers les développeurs avec Sysdig, nous pouvons transmettre les informations de suivi de l’exécution de Sysdig (qui emploie les journaux d’audit pour monitorer les environnements Kubernetes) aux développeurs directement dans leurs workflows habituels. Ce partenariat constitue la toute première plateforme de gestion de la posture de sécurité dans le cloud axée sur les développeurs.

Résultat d’analyse de la configuration de charges de travail Kubernetes dans Snyk

Comment sécuriser les hôtes Kubernetes

L’hôte cloud constitue la couche finale d’un environnement Kubernetes. Les plus grands fournisseurs cloud offrent des outils de gestion pour les ressources Kubernetes. Citons par exemple Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) et Elastic Kubernetes Service (EKS) chez Amazon. Néanmoins, la sécurité s’inscrit toujours dans le cadre d’un modèle de responsabilité partagée.

Plusieurs bons réflexes sont à appliquer pour protéger un hébergeur Kubernetes contre les vulnérabilités :

• Sécuriser la couche de la charge de travail : vérifiez que les images des conteneurs ne présentent pas de vulnérabilités et sont convenablement configurées (en veillant à désactiver les conteneurs privilégiés par exemple).

• Créer des barrières entre les charges de travail et les hôtes : limitez l’accès aux ressources de l’hôte en réduisant les privilèges des conteneurs et configurez l’environnement d’exécution de façon à restreindre l’utilisation des ressources en cas de violation.

• Surveiller les clusters en cours d’exécution : veillez à analyser les journaux d’audit pour identifier toute configuration erronée ou tout comportement suspect.

Contexte de sécurité Kubernetes : les paramètres à appliquer

Les paramètres de type securityContext sont très utiles pour empêcher les pods et les clusters d’accéder au reste du système Kubernetes. Voici 10 paramètres de contexte de sécurité que chaque pod et conteneur doit utiliser :

1. runAsNonRoot : définissez-le sur true pourempêcher les conteneurs de s’exécuter en tant qu’utilisateur racine.

2. runAsUser / runAsGroup : pour limiter l’exécution des conteneurs à un utilisateur/un groupe donné.

3. seLinuxOptions : définit le contexte SELinux qui est appliqué au conteneur ou au pod.

4. seccompProfile : permet de configurer le profil seccomp au niveau du noyau Linux pour restreindre le champ d’action des conteneurs.

5. privileged / allowPrivilegeEscalation : définissez-les sur false, car en général il est déconseillé d’autoriser les conteneurs privilégiés ou de permettre à certains processus qui les composent d’élever leurs privilèges.

6. capabilities : permet de contrôler l’accès aux appels au niveau du noyau. Limitez ce paramètre au minimum requis.

7. readonlyRootFilesystem : définissez-le sur true quand cela est possible pour empêcher toute personne malveillante d’installer un logiciel ou de changer les configurations du système de fichiers.

8. procMount : utilisez le paramètre Default, sauf dans des cas particuliers tels que les conteneurs imbriqués.

9. fsGroup / fsGroupChangePolicy : ce paramètre doit être utilisé avec discernement, car la modification du propriétaire d’un volume via fsGroup peut avoir un impact sur les performances de démarrage des pods et présenter des conséquences négatives sur les systèmes de fichiers partagés.

10. sysctls : la modification des paramètres du noyau par le biais de sysctl doit être évitée, sauf en cas d’exigences très spécifiques, car cela peut déstabiliser le système hôte.

Observabilité de la sécurité Kubernetes

S’il est important d’utiliser des configurations sûres pour tirer le meilleur parti des fonctions de sécurité fournies par Kubernetes, il est aussi crucial d’utiliser des processus de monitoring efficaces pour conserver une bonne visibilité sur les ressources Kubernetes. Voici nos conseils pour la surveillance dans Kubernetes :

• Utiliser des balises et des étiquettes : ces éléments permettent de définir les applications à l’aide de métadonnées pour simplifier leur gestion.

• Monitorer l’ensemble des conteneurs et non pas des conteneurs spécifiques : comme Kubernetes gère les pods (et non les conteneurs), il faut suivre l’activité au niveau des pods.

• Utiliser la découverte de service : cela facilite le monitoring des services Kubernetes, qui sont de nature volatile.

• Tirer parti des alertes : configurez des critères pour recevoir des alertes quand les indicateurs de bonne santé de votre environnement Kubernetes s’éloignent de la norme. Veillez cependant à ne pas générer trop d’alertes, car les systèmes distribués contiennent beaucoup de points de terminaison possibles pour le monitoring.

• Inspecter le plan de contrôle :le plan de contrôle de Kubernetes est semblable à un aiguilleur du ciel pour les charges de travail et les clusters. Scrutez chaque élément du plan de contrôle pour vérifier que les tâches sont bien planifiées et efficacement orchestrées.

Les meilleures pratiques de sécurité Kubernetes pour chaque phase

Voici les bons réflexes à adopter pour chaque phase :

Phase de développement/de conception

• En matière de sécurité, tous les environnements Kubernetes ne se valent pas. Nous vous conseillons d’utiliser une architecture à plusieurs clusters ou plusieurs espaces de noms avec des contrôles RBAC adaptés pour mieux isoler les charges de travail.

Phase de build

• Choisissez une image minimale issue d’un référentiel de confiance.

• Utilisez des outils d’analyse des conteneurs pour repérer toute vulnérabilité ou configuration erronée au sein des conteneurs.

Phase de déploiement

• Les images doivent être analysées et validées avant le déploiement.

• Un contrôleur d’admission peut être utilisé pour automatiser ce processus et limiter le déploiement aux seules images de conteneurs validées.

Phase d’exécution

• L’environnement d’exécution constitue la dernière ligne de défense des ressources Kubernetes.

• L’API Kubernetes génère des journaux d’audit qui doivent être monitorés à l’aide d’un outil dédié à la sécurité de l’exécution, comme Sysdig.

• Les fichiers de politiques et les images doivent aussi être analysés en continu pour prévenir toute présence de malware ou configuration erronée dans l’environnement d’exécution.

En savoir plus sur la sécurité Kubernetes

Consultez ces ressources additionnelles pour approfondir vos connaissances sur la sécurité Kubernetes.

• 10 paramètres du contexte de sécurité Kubernetes qu’il faut comprendre

• Security implications of Kubernetes operators (Les implications de sécurité pour les opérateurs Kubernetes)

• Risk of Containers running in privileged mode – Snyk Learn (Les risques liés à l’exécution de conteneurs en mode privilégié – Snyk Learn)

• Container doesn’t drop default capabilities – Snyk Learn (Comment supprimer les capacités par défaut d’un conteneur – Snyk Learn)

Par ailleurs, Snyk peut vous aider à optimiser et maintenir votre posture de sécurité Kubernetes avec ses outils de sécurité pensés pour les développeurs, comme Snyk Container et Snyk IaC. Snyk peut automatiser l’analyse du code d’applications, des images de conteneurs et des configurations Kubernetes puis, sur la base de ces données, livrer aux développeurs des recommandations et des informations utiles directement au sein de leurs workflows.

« Les outils comme Snyk nous aident à identifier les zones de nos services potentiellement vulnérables aux menaces externes », explique Ciro Rizzo. \[...] « Depuis que Snyk fait partie de notre pipeline de CI/CD, les contrôles de sécurité sont toujours réalisés plus en amont dans le processus de développement. »

Ciro Rizzo - Directeur de l’ingénierie - The Telegraph

De plus, notre récent partenariat avec Sysdig nous a permis d’étendre nos capacités de sécurité à l’environnement d’exécution.

FAQ sur la sécurité Kubernetes