Présentation
Les outils d'orchestration tels que Kubernetes ont introduit des niveaux de résilience et de polyvalence sans précédent dans le déploiement et la gestion des logiciels. Ils ont également braqué les projecteurs sur les insuffisances du paysage sécuritaire actuel.
L'architecture dispersée de Kubernetes nous offre plusieurs couches supplémentaires. Nous pouvons les utiliser pour améliorer et développer les paramètres de sécurité existants. Si vous configurez ces couches correctement, elles peuvent isoler toute menace de sécurité avant qu'elle n'éclate à partir de son point d'origine.
Cet article se concentre sur les mesures que vous pouvez prendre pour améliorer la sécurité globale de votre cluster Kubernetes.
1. Activer le contrôle d'accès basé sur les rôles (RBAC)
La complexité d'un système fonctionnant sur plusieurs appareils, avec de nombreux microservices interconnectés gérés par des centaines d'individus et de services publics, est un cauchemar logistique.
Exercez un contrôle strict sur les autorisations accordées aux utilisateurs. Kubernetes est partisan du contrôle d'accès basé sur les rôles (RBAC) méthode. La méthode de contrôle d'accès basée sur les rôles signifie qu'aucun utilisateur n'a plus d'autorisations qu'il n'en a besoin pour accomplir efficacement leurs tâches. Kubernetes est une question d'automatisation, et RBAC utilise un groupe d'API pour piloter les décisions d'autorisation via l'API Kubernetes.
Depuis la version 1.8 de Kubernetes, le mode RBAC est stable et soutenu par l'API rbac.authorization.k8s.io/v1. Activez RBAC en démarrant le serveur API avec la commande suivante :
--authorization-mode=RBACKubernetes dispose d'un ensemble de rôles prédéfinis pour les utilisateurs humains et les composants, tels que les applications, les contrôleurs et les nœuds. Ces rôles prédéfinis sont nombreux et offrent un niveau par défaut raisonnable de rôles distincts pour les tâches les plus courantes.
2. Gardez vos secrets secrets
Dans Kubernetes, un secret est un petit objet qui contient des données sensibles, comme un mot de passe ou un jeton.
Même si un pod n'est pas en mesure d'accéder aux secrets d'un autre pod, il est crucial de séparer le secret d'une image ou d'un pod. Sinon, toute personne ayant accès à l'image aurait également accès au secret. Les applications complexes qui gèrent plusieurs processus et ont un accès public sont particulièrement vulnérables à cet égard.
Attribuer des processus à différents conteneurs
Chaque conteneur d'un pod doit demander le volume secret dans son volume. Réduisez le risque que des secrets soient exposés en divisant les processus dans des conteneurs séparés. Utilisez un conteneur frontal qui interagit avec les utilisateurs mais ne peut pas voir la clé privée.
Complétez ce conteneur avec un conteneur de signataire qui peut voir la clé privée et répondre aux demandes de signature simples du front-end. Cette approche partitionnée oblige un attaquant à effectuer un ensemble d'actions complexes pour tenter de violer vos mesures de sécurité.
3. Restreindre le trafic de pod à pod avec une politique réseau Kubernetes
Il s'agit d'une bonne pratique de sécurité Kubernetes pour imposer le protocole de sécurité TLS à chaque niveau du pipeline de déploiement d'applications. Cependant, il est également impératif de sécuriser les éléments individuels qui composent le cluster et les éléments qui contrôlent l'accès au cluster.
Les pods acceptent le trafic de n'importe quelle source par défaut. Lorsque vous définissez des politiques de réseau , vous définissez des règles spécifiques sur la façon dont les pods communiquent au sein d'un cluster et avec des ressources externes.
Les politiques de réseau ne sont pas en conflit, mais plutôt additives. Définir une politique réseau dans un espace de noms signifie que le pod va rejeter toute connexion non autorisée par cette politique, isolant efficacement le pod. Le module est limité à ce qui est approuvé par la combinaison de plusieurs règles de réseau.
4. Améliorer la sécurité des pods
Sécuriser le noyau avec AppArmor ou SELinux
Les conteneurs partagent le même noyau, ce qui rend nécessaire l'utilisation d'outils supplémentaires pour améliorer l'isolation des conteneurs. Modules de sécurité, comme AppArmor et des systèmes qui appliquent des politiques de contrôle d'accès comme SELinux , confinent les programmes utilisateur et les services système. Ils sont également utilisés pour refuser l'accès aux fichiers et limiter les ressources réseau.
AppArmor limite l'ensemble des ressources disponibles pour un conteneur au sein du système. Chaque profil peut s'exécuter soit en application mode, qui bloque l'accès aux ressources non autorisées ou se plaint mode qui signale uniquement les violations. Un rapport rapide des problèmes potentiels améliore considérablement les capacités de journalisation et d'audit de vos systèmes.
SELinux gère l'allocation des ressources indépendamment de l'ACM Linux général (mécanisme de contrôle d'accès). Il ne reconnaît pas de superutilisateur (root) et ne dépend pas des binaires setuid/setgid.
La sécurisation d'un système sans SELinux repose sur la configuration appropriée des applications privilégiées et du noyau lui-même. Une mauvaise configuration dans ces zones peut compromettre l'ensemble du système. La sécurité d'un système basé sur un noyau SELinux dépend de l'exactitude du noyau et de la configuration de sa politique de sécurité.
Les attaques représentent toujours une menace importante. Cependant, avec SELinux, les programmes utilisateur individuels et les démons système ne doivent pas nécessairement mettre en danger la sécurité de l'ensemble du système.
Défauts et tolérances
Kubernetes offre la possibilité de créer des règles prédéfinies lorsque le système attribue de nouveaux pods aux nœuds.
En tant qu'outil d'orchestration, Kubernetes a tendance à démarrer les pods à l'emplacement le plus efficace du cluster, c'est-à-dire l'emplacement avec la charge de travail la plus faible. Il est possible d'ajuster le placement des pods en définissant des souillures et des tolérances.
Les teintes permettent aux nœuds de "rejeter" un pod ou un ensemble de pods en fonction de règles prédéfinies. D'un autre côté, les tolérances sont appliquées au niveau du pod, et elles permettent aux pods de planifier des nœuds avec des teintes correspondantes (les clés et les effets sont les mêmes).
Les teintes et les tolérances doivent être utilisées en tandem pour s'assurer que les pods ne sont pas programmés sur des nœuds inappropriés.
Espaces de noms
Kubernetes ne dispose pas d'un mécanisme assurant la sécurité des espaces de noms. Limitez l'utilisation des espaces de noms, en tant que fonctionnalité de sécurité, dans les domaines de confiance et à des fins internes. N'utilisez pas les espaces de noms lorsque vous souhaitez refuser à un utilisateur du cluster Kubernetes l'accès à l'une des autres ressources des espaces de noms.
La watch et list Les requêtes permettent aux clients d'inspecter les valeurs de tous les secrets qui se trouvent dans cet espace de noms. Seuls les composants de niveau système les plus privilégiés doivent être autorisés à implémenter ces demandes.
5. Mises à jour continues de Kubernetes
Il est devenu impossible de traquer tous les vecteurs d'attaque potentiels. Ce fait est regrettable car il n'y a rien de plus vital que d'être conscient et au-dessus des menaces potentielles. La meilleure défense consiste à vous assurer que vous utilisez la dernière version disponible de Kubernetes.
Il existe plusieurs techniques telles que les mises à jour progressives et les migrations de pools de nœuds qui vous permettent d'effectuer une mise à jour avec un minimum d'interruptions et de temps d'arrêt.
6. Définir les politiques d'audit
La journalisation d'audit enregistre la chronologie des événements qui se produisent dans un cluster Kubernetes. En gardant une trace des actions entreprises par les utilisateurs et l'API Kubernetes, les administrateurs peuvent analyser la chaîne d'événements qui ont conduit à un problème potentiel.
Kubernetes vous permet d'affiner les stratégies d'audit en définissant la fréquence à laquelle les événements sont consignés, si des alertes doivent être émises et la procédure de résiliation des pods concernés.
Utilisez régulièrement la journalisation d'audit pour vous assurer que votre système est à jour et que les menaces sont gardées sous onglet. Un déploiement basé sur un conteneur ajoute une autre dimension au processus d'audit. Une comparaison entre l'image d'origine et l'image exécutée dans le conteneur peut être utilisée efficacement pour voir si des écarts peuvent entraîner des problèmes de sécurité. Assurez-vous que les versions de vos logiciels contiennent toujours les derniers correctifs de sécurité.