Service Mesh (ASM) propose des solutions flexibles et efficaces pour la gestion du trafic sortant, garantissant la sécurité, l'observabilité et la fiabilité de vos applications. Cette rubrique décrit les fonctionnalités de gestion du trafic sortant d'ASM ainsi que les avantages liés à l'utilisation d'une passerelle de sortie ASM.
Fonctionnalités avancées de gestion du trafic sortant
ASM offre un ensemble complet de fonctionnalités pour la gestion du trafic sortant de niveau 7, couvrant le routage du trafic, l'observabilité et la sécurité. Configurez ces fonctionnalités selon vos besoins.
Si une application initie directement une requête HTTPS, le proxy sidecar associé ne peut traiter cette requête que comme un trafic TLS standard ; les fonctionnalités de niveau 7 d'ASM n'entrent alors pas en jeu. Assurez-vous donc que les requêtes envoyées par votre application sont au format HTTP en clair. ASM transfère directement ces requêtes HTTP vers les services externes ou les convertit automatiquement en requêtes HTTPS avant de les envoyer, selon votre configuration.
Routage du trafic
Pour accéder aux services HTTP situés en dehors d'un cluster, configurez les entrées de service correspondantes dans le maillage de services. Cela vous permet d'utiliser des fonctionnalités avancées via les services virtuels, telles que la mise en miroir du trafic sortante et le routage du trafic sortant par ratio. Si vous accédez à un service utilisant le protocole HTTPS, configurez également une DestinationRule. La fonctionnalité de routage du trafic ne nécessite pas de passerelle de sortie ASM.
Observation du trafic sortant
Pour les requêtes en clair, observez le trafic sortant à l'aide des journaux, des métriques et de l'analyse de tracing sans configuration supplémentaire. Si le trafic doit être chiffré, il suffit de configurer une entrée de service et une DestinationRule. Lorsqu'une application émet une requête en clair, le sidecar chiffre automatiquement le trafic avant de le transférer. Cette approche vous permet de tirer pleinement parti des capacités d'observabilité du maillage. Cette fonctionnalité ne nécessite pas de passerelle de sortie ASM.
Authentification et autorisation du trafic sortant
ASM fournit également des capacités robustes d'authentification et d'autorisation pour le trafic sortant. Implémentez des fonctionnalités de sécurité avancées dans ASM, telles que la vérification des jetons JSON Web Tokens (JWT) du trafic sortant et la restriction de l'accès depuis des clients spécifiques en fonction des métadonnées de requête de niveau 7 ou 4. Ces fonctionnalités nécessitent une passerelle de sortie ASM. Pour plus d'informations, consultez la section Modèles de sécurité pour le trafic sortant.
Modèles de sécurité pour le trafic sortant
Pour le trafic TCP pur (ni HTTP ni TLS), utilisez les politiques réseau natives de Kubernetes pour renforcer la sécurité.
Action par défaut
L'action par défaut est ALLOW_ANY, ce qui signifie que le proxy sidecar n'impose aucune restriction sur le trafic sortant. Dans ce cas, le comportement du trafic sortant est totalement non contrôlé. Le niveau de sécurité est minimal.
REGISTRY_ONLY
Si vous activez REGISTRY_ONLY, les applications ne peuvent accéder qu'aux services enregistrés via des entrées de service.
Étant donné que les propriétaires d'applications disposent des autorisations nécessaires pour modifier les configurations des pods d'application, ils peuvent utiliser diverses méthodes pour contourner le proxy sidecar. Si une requête contourne le proxy sidecar, les restrictions d'accès de REGISTRY_ONLY deviennent inefficaces et l'application peut accéder aux services externes sans limitation. Par conséquent, REGISTRY_ONLY n'est pas considéré comme une politique de sécurité valide.
De plus, cette solution ne peut restreindre l'accès aux services externes que pour les charges de travail situées dans un namespace spécifié. Elle ne permet pas un contrôle granulaire pour des charges de travail spécifiques.
REGISTRY_ONLY et passerelle de sortie
La passerelle de sortie constitue une limite de sécurité idéale. Déployée séparément, elle est entièrement contrôlée par l'administrateur du maillage. Le propriétaire de l'application ne peut pas contrôler directement la passerelle de sortie ni ses politiques de sécurité.
Par ailleurs, assurez-vous que seuls les nœuds sur lesquels la passerelle de sortie est déployée peuvent accéder aux services externes, tandis que les autres nœuds en sont exclus. Les pods d'application ne peuvent pas accéder directement à Internet. Pour envoyer avec succès du trafic vers un service externe, le propriétaire de l'application doit s'assurer que le trafic sortant de l'application est traité par le proxy sidecar, puis transféré vers la passerelle de sortie.
Une fois le trafic transféré de manière transparente vers la passerelle de sortie :
Configurez des politiques d'autorisation sur la passerelle de sortie pour mettre en œuvre une autorisation fine-grained ou appliquer une autorisation personnalisée.
Si le service auquel vous souhaitez accéder utilise HTTPS, configurez une mise à niveau HTTP vers HTTPS sur la passerelle de sortie. Celle-ci gère automatiquement les connexions HTTPS. Elle peut multiplexer les connexions HTTPS entre différentes charges de travail afin d'améliorer les performances.
Utilisation avec Cloud Firewall
Lorsque vous utilisez Cloud Firewall pour restreindre strictement le trafic sortant d'un VPC ou d'une passerelle NAT, attribuez une plage d'adresses IP fixe et prévisible aux pods de la passerelle de sortie ASM, puis ajoutez cette plage à la liste d'autorisation de la politique de pare-feu.
Pour y parvenir, assurez-vous que les pods de la passerelle de sortie utilisent un segment d'adresses IP indépendant et exclusif. Dans un cluster ACK Alibaba Cloud, utilisez l'une des deux méthodes suivantes :
-
Utilisez Terway Container Network Interface (CNI) pour attribuer des adresses IP fixes aux pods (recommandé).
Si votre cluster ACK utilise le mode réseau Terway, exploitez ses fonctionnalités natives pour attribuer des adresses IP fixes aux pods de la passerelle de sortie et les associer à un vSwitch et à un groupe de sécurité indépendants. Il s'agit de la solution la plus directe et concise. Pour plus d'informations, consultez la section Configurer une adresse IP statique, un vSwitch dédié et un groupe de sécurité pour un pod.
-
Utilisez le réseau hôte (HostNetwork) pour attribuer indirectement des adresses IP fixes aux pods.
Si vous ne pouvez pas utiliser la première méthode, suivez les étapes ci-dessous pour attribuer indirectement l'adresse IP du nœud au pod de la passerelle de sortie :
Créez un pool de nœuds exclusif : Créez un pool de nœuds dédié à la passerelle de sortie. Assurez-vous que la plage d'adresses IP de ce pool ne chevauche pas celles des autres pods d'application du cluster. Pour plus d'informations, consultez la section Créer et gérer un pool de nœuds.
Ajoutez des taints aux nœuds : Appliquez des taints à tous les nœuds de ce pool pour empêcher la planification d'autres pods sur ceux-ci.
-
Configurez la passerelle de sortie : Modifiez la configuration de déploiement de la passerelle de sortie pour :
Activer le mode réseau hôte (
hostNetwork: true).Ajouter les tolérations correspondantes afin de faire correspondre les taints du pool de nœuds dédié.
Configurer l'affinité pour garantir que les pods soient planifiés sur ce pool de nœuds exclusif.
Une fois ces configurations effectuées, le pod de la passerelle de sortie utilise l'adresse IP de son nœud comme adresse IP de sortie. Vous pouvez ensuite ajouter le segment d'adresses IP du pool de nœuds exclusif à la liste d'autorisation de Cloud Firewall.
Références
Utilisez les politiques de trafic sortant fournies par ASM pour configurer rapidement des règles de trafic permettant d'utiliser une passerelle de sortie pour accéder aux services situés en dehors d'un cluster. Pour plus d'informations, consultez la section Gérer le trafic sortant avec ASMEgressTrafficPolicy.