Dans les environnements où l'on souhaite un niveau élevé de sécurité pour les clusters Kubernetes, il est désormais courant d'appliquer des principes issus de l'initiative Réseau à confiance zéro . Pour la mise en réseau dans un cluster Kubernetes, cela signifie généralement :
- Cryptage de tout le trafic réseau
- Utiliser l'authentification pour tout le trafic réseau
- Règles de pare-feu granulaires - appliquées pour une micro segmentation autour de chaque application.
- Contrôle d'accès à moindre privilège à l'aide de RBAC, comptes de service, JWT et OpenPolicyAgent.
Les deux premiers points sont maintenant généralement résolus avec un produit de Service Mesh, tel que Linkerd , Istio et les fournisseurs de nuages offrent des solutions gérées comme AWS App Mesh . Ces produits appliquent le cryptage entre chaque Pod sous la forme de TLS, mais aussi l'authentification à l'aide de certificats clients et le TLS mutuel, mTLS de manière automatisée. Le Service Mesh dispose généralement d'un plan de contrôle partie qui est responsable, par exemple, de la rotation des certificats avec l'automatisation.
Le troisième point est généralement réalisé en utilisant Politiques de réseau Kubernetes pour obtenir des règles de pare-feu dynamiques mais granulaires appliquées à chaque instance d'application (Pod), même si elle peut être programmée dynamiquement sur différents nœuds du cluster. Ces règles sont généralement déclarées à un niveau supérieur en utilisant, par exemple, des étiquettes de Pod au lieu d'adresses IP codées en dur.
Je me demande, maintenant qu'un trafic sécurisé a "déjà atteint" le pod, si un conteneur doit également utiliser TLS, ou s'il est suffisamment sûr de communiquer avec le sidecar sans TLS ? J'aimerais connaître l'aspect sécurité entre le conteneur et son sidecar. Un sidecar doit-il être traité comme un conteneur autonome et donc la communication avec un conteneur doit également être sécurisée par TLS ?
Gousses sont les unités de programmation dans Kubernetes, ce sont des conteneurs étroitement couplés - toujours programmés ensemble. Les conteneurs d'un Pod partagent certaines ressources comme les espaces de noms linux, les volumes du système de fichiers et les cgroups :
Le contexte partagé d'un Pod est un ensemble d'espaces de noms Linux, de cgroups, et potentiellement d'autres facettes de l'isolation.
En outre, les conteneurs d'un Pod partagent l'identité réseau, l'adresse IP, et utilisent localhost pour communiquer au sein du Pod. J'envisagerais la confiance au sein du Pod, mais vous devriez appliquer des règles granulaires de sécurité. Politiques de réseau Kubernetes pour verrouiller, par exemple, les ports sur lesquels le Pod peut recevoir du trafic, et de quels Pods.
