Le modèle de sécurité basé sur la périmètre traditionnel est obsolète. Dans une architecture de microservices distribuée, les services communiquent sur des réseaux internes qui ne sont plus « fiables » simplement parce qu'ils résident dans le même centre de données ou VPC cloud. L'essor de menaces sophistiquées, y compris les déplacements latéraux des attaquants et les menaces internes, nécessite un changement fondamental dans la manière dont nous sécurisons la communication inter-services. C'est ici que l'architecture Zero Trust (ZTA) devient non seulement un mot à la mode, mais une exigence critique pour l'ingénierie.
Zero Trust est fondé sur le principe : « Ne faites jamais confiance, vérifiez toujours. » Pour les microservices, cela signifie que chaque requête, quelle que soit son origine, doit être authentifiée, autorisée et chiffrée. Dans cet article, nous explorerons comment mettre en œuvre ce paradigme en utilisant le Transport Layer Security mutuel (mTLS) et des cadres d'identité tels que SPIFFE (Spiffe Identity for Edge Federated Enterprises).
Le problème de la confiance implicite
Historiquement, les développeurs supposaient que le trafic entre les services au sein d'un cluster était sûr. Cette confiance implicite permet à un attaquant qui compromet un service de pivoter latéralement vers d'autres avec un minimum de friction. Sans ZTA, vous construisez essentiellement une maison avec une porte d'entrée solide mais sans serrures dans les pièces intérieures.
La mise en œuvre de Zero Trust nécessite de passer de contrôles basés sur le réseau à des contrôles basés sur l'identité. Chaque service doit avoir une identité unique et cryptographiquement vérifiable, et chaque canal de communication doit appliquer des politiques d'accès strictes basées sur ces identités.
Composants clés : SPIFFE et mTLS
Pour opérationnaliser Zero Trust, nous nous appuyons sur deux technologies clés :
- SPIFFE/SPIRE : SPIFFE fournit une norme pour spécifier les identités, et SPIRE est le système d'exécution qui émet ces identités via des certificats X.509.
- mTLS : Contrairement au TLS standard où seul le serveur prouve son identité, le mTLS exige que le client et le serveur présentent des certificats, garantissant que les deux parties sont des entités légitimes.
En intégrant SPIRE avec un maillage de services (service mesh) comme Istio ou Linkerd, nous pouvons automatiser l'émission et le renouvellement des certificats. Cela élimine la charge de gestion manuelle des certificats SSL/TLS tout en garantissant que les identités des services sont à courte durée de vie et révocables.
Mise en œuvre pratique : Configuration des fournisseurs d'identité
Examinons un exemple pratique de la manière de configurer un agent SPIRE de base pour garantir l'identité d'un service. Cette configuration indique à l'agent SPIRE quel charge de travail (service) faire confiance et quelle audience (maillage de services) l'identité résultante doit avoir.
# spire-server.conf
server {
bind_address = "0.0.0.0"
bind_port = "8081"
data_dir = "/run/spire/data"
log_level = "DEBUG"
trust_domain = "example.org"
}
# Définir le plugin pour la charge de travail
plugins {
NodeAttestor "k8s_psat" {
plugin_data {
cluster = "my-k8s-cluster"
}
}
KeyManager "disk" {
plugin_data {
keys_path = "/run/spire/data/keys.json"
}
}
WorkloadAttestor "k8s" {
plugin_data {
# Ignorer la vérification du jeton Kubernetes pour simplifier le développement
skip_k8s_server_tls_verify = true
}
}
}
# Définir la politique pour le microservice spécifique
authority {
# Autoriser le "payment-service" à s'attester
selector "k8s:pod-ns:payment"
selector "k8s:pod-name:payment-service"
}
Dans cette configuration, les instructions selector définissent quels pods Kubernetes sont autorisés à s'enregistrer auprès du serveur SPIRE. Cela garantit que seul le pod authentique payment-service peut obtenir l'identité cryptographique requise pour communiquer avec d'autres services.
Application des politiques d'autorisation
Une fois les identités établies, l'étape suivante est l'autorisation. Zero Trust ne vérifie pas seulement qui vous êtes ; il vérifie ce que vous avez le droit de faire. Cela est généralement géré par les proxies sidecar du maillage de services (comme Envoy).
Par exemple, dans un maillage de services Istio, vous pouvez définir une AuthorizationPolicy pour restreindre l'accès. Supposons que le frontend-service ne soit pas autorisé à appeler directement le internal-logging-service. Vous pouvez appliquer cela en écrivant la politique YAML suivante :
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-frontend-to-logging
namespace: default
spec:
selector:
matchLabels:
app: internal-logging-service
action: DENY
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/frontend-service"]
Cette politique nie explicitement toute requête provenant de l'identité frontend-service vers le internal-logging-service, même si le chemin réseau est ouvert. Ce contrôle granulaire est la marque de fabrique d'une mise en œuvre Zero Trust.
Conclusion
La mise en œuvre de Zero Trust dans la communication des microservices n'est pas un projet ponctuel, mais un processus continu de durcissement de votre posture de sécurité. En adoptant des normes comme SPIFFE et en tirant parti du TLS mutuel, les organisations peuvent éliminer les hypothèses de confiance implicite et réduire considérablement la portée des violations potentielles.
Pour les développeurs intermédiaires et avancés, le défi réside dans l'équilibre entre sécurité, observabilité et performance. Cependant, les avantages à long terme en termes de résilience, de conformité et de confiance dans les systèmes distribués dépassent largement les coûts initiaux de mise en œuvre. Commencez petit, automatisez la gestion des identités et testez rigoureusement vos politiques d'autorisation pour construire un écosystème de microservices véritablement sécurisé.