Sécurité du Service Mesh
Qu'est-ce que Sécurité du Service Mesh ?
Sécurité du Service MeshEnsemble de contrôles d'identité, de chiffrement et d'autorisation qu'un service mesh fournit pour sécuriser le trafic service-à-service en environnement cloud-native.
La sécurité du service mesh est le modèle proposé par les maillages comme Istio, Linkerd, Consul ou Cilium Service Mesh. Il déploie un proxy sidecar ou de nœud à côté de chaque workload pour appliquer mTLS entre services, rotation automatique de certificats, autorisation fine (allow/deny par identité source, chemin, méthode, claims JWT) et observabilité du trafic. Le mesh déplace la confiance de la localisation réseau vers l'identité de la charge, supportant les architectures zero-trust dans Kubernetes et les environnements multi-clusters. Les risques comprennent les mauvaises configurations de sidecar, la compromission du control plane, les faiblesses de l'autorité de certification et le contournement du mesh quand l'injection est incomplète. Les défenses incluent un durcissement CIS, la revue de politiques et la surveillance du plan de contrôle.
● Exemples
- 01
AuthorizationPolicy Istio limitant les appels vers payments-service à checkout-service.
- 02
mTLS automatique Linkerd entre tous les pods d'un namespace sans changement applicatif.
● Questions fréquentes
Qu'est-ce que Sécurité du Service Mesh ?
Ensemble de contrôles d'identité, de chiffrement et d'autorisation qu'un service mesh fournit pour sécuriser le trafic service-à-service en environnement cloud-native. Cette notion relève de la catégorie Sécurité du cloud en cybersécurité.
Que signifie Sécurité du Service Mesh ?
Ensemble de contrôles d'identité, de chiffrement et d'autorisation qu'un service mesh fournit pour sécuriser le trafic service-à-service en environnement cloud-native.
Comment fonctionne Sécurité du Service Mesh ?
La sécurité du service mesh est le modèle proposé par les maillages comme Istio, Linkerd, Consul ou Cilium Service Mesh. Il déploie un proxy sidecar ou de nœud à côté de chaque workload pour appliquer mTLS entre services, rotation automatique de certificats, autorisation fine (allow/deny par identité source, chemin, méthode, claims JWT) et observabilité du trafic. Le mesh déplace la confiance de la localisation réseau vers l'identité de la charge, supportant les architectures zero-trust dans Kubernetes et les environnements multi-clusters. Les risques comprennent les mauvaises configurations de sidecar, la compromission du control plane, les faiblesses de l'autorité de certification et le contournement du mesh quand l'injection est incomplète. Les défenses incluent un durcissement CIS, la revue de politiques et la surveillance du plan de contrôle.
Comment se défendre contre Sécurité du Service Mesh ?
Les défenses contre Sécurité du Service Mesh combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.
Quels sont les autres noms de Sécurité du Service Mesh ?
Noms alternatifs courants : Sécurité du mesh, Sécurité du sidecar.
● Termes liés
- cloud-security№ 559
Sécurité Istio
Ensemble des fonctionnalités de sécurité d'Istio : identité de workload via SPIFFE, mTLS automatique et AuthorizationPolicy/RequestAuthentication pour un contrôle d'accès fin.
- network-security№ 1262
Réseau Zero Trust
Architecture qui ne fait jamais confiance par défaut aux utilisateurs, terminaux ou services et impose une vérification continue, basée sur l'identité, de chaque connexion.
- cloud-security№ 1248
Identité de Workload
Identité cryptographique attribuée à un service, un conteneur ou une fonction pour s'authentifier auprès d'autres systèmes sans secrets partagés longue durée.
- cloud-security№ 1078
SPIFFE
Standard ouvert pour attribuer des identités cryptographiques portables aux workloads via des SPIFFE IDs sous forme d'URI et des SVID X.509 ou JWT à courte durée de vie.
- cloud-security№ 600
Sécurité de Kubernetes
Protection d'un cluster Kubernetes — son API server, son plan de contrôle, ses nœuds, ses workloads et son réseau — contre les mauvaises configurations, les compromissions et le mouvement latéral.
● Voir aussi
- № 1079Runtime SPIRE
- № 756OPA (Open Policy Agent)
- № 839Policy as Code
- № 991Sécurité as Code