Un guide pour gérer la surcharge de politiques dans les systèmes distribués actuels

Je vous mets au défi d'assister à 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 réellement ? »

Lors de la récente KubeCon à Salt Lake City, je me suis retrouvée à sprinter entre deux sessions où la « politique » occupait une place prépondérante dans les titres. Mais pour chaque orateur, le mot signifiait quelque chose de complètement différent.

En tant que personne spécialisée dans les politiques réseau basées sur les étiquettes, je devais souvent rencontrer les conférenciers à l'avance pour leur demander : « Cette session sur les politiques porte-t-elle sur les politiques réseau, les contrôleurs d'admission ou la conformité ? »

Ces échanges révèlent un problème croissant dans les écosystèmes informatiques distribués et natifs du cloud d'aujourd'hui. Le terme « politique » est utilisé si largement qu'il est pratiquement une abstraction en soi.

Pour résoudre ce problème, j'examinerai de plus près les huit types de politiques fréquemment abordés sous ce terme général et leur importance pour comprendre l'infrastructure, la sécurité et l'automatisation des systèmes distribués.

1. Politiques du 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 politiques de réseau utilisez une approche basée sur une liste d'autorisations. 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.

En tant que microservices et applications basées sur des conteneurs deviennent de plus en plus courants, il est encore plus important de contrôler soigneusement la façon dont les services communiquent et de les isoler en cas de besoin.

Par exemple, les politiques 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 complique également à créer et à gérer.

2. Politiques relatives aux contrôleurs 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. Ce sont essentiellement des portiers. 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 :

• Appliquez automatiquement les limites de ressources

• Ajouter des étiquettes aux déploiements

• Empêcher l'utilisation de configurations non sécurisées

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

3. Politiques de l'OPA et de Kyverno

Les politiques de l'OPA et de Kyverno sont-elles simplement des contrôleurs d'admission, ou sont-elles quelque chose de plus ?

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

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

• Kyverno est un moteur de politiques conçu spécifiquement pour Kubernetes. Il s'agit d'un moyen 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 Kubernetes natifs, ce qui facilite la création et l'application de politiques.

Ces outils peuvent contrôler ce qui a accès à un système, mais ils peuvent faire bien plus sur une gamme d'applications et de systèmes. Ils peuvent gérer :

• 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.

• Quotas sont généralement définis 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.

• Limites définissez le plus petit et le plus grand nombre de ressources qu'un conteneur ou un pod peut utiliser. Cela garantit qu'aucune charge de travail n'utilise trop de ressources et ne pose 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 comptant de nombreux utilisateurs ou dans des applications qui évoluent de manière dynamique. Bien que ces politiques contribuent à maintenir la stabilité du système, elles compliquent également les choses car elles interagissent avec d'autres niveaux de politique tels 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 comptant de nombreux utilisateurs ou dans 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)

Politiques de sécurité des pods (PSP) dans Kubernetes définissez les configurations de sécurité au niveau du pod. Cela inclut l'arrêt de l'exécution des conteneurs en tant que root ou la nécessité de certaines fonctionnalités Linux.

Mais les PSP sont progressivement supprimés dans Kubernetes. Ils sont remplacés par de nouvelles options telles que Pod Security Standards (PSS) et des outils externes tels que 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 s'exécuter avec des configurations trop permissives. Bien qu'elles soient utiles, la gestion des PSP ainsi que d'autres politiques peut prêter à confusion. Les nouveaux outils offrent des moyens plus flexibles de renforcer la sécurité, souvent sous le terme général de « politiques de sécurité ».

6. Politiques de maillage de services

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

• Authentifiez et autorisez le trafic : Les maillages de services utilisent le mTLS (Mutual TLS) pour crypter les communications entre les services. Ils vous permettent également de définir des politiques selon lesquelles les services peuvent communiquer entre eux, ajoutant ainsi un niveau supplémentaire de contrôle d'accès.

• Gérez le trafic : Les politiques de maillage de services contrôlent le routage, l'équilibrage de charge et le basculement. Cela facilite les tâches telles que les tests A/B, les versions Canary ou l'acheminement du trafic vers différentes versions de service.

Contrairement aux politiques réseau, les politiques de maillage de services fonctionnent au niveau de la couche applicative et ont une incidence sur la manière dont les services interagissent. Ces politiques sont essentielles pour gérer le trafic de service à service. Mais elles peuvent parfois prêter à confusion car elles recoupent les politiques du réseau.

7. Politiques de conformité

Politiques de conformité peut 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 de conformité internes, telles que le RGPD, la HIPAA ou le SOC 2. Ces politiques peuvent jouer un rôle majeur dans de nombreuses parties d'un système, affectant la sécurité, la journalisation et le stockage des données.

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

Les politiques de conformité sont particulièrement importantes dans les secteurs soumis à des réglementations strictes, comme la santé et la finance. Comme elles concernent de nombreuses parties d'un système et recoupent souvent les politiques de sécurité, leur gestion peut devenir complexe. Malgré cela, ils sont essentiels pour garantir la sécurité, l'organisation et la conformité des systèmes.

8. Politiques d'automatisation et de cycle de vie

Les politiques d'automatisation contrôlent quand et comment les ressources d'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 de ressources sont écrites sous forme de code et gérées via des pipelines CI/CD.

Par exemple, les politiques 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 builds, exécuter des tests et gérer les déploiements. Cela permet de créer des environnements autogérés qui peuvent s'adapter à l'évolution de la 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 cloud natifs. Mais elles interagissent étroitement avec d'autres politiques, telles que celles relatives à la gestion des ressources et au contrôle des admissions, ce qui peut ajouter de la complexité.

Tu me suis toujours ? Le chevauchement des « politiques » se poursuit...

Si vous n'êtes pas encore dépassé, voici le rebondissement. De nombreuses organisations disposent désormais de politiques en matière de politiques.

C'est ce que l'on appelle des « méta-politiques ». Ils font office de garde-fous et fixent des règles indiquant qui peut élaborer, gérer ou appliquer d'autres politiques.

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

Dans les grands systèmes, Politiques du RBAC car les politiques sont essentielles. Ils s'assurent que seuls des administrateurs ou des équipes spécifiques peuvent modifier les politiques. En appliquant des contrôles RBAC stricts, ces « politiques pour les politiques » garantissent que les autres politiques n'ont pas une portée excessive ou n'interfèrent pas avec les infrastructures critiques.

Réflexions finales : Une feuille de route pour surmonter la surcharge de politiques

À mesure que les environnements cloud natifs et distribués se développent, la notion de « politique » continuera d'évoluer. Ils deviendront plus compliqués, 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 qui définit chaque type de stratégie et de faire bon usage des outils de stratégie.

Et la prochaine fois que vous assisterez à une conférence technique et que vous entendrez « politique », prenez un moment pour demander : « Laquelle ? ! » Cela pourrait vous éviter bien des confusions, voire même un sprint inter-hall !

Contactez-nous dès aujourd'hui pour découvrir comment Illumio peut simplifier les politiques de sécurité de votre réseau dans les environnements de cloud, de terminaux et de centres de données.