Comment concevoir l’architecture Kubernetes la plus sécurisée ?
Les environnements Kubernetes peuvent se présenter sous différentes formes et tailles. Et certains sont intrinsèquement plus sécurisés que d’autres.
En d’autres termes, l’architecture Kubernetes (c’est-à-dire la stratégie architecturale que vous choisissez lors de la conception de votre environnement Kubernetes) peut avoir des répercussions importantes sur la sécurité globale. Un environnement multiclusters peut être plus sécurisé à certains égards qu’un environnement qui exécute tout dans un seul et unique cluster (même si plus il y a de clusters, plus le système est complexe, ce qui est un inconvénient du point de vue de la sécurité). De même, les outils tiers, comme les agents de surveillance et les services mesh, que vous pouvez choisir d’intégrer à votre architecture Kubernetes, ont un impact sur la sécurité.
Par conséquent, quels sont les types de stratégies architecturales à privilégier pour une sécurité optimale de Kubernetes ? Cet article apporte une réponse à cette question en présentant les choix de conception de haut niveau que les administrateurs sont généralement amenés à faire lors de la planification d’un environnement Kubernetes. Vous découvrirez également ce que chaque élément signifie du point de vue de la sécurité.
Comparaison entre un service Kubernetes géré et un service Kubernetes auto-géré
La première question que la plupart des équipes se posent probablement aujourd’hui lors de la planification d’une installation de Kubernetes est probablement de savoir si elles doivent utiliser un service Kubernetes géré (comme Amazon AKS, Azure Kubernetes Service ou une autre plate-forme Kubernetes qui fonctionne dans un cloud public) ou déployer et gérer Kubernetes elles-mêmes sur une infrastructure qu’elles contrôlent.
Un service Kubernetes géré est la plupart du temps plus facile à configurer et à tenir à jour, car le fournisseur Kubernetes assure au moins une partie des tâches d’approvisionnement et de maintenance nécessaires au bon fonctionnement des clusters. (Remarque : l’étendue des fonctions de gestion que les fournisseurs proposent peut varier considérablement d’un service Kubernetes « géré » à un autre, mais nous nous éloignons du sujet).
Un service Kubernetes géré peut également être plus sécurisé pour deux raisons principales :
- L’infrastructure hôte fait l’objet d’une gestion et d’une surveillance professionnelles pour détecter les menaces en matière de sécurité. En d’autres termes, avec un service Kubernetes géré, vous avez moins à vous soucier des problèmes de sécurité au niveau de l’OS sur vos nœuds.
- Votre fournisseur de service Kubernetes géré peut fournir des paramètres ou des outils préconfigurés qui (dans la plupart des cas) respectent les meilleures pratiques en matière de sécurité.
D’autre part, l’architecture Kubernetes gérée implique l’utilisation d’outils et, bien souvent, d’une infrastructure appartenant au fournisseur. Du point de vue de la sécurité, cela a un inconvénient : il faut restreindre le niveau de contrôle et de confidentialité dont disposent les utilisateurs. Vous ne pouvez pas utiliser un service Kubernetes géré si vous souhaitez « ventiler » vos clusters depuis Internet, par exemple. De plus, bien que certains types de plates-formes Kubernetes gérées (comme Platform9) soient compatibles avec une infrastructure on-premises, la plupart nécessitent l’utilisation d’une infrastructure hébergée dans le cloud public, qui est donc plus souvent exposée à des menaces de sécurité.
En résumé, si ne connaissez pas bien Kubernetes ni les principes de sécurité de Kubernetes, un service Kubernetes géré vous permettra probablement de bénéficier d’un environnement plus sécurisé que celui que vous mettriez en place vous-même. Cependant, si vous avez besoin d’une architecture de sécurité avancée comprenant des fonctions telles que la « ventilation », vous devrez configurer et gérer vous-même votre environnement.
Comparaison entre une architecture Kubernetes à un cluster et une architecture Kubernetes multiclusters
Concernant l’architecture, il y a une autre décision importante que vous devrez prendre lors de la planification d’une installation Kubernetes : savoir s’il faut mettre en place un seul ou plusieurs clusters.
Presque toutes les équipes n’utilisaient habituellement qu’un seul cluster. À présent, les environnements multiclusters deviennent de plus en plus populaires selon la CNCF, notamment parce qu’ils permettent d’atteindre un haut degré d’isolement entre les workloads. Vous pouvez déployer différents workloads dans différents clusters, ce qui réduit considérablement le risque de voir un problème de sécurité dans un workload se propager aux autres. En savoir plus sur la sécurisation de clusters Kubernetes.
Ceci étant, les équipes doivent bien mettre dans la balance cet avantage en matière de sécurité et le principal inconvénient d’une architecture Kubernetes multiclusters : une complexité accrue. Plus de clusters signifie plus de journaux d’audit à suivre, plus de politiques RBAC à créer, à appliquer et à surveiller, plus de réseaux à configurer et à isoler et ainsi de suite.
Si vous avez mis en place de fortes automatisations pour la gestion et la surveillance de vos clusters, cette complexité supplémentaire peut ne pas être un problème. Dans ce cas, vous pouvez opter pour une architecture multiclusters. Toutefois, si vous n’arrivez pas à effectuer un suivi complet avec ce type de configuration, contentez-vous d’un seul cluster. Il vous sera alors plus facile de gérer des tâches comme la détection des événements de sécurité et la garantie que les politiques RBAC sont bien à jour.
Comparaison entre un namespace unique et plusieurs namespaces
Même si vous n’exécutez pas plusieurs clusters, vous pouvez bénéficier d’un isolement assez fort des workloads en créant plusieurs namespaces. Les namespaces sont principalement des clusters virtuels qui sont hébergés dans le même cluster physique.
En général, vous voudrez créer un namespace différent pour chaque application que vous exécutez au sein de Kubernetes. Vous devez également créer des namespaces différents pour la partie développement/test et la partie production.
N’oubliez pas cependant que l’isolement fourni par les namespaces est limité. Toutes les autorisations que vous attribuez par le biais de ClusterRoles seront appliquées à tous les namespaces. En ce sens, le fait d’avoir plusieurs namespaces est intéressant uniquement si vous créez des politiques RBAC qui vous permettent d’isoler les utilisateurs et les comptes au sein de chaque namespace. Pour ce faire, attribuez des autorisations en utilisant des rôles plutôt que des ClusterRoles lorsque c’est possible.
Services mesh
Les services mesh, qui gèrent la découverte de services et la connectivité pour les ressources exécutées au sein d’un cluster Kubernetes, sont un outil essentiel pour tout environnement Kubernetes qui comporte bien plus que quelques services.
Les services mesh sont un rempart supplémentaire pour la sécurité de votre architecture Kubernetes. Ils aident à gérer la connectivité, mais la plupart des services mesh offrent également des fonctions de surveillance et d’alerte qui peuvent vous aider à détecter des menaces sur le plan de la sécurité. Kubernetes en soit n’enregistre pas les incidents de sécurité liés au réseau (les événements d’audit de Kubernetes ne couvrent pas le réseau, mais uniquement l’API). Les services mesh viennent alors combler cette grosse lacune en matière de sécurité concernant la visibilité.
L’inconvénient des services mesh est qu’ils augmentent la surface d’attaque globale et la complexité de Kubernetes. Si une personne mal intentionnée parvient à pénétrer dans votre service mesh, elle peut l’utiliser comme point de départ pour pénétrer dans l’ensemble de votre cluster (ou de vos clusters).
Ceci étant, si vous déployez des services mesh de façon sécurisée, vous pouvez diminuer les risques associés. Si vous déployez vos logiciels de services mesh via des containers sidecar qui s’exécutent en parallèle à vos pods d’application, veillez à isoler les sidecars et à verrouiller leur accès à l’aide de RBAC et de stratégies réseau.
Logiciels de surveillance et de sécurité externes
En plus des services mesh, les équipes déploient souvent des logiciels tiers de surveillance des performances et de la sécurité pour les aider à gérer leurs clusters.
Ces outils augmentent également votre surface d’attaque. Mais tant que vous les déployez de façon sécurisée, les avantages l’emportent nettement sur les risques.
Vous pouvez optimiser la sécurité des outils externes en suivant des pratiques comme celles-ci :
- Comme indiqué ci-dessus, appliquez le principe du moindre privilège pour les agents qui s’exécutent en tant que containers sidecar.
- Dans la mesure du possible, utilisez des webhooks pour transmettre des données de Kubernetes à des outils externes. Ainsi, vous évitez d’avoir à exécuter les outils directement dans votre cluster, car cela vous exposerait à un plus grand risque de sécurité que si vous les exécutiez de façon isolée.
- Veillez à sécuriser toutes les données que les outils externes génèrent ou stockent de manière persistante. Des informations comme celles que l’on trouve dans les journaux d’audit de Kubernetes pourraient potentiellement aider des personnes mal intentionnées à accéder à votre cluster. Il est donc important de faire attention à la façon dont vous gérez ces données.
Comment concevoir l’architecture Kubernetes la plus sécurisée ?
En définitive, il n’existe pas d’approche unique pour concevoir une architecture Kubernetes sécurisée. Les décisions que vous prenez concernant votre architecture sont généralement le reflet de l’échelle de votre environnement, des types de workloads que vous y exécutez et du nombre d’utilisateurs ou d’équipes différents qui partagent l’environnement. Les petits environnements ont tendance à être plus simples dans leur conception et à nécessiter moins d’outils externes, ce qui se traduit par une posture de sécurité plus forte par défaut.
Il est à noter cependant que les environnements complexes, c’est-à-dire ceux qui impliquent plusieurs clusters et une variété d’intégrations tierces, peuvent être tout autant sécurisés que les configurations architecturales simples.
C’est pourquoi la clé de la conception d’un environnement Kubernetes sécurisé ne consiste pas à éviter un certain type de configuration ni à s’assurer que vous incluez ou non tel ou tel outil. Il est surtout nécessaire de veiller à ce que, chaque fois que vous ajoutez de la complexité à l’architecture Kubernetes, vous identifiez et traitiez les répercussions de votre décision en matière de sécurité.