SupportConsoleDéveloppeursCommencer un essaiContact

2.6. Personnalisation de la sécurité dans un maillage de services

Avertissement

You are viewing documentation for a Red Hat OpenShift Service Mesh release that is no longer supported.

Les plans de contrôle Service Mesh version 1.0 et 1.1 ne sont plus pris en charge. Pour plus d'informations sur la mise à niveau de votre plan de contrôle Service Mesh, voir Mise à niveau de Service Mesh.

Pour plus d'informations sur l'état de l'assistance d'une version particulière de Red Hat OpenShift Service Mesh, consultez la page Cycle de vie du produit.

Si votre application Service Mesh est construite avec un ensemble complexe de microservices, vous pouvez utiliser Red Hat OpenShift Service Mesh pour personnaliser la sécurité de la communication entre ces services. L'infrastructure d'OpenShift Container Platform et les fonctionnalités de gestion du trafic de Service Mesh peuvent vous aider à gérer la complexité de vos applications et à assurer la sécurité des services et des identités pour les microservices.

2.6.1. Activation de la sécurité mutuelle de la couche transport (mTLS)

Mutual Transport Layer Security (mTLS) est un protocole dans lequel deux parties s'authentifient mutuellement. C'est le mode d'authentification par défaut dans certains protocoles (IKE, SSH) et facultatif dans d'autres (TLS).

mTLS peut être utilisé sans modification du code de l'application ou du service. Le TLS est entièrement géré par l'infrastructure de maillage de services et entre les deux mandataires sidecar.

Par défaut, Red Hat OpenShift Service Mesh est configuré en mode permissif, où les sidecars dans Service Mesh acceptent à la fois le trafic en texte clair et les connexions qui sont chiffrées à l'aide de mTLS. Si un service dans votre maillage communique avec un service en dehors du maillage, un mTLS strict pourrait interrompre la communication entre ces services. Utilisez le mode permissif pendant que vous migrez vos charges de travail vers Service Mesh.

2.6.1.1. Activation de mTLS strict à travers le maillage

Si vos charges de travail ne communiquent pas avec des services en dehors de votre maillage et que la communication ne sera pas interrompue en n'acceptant que des connexions cryptées, vous pouvez activer mTLS dans votre maillage rapidement. Définissez spec.istio.global.mtls.enabled sur true dans votre ressource ServiceMeshControlPlane. L'opérateur crée les ressources nécessaires. 

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
2.6.1.1.1. Configuration des sidecars pour les connexions entrantes pour des services spécifiques

Vous pouvez également configurer mTLS pour des services ou des espaces de noms individuels en créant une stratégie. 

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: default
  namespace: <NAMESPACE>
spec:
  peers:
    - mtls: {}

2.6.1.2. Configuration des sidecars pour les connexions sortantes

Créez une règle de destination pour configurer Service Mesh afin qu'il utilise mTLS lors de l'envoi de requêtes à d'autres services dans le maillage. 

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "default"
  namespace: <CONTROL_PLANE_NAMESPACE>>
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

2.6.1.3. Définition des versions minimale et maximale du protocole

Si votre environnement a des exigences spécifiques pour le trafic crypté dans votre maillage de services, vous pouvez contrôler les fonctions cryptographiques autorisées en définissant les valeurs spec.security.controlPlane.tls.minProtocolVersion ou spec.security.controlPlane.tls.maxProtocolVersion dans votre ressource ServiceMeshControlPlane. Ces valeurs, configurées dans votre ressource de plan de contrôle, définissent la version TLS minimale et maximale utilisée par les composants du maillage lorsqu'ils communiquent de manière sécurisée via TLS. 

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      tls:
        minProtocolVersion: TLSv1_2
        maxProtocolVersion: TLSv1_3

La valeur par défaut est TLS_AUTO et ne spécifie pas de version de TLS.

Tableau 2.3. Valeurs valables
ValeurDescription

TLS_AUTO

par défaut

TLSv1_0

TLS version 1.0

TLSv1_1

TLS version 1.1

TLSv1_2

TLS version 1.2

TLSv1_3

TLS version 1.3

2.6.2. Configuration des suites de chiffrement et des courbes ECDH

Les suites de chiffrement et les courbes de Diffie-Hellman à courbe elliptique (courbes ECDH) peuvent vous aider à sécuriser votre maillage de services. Vous pouvez définir une liste séparée par des virgules de suites de chiffrement en utilisant spec.istio.global.tls.cipherSuites et de courbes ECDH en utilisant spec.istio.global.tls.ecdhCurves dans votre ressource ServiceMeshControlPlane. Si l'un de ces attributs est vide, les valeurs par défaut sont utilisées.

Le paramètre cipherSuites est efficace si votre maillage de services utilise TLS 1.2 ou une version antérieure. Il n'a aucun effet lors de la négociation avec TLS 1.3.

Définissez vos suites de chiffrement dans la liste séparée par des virgules, par ordre de priorité. Par exemple, ecdhCurves: CurveP256, CurveP384 donne à CurveP256 une priorité plus élevée que CurveP384.

Note

Vous devez inclure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ou TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 lorsque vous configurez la suite de chiffrement. La prise en charge de HTTP/2 nécessite au moins l'une de ces suites de chiffrement.

Les suites de chiffrement prises en charge sont les suivantes

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

Les courbes ECDH prises en charge sont les suivantes :

  • CourbeP256
  • CourbeP384
  • CourbeP521
  • X25519

2.6.3. Ajout d'une clé et d'un certificat d'une autorité de certification externe

Par défaut, Red Hat OpenShift Service Mesh génère un certificat racine et une clé auto-signés, et les utilise pour signer les certificats de charge de travail. Vous pouvez également utiliser le certificat et la clé définis par l'utilisateur pour signer les certificats de charge de travail, avec le certificat racine défini par l'utilisateur. Cette tâche présente un exemple d'insertion de certificats et de clés dans Service Mesh.

Conditions préalables

  • Vous devez avoir installé Red Hat OpenShift Service Mesh avec TLS mutuel activé pour configurer les certificats.
  • Cet exemple utilise les certificats du référentiel Maistra. Pour la production, utilisez vos propres certificats provenant de votre autorité de certification.
  • Vous devez déployer l'application d'exemple Bookinfo pour vérifier les résultats avec ces instructions.

2.6.3.1. Ajouter un certificat et une clé existants

Pour utiliser un certificat et une clé de signature (CA) existants, vous devez créer un fichier de chaîne de confiance qui inclut le certificat CA, la clé et le certificat racine. Vous devez utiliser les noms de fichiers exacts suivants pour chacun des certificats correspondants. Le certificat de l'autorité de certification s'appelle ca-cert.pem, la clé ca-key.pem, et le certificat racine, qui signe ca-cert.pem, s'appelle root-cert.pem. Si votre charge de travail utilise des certificats intermédiaires, vous devez les spécifier dans un fichier cert-chain.pem.

Ajoutez les certificats à Service Mesh en suivant les étapes suivantes. Sauvegardez localement les certificats d'exemple du repo Maistra et remplacez <path> par le chemin d'accès à vos certificats.

  1. Créez un secret cacert qui comprend les fichiers d'entrée ca-cert.pem, ca-key.pem, root-cert.pem et cert-chain.pem. 

    $ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
    --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
    --from-file=<path>/cert-chain.pem

  2. Dans la ressource ServiceMeshControlPlane, l'ensemble global.mtls.enabled devient true et l'ensemble security.selfSigned devient false. Service Mesh lit les certificats et la clé à partir des fichiers secret-mount. 

    apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: false

  3. Pour s'assurer que les charges de travail ajoutent rapidement les nouveaux certificats, supprimez les secrets générés par Service Mesh, nommés istio.*. Dans cet exemple, istio.default. Service Mesh émet de nouveaux certificats pour les charges de travail. 

    $ oc delete secret istio.default

2.6.3.2. Vérification des certificats

Utilisez l'exemple d'application Bookinfo pour vérifier que vos certificats sont montés correctement. Tout d'abord, récupérez les certificats montés. Ensuite, vérifiez les certificats montés sur le pod.

  1. Enregistrez le nom du pod dans la variable RATINGSPOD. 

    $ RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`

  2. Exécutez les commandes suivantes pour récupérer les certificats montés sur le proxy. 

    oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/root-cert.pem > /tmp/pod-root-cert.pem

    Le fichier /tmp/pod-root-cert.pem contient le certificat racine propagé au pod. 

    oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem

    Le fichier /tmp/pod-cert-chain.pem contient le certificat de la charge de travail et le certificat de l'autorité de certification propagé au pod.

  3. Vérifiez que le certificat racine est le même que celui spécifié par l'opérateur. Remplacez <path> par le chemin d'accès à vos certificats. 

    $ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
    $ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt
    $ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

    S'attendre à ce que la sortie soit vide.

  4. Vérifiez que le certificat CA est le même que celui spécifié par Operator. Remplacez <path> par le chemin d'accès à vos certificats. 

    $ sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem
    $ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
    $ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
    $ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

    S'attendre à ce que la sortie soit vide.

  5. Vérifiez la chaîne de certificats depuis le certificat racine jusqu'au certificat de charge de travail. Remplacez <path> par le chemin d'accès à vos certificats. 

    head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem
    $ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem

    Exemple de sortie

    /tmp/pod-cert-chain-workload.pem: OK

2.6.3.3. Suppression des certificats

Pour supprimer les certificats que vous avez ajoutés, procédez comme suit.

  1. Retirer le secret cacerts. 

    $ oc delete secret cacerts -n istio-system

  2. Redéployer Service Mesh avec un certificat racine auto-signé dans la ressource ServiceMeshControlPlane. 

    apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: true
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.