Un guide pour naviguer dans la surcharge de politiques des systèmes distribués d'aujourd'hui

Je vous mets au défi de participer à la KubeCon et d'assister à une session sur la "politique". Une fois sur place, ne soyez pas surpris si vous vous demandez : "De quel type de politique s'agit-il en réalité ?".

Lors de la récente conférence KubeCon à Salt Lake City, je me suis retrouvé à sprinter entre les sessions où le mot "politique" figurait en bonne place dans les titres. Mais pour chacun d'entre eux, ce mot avait une signification totalement différente.

En tant que spécialiste des politiques de réseau basées sur les étiquettes, j'ai souvent dû demander à l'avance aux orateurs : "Cette session porte-t-elle sur les politiques de réseau, sur les contrôleurs d'admission ou sur la conformité ?

Ces échanges révèlent un problème croissant dans les écosystèmes informatiques distribués et natifs de l'informatique en nuage d'aujourd'hui. Le terme "politique" est utilisé de manière si large qu'il est pratiquement une abstraction en soi.

Pour démêler tout cela, je vais examiner de plus près les huit différents types de politiques fréquemment évoqués sous ce terme général et expliquer pourquoi ils sont essentiels pour comprendre l'infrastructure, la sécurité et l'automatisation des systèmes distribués.

1. Politiques de réseau

Les politiques réseau sont importantes pour contrôler et gérer la façon dont les systèmes d'un réseau communiquent entre eux, en particulier dans des environnements tels que Kubernetes.

La plupart des politiques de réseau utilisent une approche de liste d'autorisation. Cela signifie que les connexions sont bloquées par défaut, à moins qu'elles ne soient spécifiquement autorisées par la politique. Ces politiques peuvent utiliser des règles basées sur des adresses IP ou des étiquettes pour décider quelles ressources peuvent communiquer.

À mesure que les microservices et les applications basées sur des conteneurs se généralisent, il est encore plus important de contrôler soigneusement la façon dont les services communiquent et de les isoler lorsque cela est nécessaire.

Par exemple, les politiques de réseau de Kubernetes sont hautement personnalisables. Ils peuvent définir des règles de circulation pour le trafic interne (est-ouest) et le trafic externe (nord-sud). Cette flexibilité en fait des outils puissants pour assurer la sécurité des systèmes, mais elle les rend également plus compliqués à construire et à gérer.

2. Politiques du contrôleur d'admission

Les contrôleurs d'admission sont des politiques spécialisées dans Kubernetes. Ils évaluent les demandes d'API pour décider si elles doivent être autorisées ou modifiées. Ils sont essentiellement des gardiens. Ils appliquent certaines normes ou pratiques de sécurité au sein du cluster avant qu'une demande d'API ne puisse être traitée.

Par exemple, les politiques des contrôleurs d'admission peuvent :

• Appliquer automatiquement les limites de ressources

• Ajouter des étiquettes aux déploiements

• Empêcher l'utilisation de configurations dangereuses

Ces types de politiques peuvent intercepter et modifier les demandes. Ils sont donc essentiels pour maintenir une sécurité cohérente au sein des clusters. Mais elles ne concernent que les politiques dans le cycle de vie des appels d'API de Kubernetes.  

3. Politiques de l'OPA et de Kyverno

Les politiques OPA et Kyverno sont-elles de simples contrôleurs d'admission ou sont-elles plus que cela ?

Open Policy Agent (OPA) et Kyverno offrent plus que les contrôleurs d'admission traditionnels. Alors qu'ils fonctionnent souvent comme des contrôleurs d'admission dans Kubernetes, ils introduisent un langage de politique plus flexible et plus complet. Cela permet aux organisations de définir et d'appliquer des règles complexes dans plusieurs systèmes.

• OPA (Open Policy Agent) est un moteur de politique polyvalent qui peut être utilisé dans différents environnements. Il utilise un langage appelé Rego qui peut gérer des exigences politiques complexes. Outre Kubernetes, OPA peut gérer des politiques pour les pipelines CI/CD, les microservices et même les ressources cloud.

• Kyverno est un moteur de politiques conçu spécifiquement pour Kubernetes. Il s'agit d'une manière plus simple de définir des politiques en YAML. De nombreuses personnes le préfèrent pour configurer Kubernetes. Il fonctionne bien avec les objets natifs de Kubernetes, ce qui facilite la construction et l'application de politiques.

Ces outils permettent de contrôler l'accès à un système, mais ils peuvent faire beaucoup plus pour toute une série d'applications et de systèmes. Ils peuvent se débrouiller :

• Gestion du cycle de vie

• Validation

• Contrôles de conformité personnalisés

4. Quotas de ressources et politiques de limitation

Les politiques de gestion des ressources permettent de contrôler la quantité de CPU, de mémoire et de stockage qu'un cluster Kubernetes peut utiliser. Ces politiques sont importantes dans les environnements partagés car elles empêchent une application ou un utilisateur d'utiliser trop de ressources.

• Des quotas sont généralement fixés pour chaque espace de noms. Ils limitent la quantité totale de ressources qu'un espace de noms peut utiliser afin qu'aucun espace de noms ne prenne trop de place.

• Les limites définissent le plus petit et le plus grand nombre de ressources qu'un conteneur ou un module peut utiliser. Cela permet de s'assurer qu'aucune charge de travail n'utilise trop de ressources et ne cause de problèmes au reste du système.

Grâce à ces politiques, les administrateurs peuvent équilibrer les ressources, ce qui est particulièrement important dans les environnements avec de nombreux utilisateurs ou des applications qui évoluent de manière dynamique. Si ces politiques contribuent à la stabilité du système, elles compliquent également les choses en interagissant avec d'autres couches de politiques telles que l'automatisation et les contrôles d'admission.

Ces politiques aident les administrateurs à équilibrer les ressources, ce qui est particulièrement important dans les systèmes avec beaucoup d'utilisateurs ou les applications qui évoluent de manière dynamique. Cependant, la gestion de ces politiques peut s'avérer difficile. Elles se chevauchent souvent avec d'autres politiques telles que l'automatisation et les contrôles d'admission.

5. Politiques de sécurité des pods (PSP)

Les politiques de sécurité des pods (PSP) dans Kubernetes définissent les configurations de sécurité au niveau des pods. Il s'agit notamment d'empêcher les conteneurs de fonctionner en tant que root ou d'exiger certaines capacités Linux.  

Mais les PSP sont progressivement abandonnés dans Kubernetes. Ils sont remplacés par de nouvelles options telles que les normes de sécurité des pods (PSS) et des outils externes comme OPA et Kyverno.

Les PSP ont été conçus pour ajouter des paramètres de sécurité granulaires qui empêchent les charges de travail de fonctionner avec des configurations trop permissives. Bien qu'utiles, la gestion des PSP avec d'autres politiques peut s'avérer confuse. Des outils plus récents offrent des moyens plus souples d'appliquer la sécurité, souvent sous le terme général de "security policies."

6. Politiques de maillage des services

Dans les environnements microservices, les maillages de services comme Istio ou Linkerd ajoutent une autre couche de politique qui sécurise et surveille la communication entre les services. Ces politiques sont souvent.. :  

• Authentifier et autoriser le trafic : Les mailles de services utilisent mTLS (mutual TLS) pour chiffrer la communication entre les services. Ils vous permettent également de définir des règles concernant les services qui peuvent communiquer entre eux, ajoutant ainsi une autre couche de contrôle d'accès.

• Gérer le trafic : Les politiques de maillage des services contrôlent le routage, l'équilibrage des charges et le basculement. Il est ainsi plus facile de procéder à des tests A/B, à des mises à jour canari ou d'acheminer le trafic vers différentes versions du service.  

Contrairement aux politiques de réseau, les politiques de maillage de services agissent au niveau de la couche d'application, affectant la manière dont les services interagissent. Ces politiques sont cruciales pour la gestion du trafic de service à service. Mais elles peuvent parfois prêter à confusion parce qu'elles se chevauchent avec les politiques du réseau.

7. Politiques de conformité

Les politiques de conformité peuvent couvrir la gestion des données, l'accès et les normes opérationnelles afin de garantir que les systèmes répondent aux exigences légales ou internes de conformité, telles que GDPR, HIPAA ou SOC 2. Ces politiques peuvent jouer un rôle majeur dans de nombreuses parties d'un système, en affectant la sécurité, la journalisation et le stockage des données.

Par exemple, une politique de conformité peut exiger que les données ne soient stockées qu'à des endroits spécifiques (résidence des données) ou que les journaux d'audit soient conservés pendant un certain temps. Dans Kubernetes, des outils comme OPA et Kyverno sont souvent utilisés pour appliquer ces politiques en surveillant et en auditant continuellement les systèmes en temps réel pour s'assurer qu'ils respectent les normes.

Les politiques de conformité sont particulièrement importantes dans les secteurs soumis à des réglementations strictes, comme les soins de santé et la finance. Parce qu'ils interviennent dans de nombreuses parties d'un système et qu'ils empiètent souvent sur les politiques de sécurité, leur gestion peut s'avérer complexe. Malgré cela, ils sont essentiels pour garantir la sécurité, l'organisation et la conformité des systèmes.

8. Automatisation et politiques de cycle de vie

Les politiques d'automatisation contrôlent quand et comment les ressources de l'infrastructure sont créées, mises à jour ou supprimées. Ces politiques constituent une partie importante de l'infrastructure en tant que code (IaC), où les configurations des ressources sont écrites en tant que code et gérées par des pipelines CI/CD.

Par exemple, les stratégies d'automatisation peuvent gérer des tâches telles que la mise à l'échelle automatique des ressources, le nettoyage des ressources inutilisées ou la gestion des étapes du cycle de vie d'un déploiement. Ils peuvent également s'intégrer aux pipelines CI/CD pour déclencher des constructions, exécuter des tests et gérer les déploiements. Cela permet de créer des environnements autogérés qui peuvent s'adapter aux changements de charge de travail en temps réel.

Les politiques d'automatisation peuvent simplifier la gestion des ressources et garantir les meilleures pratiques dans les environnements natifs du cloud. Mais elles interagissent étroitement avec d'autres politiques, comme celles relatives à la gestion des ressources et au contrôle des admissions, ce qui peut ajouter à la complexité.

Vous suivez toujours ? Le chevauchement des "politiques" se poursuit...

Si vous ne vous sentez pas encore dépassé, voici ce qu'il en est. De nombreuses organisations disposent désormais de politiques en la matière.  

C'est ce qu'on appelle les "métapolitiques". Elles servent de garde-fous en fixant des règles pour déterminer qui peut élaborer, gérer ou appliquer d'autres politiques.  

Par exemple, une métapolitique peut décider quelles équipes peuvent créer des politiques de réseau spécifiques ou qui est autorisé à créer des politiques de contrôle d'admission. Ces politiques reposent souvent sur un contrôle d'accès basé sur les rôles (RBAC).

Dans les grands systèmes, les politiques RBAC sont essentielles. Ils veillent à ce que seuls des administrateurs ou des équipes spécifiques puissent modifier les politiques. En appliquant des contrôles RBAC stricts, ces "politiques pour les politiques" garantissent que les autres politiques n'outrepassent pas les limites et n'interfèrent pas avec l'infrastructure critique.

Dernières réflexions : Une feuille de route pour faire face à la surcharge politique

Au fur et à mesure que les environnements cloud-native et distribués se développent, l'idée de la politique "" continuera d'évoluer. Ils deviendront plus compliqués, plus spécialisés et parfois même contradictoires.

Pour éviter une surcharge de politiques, il est important d'utiliser des conventions de dénomination claires, de créer une documentation définissant chaque type de politique et d'utiliser à bon escient les outils de gestion des politiques.

La prochaine fois que vous assisterez à une conférence technique et que vous entendrez parler de "politique," prenez le temps de demander : "Laquelle ?!" Cela pourrait vous éviter beaucoup de confusion - ou même un sprint à travers la salle !

Communiquez avec nous dès aujourd'hui pour savoir comment Illumio peut simplifier vos politiques de sécurité réseau dans les environnements d'informatique en nuage, de points d'extrémité et de centres de données.