Remarque perev. : Ce n'est pas le premier article contenant des recommandations générales de sécurité sur Kubernetes que nous traduisons sur notre blog. Cependant, sa pertinence - au moins pour rappeler des choses simples et importantes qui ne devraient pas être fermées aux yeux par manque de temps - n'est confirmée que par les événements récents mentionnés par l'auteur au début du document. À propos, l'auteur est Connor Gilbert, chef de produit pour StackRox, une plate-forme prête à l'emploi pour sécuriser les applications déployées au sein des clusters Kubernetes. Alors, voici ce qu'il conseille aux lecteurs du blog CNCF ...
NB : Pour rendre l'article plus informatif, pour certains des termes / méthodes mentionnés par l'auteur, nous avons ajouté des liens vers la documentation pertinente.
Le mois dernier, Kubernetes, le système d'orchestration de conteneurs le plus populaire au monde, a
découvert la première vulnérabilité de sécurité majeure qui a frappé l'écosystème du projet. La vulnérabilité
CVE-2018-1002105 permet aux attaquants de compromettre les clusters via le serveur API Kubernetes, ce qui permet d'exécuter du code malveillant pour installer des logiciels malveillants, etc.
Plus tôt dans l'année, la configuration incorrecte du panneau de configuration de Kubernetes a conduit au fait que les ressources Tesla
avaient un logiciel d'exploration de crypto-monnaie
installé . Ensuite, les attaquants ont profité du fait que l'un des panneaux Kubernetes n'était pas protégé par mot de passe, ce qui leur a permis d'accéder à l'un des pods avec un compte pour accéder à la plus grande infrastructure Tesla dans AWS.
Les organisations qui accélèrent la mise en œuvre des conteneurs et leur orchestration doivent également prendre des mesures obligatoires pour protéger une partie aussi critique de leur infrastructure. Vous trouverez ci-dessous neuf des meilleures pratiques de sécurité de Kubernetes basées sur les données des clients: suivez-les pour mieux protéger votre infrastructure.
1. Mise à jour vers la dernière version
Dans chaque version trimestrielle de [Kubernetes], il y a non seulement des corrections de bugs, mais aussi de nouvelles fonctionnalités de sécurité: pour en profiter, nous vous recommandons de travailler avec la dernière version stable.
L'utilisation de la dernière version avec les derniers correctifs sera particulièrement pertinente à la lumière de la récente découverte de CVE-2018-1002105. Les mises à jour et le support peuvent être plus difficiles que les nouvelles fonctionnalités proposées dans les versions, alors planifiez vos mises à jour au moins une fois par trimestre.
Simplifier considérablement les mises à jour peut utiliser les fournisseurs de solutions Kubernetes gérées.
2. Activer le contrôle d'accès basé sur les rôles (RBAC)
Utilisez
RBAC (Role-Based Access Control) pour contrôler qui peut accéder à l'API Kubernetes et quels droits ils ont. En règle générale, RBAC est activé par défaut dans Kubernetes version 1.6 et supérieure (ou ultérieure pour certains fournisseurs), mais si vous avez été mis à jour depuis et n'avez pas modifié la configuration, vous devez vérifier à nouveau vos paramètres. En raison du mécanisme par lequel le travail des contrôleurs d'autorisation dans Kubernetes est combiné
(pour la séquence générale des opérations, lisez l'article « Que se passe-t-il dans Kubernetes lorsque l'exécution de kubectl démarre? Partie 1 » - traduction approximative ) , vous devez avoir activé à la fois RBAC et ABAC hérité (Contrôle d'accès basé sur les attributs).
Cependant, l'activation de RBAC n'est pas suffisante - elle doit encore être utilisée efficacement. Dans le cas général, les droits sur l'ensemble du cluster
(à l'échelle du cluster) doivent être évités, en privilégiant les droits dans certains espaces de noms. Évitez de donner à quelqu'un des privilèges d'administrateur de cluster même pour le débogage - il est beaucoup plus sûr d'accorder des droits uniquement lorsque cela est nécessaire et de temps en temps.
Vous pouvez voir les rôles de cluster et simplement les rôles avec les commandes
kubectl get clusterrolebinding ou
kubectl get rolebinding --all-namespaces . Vous pouvez ainsi vérifier rapidement à qui le rôle d'
cluster-admin est
cluster-admin (dans cet exemple, c'est uniquement pour le groupe
masters ):
$ kubectl describe clusterrolebinding cluster-admin Name: cluster-admin Labels: kubernetes.io/boostrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate=true Role: Kind: ClusterRole Name: cluster-admin Subjects: Kind Name ---- ---- Group system:masters Namespace ---------
Si l'application nécessite un accès à l'API Kubernetes, créez des comptes de service distincts
(lisez-en plus à leur sujet dans ce document - environ la traduction ) . Et donnez-leur le minimum de droits requis pour chaque cas d'utilisation. Cette approche est bien meilleure que d'accorder trop de privilèges au compte par défaut dans l'espace de noms.
La plupart des applications n'ont pas du tout besoin d'accéder à l'API:
vous pouvez leur automountServiceAccountToken false pour
automountServiceAccountToken .
3. Utilisez des espaces de noms pour définir les limites de sécurité
La création d'espaces de noms séparés est importante en tant que premier niveau d'isolement des composants. Il est beaucoup plus facile d'ajuster les paramètres de sécurité - par exemple, les stratégies réseau - lorsque différents types de charges de travail sont déployés dans des espaces de noms distincts.
Votre équipe utilise-t-elle efficacement les espaces de noms? Vérifiez leur liste pour non standard (non créé par défaut):
$ kubectl get ns NAME STATUS AGE default Active 16m kube-public Active 16m kube-system Active 16m
4. Séparez les charges de travail sensibles.
Une bonne pratique pour limiter les conséquences potentielles d'un compromis consiste à exécuter des charges de travail avec des données sensibles sur un ensemble dédié de machines. Cette approche réduit le risque qu'une application moins sécurisée accède à l'application avec des données sensibles s'exécutant dans le même environnement exécutable de conteneur ou sur le même hôte. Par exemple, un kubelet d'un nœud compromis n'a généralement accès au contenu des secrets que s'ils sont montés sur des pods planifiés pour être exécutés sur le même nœud. Si des secrets importants peuvent être trouvés sur plusieurs nœuds de cluster, un attaquant aura plus de chances de les obtenir.
La séparation peut être effectuée à l'aide de
pools de nœuds -
pools de nœuds (dans le cloud ou sur site) - ainsi que des mécanismes de contrôle de Kubernetes, tels que les espaces de noms, les
souillures, les tolérances, etc.
5. Protégez l'accès aux métadonnées du service cloud
Les métadonnées sensibles - par exemple, les informations d'identification administratives du kubelet - peuvent être volées ou utilisées avec une intention malveillante pour augmenter les privilèges dans un cluster. Par exemple, une
découverte récente dans la prime aux bogues de Shopify a montré en détail comment un utilisateur pouvait dépasser l'autorité en recevant des métadonnées d'un fournisseur de cloud en utilisant des données spécialement générées pour l'un des microservices.
Dans GKE, la fonction de
dissimulation des métadonnées , la
dissimulation des
métadonnées , modifie le mécanisme de déploiement du cluster de manière à éviter un tel problème, et nous vous recommandons de l'utiliser jusqu'à ce qu'une solution permanente soit implémentée.
Des contre-mesures similaires peuvent être nécessaires dans d'autres environnements.
6. Créez et définissez des stratégies de réseau de cluster
Stratégies réseau - Stratégies
réseau - vous permettent de contrôler l'accès réseau vers et depuis les applications conteneurisées. Pour les utiliser, vous devez disposer d'un fournisseur de réseau prenant en charge une telle ressource; pour les fournisseurs de solutions Kubernetes gérées comme Google Kubernetes Engine (GKE), la prise en charge devra être activée. (L'activation des stratégies réseau pour les clusters existants dans GKE nécessitera une courte mise à jour continue.)
Une fois que tout est prêt, commencez par des politiques réseau par défaut simples - par exemple, en bloquant (par défaut) le trafic provenant d'autres espaces de noms.
Si vous utilisez Google Container Engine, vous pouvez vérifier si la prise en charge des stratégies est activée sur les clusters en fonctionnement:
$ gcloud container clusters list \ --format='table[box] (name,addonsConfig.networkPolicyConfig)'
7. Définissez la politique de sécurité des pods pour le cluster.
Stratégie de sécurité des pods -
Stratégie de sécurité des pods - définit les valeurs par défaut utilisées pour démarrer les charges de travail dans le cluster. Envisagez de définir une stratégie et d'activer le
contrôleur d'admission de la politique de sécurité des
pods : les instructions de ces étapes varient en fonction du fournisseur de cloud ou du modèle de déploiement utilisé.
Pour commencer, vous
NET_RAW peut
NET_RAW capacité NET_RAW dans les conteneurs pour vous protéger contre certains types d'attaques d'usurpation d'identité.
8. Travail sur la sécurité des nœuds
Pour améliorer la sécurité de l'hôte, vous pouvez suivre ces étapes:
- Assurez-vous que l'hôte est correctement et correctement configuré . Une façon est CIS Benchmarks ; De nombreux produits ont un vérificateur autochtone qui vérifie automatiquement la conformité du système avec ces normes.
- Surveillez la disponibilité du réseau des ports importants . Assurez-vous que votre réseau bloque l'accès aux ports utilisés par kubelet, notamment 10250 et 10255. Envisagez de restreindre l'accès au serveur API Kubernetes - sauf pour les réseaux approuvés. Dans les clusters qui ne nécessitaient pas d'authentification et d'autorisation dans l'API kubelet, les attaquants ont utilisé l'accès à ces ports pour lancer des mineurs de crypto-monnaie.
- Minimisez l'accès administratif aux hôtes Kubernetes . L'accès aux nœuds de cluster doit en principe être limité: pour déboguer et résoudre d'autres problèmes, en règle générale, vous pouvez vous passer de l'accès direct au nœud.
9. Activer la journalisation d'audit
Assurez-vous que
les journaux d'audit sont activés et que vous surveillez l'occurrence d'appels d'API inhabituels ou indésirables, en particulier dans le contexte d'éventuels échecs d'autorisation - ces entrées auront un message avec le statut «Interdit». Les échecs d'autorisation peuvent signifier qu'un attaquant tente de tirer parti des informations d'identification obtenues.
Les fournisseurs de solutions gérées (y compris GKE) donnent accès à ces données dans leurs interfaces et peuvent vous aider à configurer des notifications en cas d'échec d'autorisation.
Tourné vers l'avenir
Suivez ces instructions pour un cluster Kubernetes plus sécurisé. N'oubliez pas que même après la configuration sécurisée du cluster, vous devez garantir la sécurité dans les autres aspects de la configuration et du fonctionnement des conteneurs. Pour améliorer la sécurité de la pile technologique, explorez les outils qui fournissent un système central pour gérer les conteneurs déployés, surveiller et protéger en permanence les conteneurs et les applications natives du cloud.
PS du traducteur
Lisez aussi dans notre blog: