Configurer la sécurité du transport.

Remarque : Ce guide n'est compatible qu'avec Cloud Service Mesh et les API Istio. Il n'est pas compatible avec les API Google Cloud . Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Vous pouvez sécuriser le trafic interservices dans Cloud Service Mesh avec les API Istio en appliquant le protocole TLS mutuel (mTLS) strict. Dans les charges de travail Kubernetes, l'authentification mTLS automatique est activée par défaut : les proxys side-car clients envoient automatiquement le trafic mTLS aux side-cars, mais les services de destination acceptent toujours les requêtes en texte brut et chiffrées.

Les règles PeerAuthentication vous permettent de limiter les services pour qu'ils n'acceptent que l'authentification mTLS. Vous pouvez appliquer une règle à l'ensemble du maillage, à un espace de noms spécifique ou à une charge de travail individuelle. Pour connaître les champs compatibles sur les différentes plates-formes, consultez Fonctionnalités compatibles (plan de contrôle géré), Compatibilité des API dans Cloud Service Mesh géré et Fonctionnalités compatibles (plan de contrôle au sein du cluster).

Activer l'authentification TLS mutuelle par espace de noms

Pour activer l'authentification mTLS pour toutes les charges de travail d'un espace de noms donné, utilisez une règle d'authentification à l'échelle de l'espace de noms. Spécifiez l'espace de noms auquel il s'applique sous metadata.

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  mtls:
    mode: STRICT
EOF

Résultat attendu :

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

Activer l'authentification TLS mutuelle par charge de travail

Pour définir une règle PeerAuthentication pour une charge de travail spécifique, vous devez configurer la section selector et spécifier les étiquettes qui correspondent à la charge de travail ciblée. Toutefois, Cloud Service Mesh ne peut pas agréger les règles au niveau de la charge de travail pour le trafic mTLS sortant vers un service. Vous devez configurer une règle de destination pour gérer ce comportement.

1. Appliquez une règle d'authentification à une charge de travail spécifique de l'espace de noms :

   cat <<EOF | kubectl apply -n NAMESPACE -f -
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "AUTH_POLICY_NAME"
     namespace: "NAMESPACE"
   spec:
     selector:
       matchLabels:
         app: WORKLOAD
     mtls:
       mode: STRICT
   EOF
   

   Résultat attendu :

   peerauthentication.security.istio.io/AUTH_POLICY_NAME created

2. Configurez une règle de destination correspondante :

   cat <<EOF | kubectl apply -n NAMESPACE -f -
   apiVersion: "networking.istio.io/v1beta1"
   kind: "DestinationRule"
   metadata:
     name: "DEST_RULE_NAME"
   spec:
     host: "WORKLOAD.NAMESPACE.svc.cluster.local"
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

   Résultat attendu :

   destinationrule.networking.istio.io/DEST_RULE_NAME created

Appliquer l'authentification mTLS à l'échelle du maillage

Pour empêcher tous les services du maillage d'accepter le trafic en texte brut, définissez une règle PeerAuthentication à l'échelle du maillage avec le mode mTLS défini sur STRICT (la valeur par défaut est PERMISSIVE). La règle PeerAuthentication ne doit pas comporter de sélecteur et doit être appliquée dans l'espace de noms racine istio-system. Lorsque vous déployez la règle, le plan de contrôle provisionne automatiquement les certificats TLS afin que les charges de travail puissent s'authentifier mutuellement.

Pour appliquer l'authentification mTLS à l'échelle du maillage, procédez comme suit :

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

Résultat attendu :

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

Désactiver mTLS

Cloud Service Mesh géré avec le plan de contrôle TRAFFIC_DIRECTOR n'est pas compatible avec le mode DISABLE dans les ressources PeerAuthentication (mtls.mode: DISABLE ou portLevelMtls.mode: DISABLE).

Pour envoyer du trafic en texte brut à un service ou un port spécifique dans Cloud Service Mesh géré, configurez les proxys côté serveur et côté client :

1. Côté serveur (PeerAuthentication) : assurez-vous que la charge de travail de destination accepte le trafic en texte brut en utilisant le mode PERMISSIVE. Si votre maillage ou votre espace de noms utilise la règle PERMISSIVE par défaut, vous n'avez pas besoin de créer de ressource PeerAuthentication. Si vous avez appliqué le protocole mTLS STRICT à l'échelle du maillage ou de l'espace de noms, appliquez une règle PeerAuthentication spécifique à la charge de travail ou au port définie sur PERMISSIVE.
2. Côté client (DestinationRule) : configurez une ressource DestinationRule avec tls.mode: DISABLE afin que les proxys side-car côté client envoient du trafic en texte brut lors de l'appel de ce service ou de ce port.

REMARQUE : Étant donné que le proxy côté serveur utilise le mode PERMISSIVE au lieu de DISABLE, la charge de travail de destination accepte toujours le trafic mTLS de tout client non couvert par le DestinationRule. Pour vous assurer que tous les clients du maillage envoient du texte brut, créez la ressource DestinationRule dans l'espace de noms du service de destination (ou istio-system) sans restreindre exportTo.

Exemple : Désactiver mTLS pour un service

1. Si votre maillage ou votre espace de noms applique l'authentification mTLS STRICT, autorisez la charge de travail cible (ou un port spécifique) à accepter le trafic en texte brut en définissant son mode PeerAuthentication sur PERMISSIVE :

   cat <<EOF | kubectl apply -n NAMESPACE -f -
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "AUTH_POLICY_NAME"
     namespace: "NAMESPACE"
   spec:
     selector:
       matchLabels:
         app: WORKLOAD
     mtls:
       mode: PERMISSIVE
   EOF
   

   Pour n'autoriser le texte brut que sur un port de charge de travail spécifique (par exemple, lors de la migration depuis portLevelMtls), définissez plutôt portLevelMtls :

   spec:
     selector:
       matchLabels:
         app: WORKLOAD
     mtls:
       mode: STRICT
     portLevelMtls:
       WORKLOAD_PORT:
         mode: PERMISSIVE
   

2. Configurez un DestinationRule pour indiquer aux proxys clients d'envoyer du trafic en texte brut au service cible :

   cat <<EOF | kubectl apply -n NAMESPACE -f -
   apiVersion: "networking.istio.io/v1beta1"
   kind: "DestinationRule"
   metadata:
     name: "DEST_RULE_NAME"
     namespace: "NAMESPACE"
   spec:
     host: "SERVICE_NAME.NAMESPACE.svc.cluster.local"
     trafficPolicy:
       tls:
         mode: DISABLE
   EOF
   

   Pour désactiver mTLS uniquement pour un port de service spécifique, utilisez portLevelSettings dans DestinationRule :

   spec:
     host: "SERVICE_NAME.NAMESPACE.svc.cluster.local"
     trafficPolicy:
       portLevelSettings:
       - port:
           number: SERVICE_PORT
         tls:
           mode: DISABLE
   

Rechercher et supprimer des règles PeerAuthentication

Pour obtenir la liste de toutes les règles PeerAuthentication du maillage de services, procédez comme suit :

kubectl get peerauthentication --all-namespaces

Si une règle PeerAuthentication est appliquée, vous pouvez la supprimer à l'aide de la commande kubectl delete :

kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME

Étapes suivantes

• Exemple avec Cloud Service Mesh : mTLS
• Apprenez-en plus sur la sécurité dans Cloud Service Mesh.