La confiance zéro dans Kubernetes commence par l'identité et la politique_

« La confiance zéro » devient rapidement un jargon vide si cela ne signifie que « nous nous préoccupons de la sécurité ». À l'intérieur de Kubernetes, la version pratique est plus simple et plus stricte : un service ne doit pas faire confiance à un autre service simplement parce qu'il se trouve sur le même réseau de cluster.

Cela conduit à trois exigences concrètes :

• identité de charge de travail
• trafic de service à service chiffré
• politique d'autorisation explicite

À quoi ressemble réellement la confiance zéro dans Kubernetes

Dans la plupart des clusters de production, le point de départ n'est pas un déploiement de service mesh parfait. C'est un ensemble plus restreint de contrôles applicables :

• identités de service authentifiées
• mTLS entre services sensibles
• politique réseau au niveau de l'espace de noms ou de la charge de travail
• autorisation de style liste blanche pour les API importantes

Avec Istio, une politique d'autorisation peut ressembler à ceci :

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-api
spec:
  selector:
    matchLabels:
      app: payments-api
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/checkout/sa/checkout-service

C'est beaucoup plus proche de la confiance zéro que « les services sont tous privés ».

Pourquoi les équipes ont des difficultés avec cela

La valeur est réelle, mais le coût opérationnel l'est également. Une fois que vous introduisez mTLS et des couches de politiques, vous introduisez aussi de nouveaux modes d'échec :

• problèmes de rotation de certificats
• débogage du trafic plus compliqué
• erreurs de politique qui ressemblent à des pannes
• latence supplémentaire et complexité du plan de contrôle

C'est pourquoi les équipes matures adoptent cela progressivement. Elles commencent par l'identité sur une tranche étroite, ajoutent des politiques là où le rayon d'impact est le plus élevé, et investissent dans l'observabilité avant d'essayer de verrouiller tout.

Meilleur objectif, meilleur langage

Le bon objectif n'est pas « installer un mesh et devenir zéro confiance ». Le bon objectif est de remplacer la confiance implicite du réseau par une identité et une politique explicites dans les parties de la plateforme qui comptent le plus.

Cette approche est plus honnête, plus mesurable et beaucoup plus facile à opérer.

Lectures complémentaires

• Concepts de sécurité Istio
• Politique d'autorisation Istio
• Politiques réseau Kubernetes