Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

9.2. Itinéraires sécurisés

Les itinéraires sécurisés permettent d’utiliser plusieurs types de terminaison TLS pour servir des certificats au client. Les sections suivantes décrivent comment créer des itinéraires de recryptage, de bord et de passage avec des certificats personnalisés.

Important

Lorsque vous créez des itinéraires dans Microsoft Azure via des points de terminaison publics, les noms de ressource sont soumis à des restrictions. Il est impossible de créer des ressources qui utilisent certains termes. Dans la liste des termes qu’Azure restreint, consultez Résoudre les erreurs de nom de ressource réservées dans la documentation Azure.

Il est possible de configurer un itinéraire sécurisé en recryptant la terminaison TLS avec un certificat personnalisé à l’aide de la commande oc create route.

Conditions préalables

  • Il faut avoir une paire de certificats/clés dans les fichiers encodés PEM, où le certificat est valide pour l’hôte de route.
  • Il se peut que vous ayez un certificat CA distinct dans un fichier codé PEM qui complète la chaîne de certificats.
  • Il faut avoir un certificat CA de destination distinct dans un fichier encodé PEM.
  • Il faut avoir un service que vous voulez exposer.
Note

Les fichiers clés protégés par mot de passe ne sont pas pris en charge. Afin de supprimer une phrase de passe d’un fichier clé, utilisez la commande suivante: 

$ openssl rsa -in password_protected_tls.key -out tls.key
Copy to Clipboard Toggle word wrap

Procédure

Cette procédure crée une ressource Route avec un certificat personnalisé et recrypte la terminaison TLS. Ce qui suit suppose que la paire certificat/clé est dans les fichiers tls.crt et tls.key dans le répertoire de travail actuel. Il faut également spécifier un certificat CA de destination pour permettre au contrôleur Ingress de faire confiance au certificat du service. Il est également possible que vous spécifiiez un certificat CA si nécessaire pour compléter la chaîne de certificats. Les noms de chemin réels sont remplacés par tls.crt, tls.key, cacert.crt et (facultativement) ca.crt. Remplacez le nom de la ressource Service que vous souhaitez exposer pour frontend. Remplacez le nom d’hôte approprié à www.example.com.

  • Créez une ressource Route sécurisée en recryptant la terminaison TLS et un certificat personnalisé: 

    $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
    Copy to Clipboard Toggle word wrap

    Lorsque vous examinez la ressource de Route résultante, elle devrait ressembler à ce qui suit:

    Définition YAML de la route sécurisée

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: reencrypt
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    destinationCACertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

    Consultez oc create route reencrypt --help pour plus d’options.

Il est possible de configurer un itinéraire sécurisé à l’aide d’un certificat personnalisé en utilisant la commande oc create route. Avec une route bordée, le contrôleur Ingress met fin au cryptage TLS avant de transférer du trafic vers le pod de destination. L’itinéraire spécifie le certificat TLS et la clé que le contrôleur Ingress utilise pour l’itinéraire.

Conditions préalables

  • Il faut avoir une paire de certificats/clés dans les fichiers encodés PEM, où le certificat est valide pour l’hôte de route.
  • Il se peut que vous ayez un certificat CA distinct dans un fichier codé PEM qui complète la chaîne de certificats.
  • Il faut avoir un service que vous voulez exposer.
Note

Les fichiers clés protégés par mot de passe ne sont pas pris en charge. Afin de supprimer une phrase de passe d’un fichier clé, utilisez la commande suivante: 

$ openssl rsa -in password_protected_tls.key -out tls.key
Copy to Clipboard Toggle word wrap

Procédure

Cette procédure crée une ressource Route avec un certificat personnalisé et une terminaison TLS. Ce qui suit suppose que la paire certificat/clé est dans les fichiers tls.crt et tls.key dans le répertoire de travail actuel. Il est également possible que vous spécifiiez un certificat CA si nécessaire pour compléter la chaîne de certificats. Les noms de chemin réels sont remplacés par tls.crt, tls.key et (facultativement) ca.crt. Remplacez le nom du service que vous souhaitez exposer pour frontend. Remplacez le nom d’hôte approprié à www.example.com.

  • Créez une ressource Route sécurisée à l’aide de terminaisons TLS et d’un certificat personnalisé. 

    $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
    Copy to Clipboard Toggle word wrap

    Lorsque vous examinez la ressource de Route résultante, elle devrait ressembler à ce qui suit:

    Définition YAML de la route sécurisée

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

    Consultez oc créer le bord de route --aide pour plus d’options.

9.2.3. Création d’un parcours de passage
Copier lien

Il est possible de configurer un itinéraire sécurisé à l’aide de la commande oc create route. Avec la terminaison de passage, le trafic crypté est envoyé directement à la destination sans que le routeur ne fournisse la terminaison TLS. Aucune clé ou certificat n’est donc requis sur l’itinéraire.

Conditions préalables

  • Il faut avoir un service que vous voulez exposer.

Procédure

  • Créer une ressource Route: 

    $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080
    Copy to Clipboard Toggle word wrap

    Lorsque vous examinez la ressource de Route résultante, elle devrait ressembler à ce qui suit:

    La route sécurisée à l’aide de la terminaison de passage

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured
    1 
    
spec:
  host: www.example.com
  port:
    targetPort: 8080
  tls:
    termination: passthrough
    2 
    
    insecureEdgeTerminationPolicy: None
    3 
    
  to:
    kind: Service
    name: frontend
    Copy to Clipboard Toggle word wrap

    1
    Le nom de l’objet, qui est limité à 63 caractères.
    2
    Le champ de terminaison est défini pour passer. C’est le seul champ de tls requis.
    3
    En option, non sécuriséEdgeTerminationPolicy. Les seules valeurs valides sont Aucune, Redirect ou vide pour désactivé.

    Le pod de destination est responsable du service des certificats pour le trafic au point de terminaison. C’est actuellement la seule méthode qui peut prendre en charge l’exigence de certificats clients, également connu sous le nom d’authentification bidirectionnelle.

Important

La sécurisation de l’itinéraire avec des certificats externes dans les secrets TLS n’est qu’une fonctionnalité d’aperçu technologique. Les fonctionnalités d’aperçu technologique ne sont pas prises en charge avec les accords de niveau de service de production de Red Hat (SLA) et pourraient ne pas être fonctionnellement complètes. Le Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès précoce aux fonctionnalités du produit à venir, permettant aux clients de tester les fonctionnalités et de fournir des commentaires pendant le processus de développement.

En savoir plus sur la portée du support des fonctionnalités de Red Hat Technology Preview, voir la portée du support des fonctionnalités d’aperçu de la technologie.

En utilisant le champ .spec.tls.externalCertificate de l’API de route, vous pouvez configurer OpenShift Dedicated avec des solutions de gestion de certificats tierces. Il est possible de faire référence à des certificats TLS gérés par l’extérieur via des secrets, éliminant ainsi la nécessité d’une gestion manuelle des certificats. L’utilisation du certificat géré par l’extérieur réduit les erreurs assurant un déploiement plus fluide des mises à jour des certificats, permettant au routeur OpenShift de servir rapidement les certificats renouvelés.

Note

Cette fonctionnalité s’applique à la fois aux routes périphériques et au recryptage des routes.

Conditions préalables

  • Il faut activer le portail RouteExternalCertificate.
  • Il faut avoir les autorisations de création et de mise à jour sur les routes/hôte personnalisé.
  • Il faut avoir un secret contenant une paire de certificats / clé valide au format PEM de type kubernetes.io/tls, qui comprend à la fois les touches tls.key et tls.crt.
  • Il faut placer le secret référencé dans le même espace de noms que l’itinéraire que vous souhaitez sécuriser.

Procédure

  1. Créez un rôle dans le même espace de noms que le secret pour permettre l’accès au compte de service routeur en exécutant la commande suivante: 

    $ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \
    1 
    
--namespace=<current-namespace>
    2
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le nom de votre secret.
    2
    Indiquez l’espace de noms où résident à la fois votre secret et votre itinéraire.

  2. Créez une liaison de rôle dans le même espace de noms que le secret et liez le compte de service routeur au rôle nouvellement créé en exécutant la commande suivante: 

    $ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’espace de noms où résident à la fois votre secret et votre itinéraire.

  3. Créez un fichier YAML qui définit l’itinéraire et spécifie le secret contenant votre certificat à l’aide de l’exemple suivant.

    Définition YAML de l’itinéraire sécurisé

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: myedge
  namespace: test
spec:
  host: myedge-test.apps.example.com
  tls:
    externalCertificate:
      name: <secret-name>
    1 
    
    termination: edge
    [...]
[...]
    Copy to Clipboard Toggle word wrap

    1
    Indiquez le nom de votre secret.

  4. Créez une ressource d’itinéraire en exécutant la commande suivante: 

    $ oc apply -f <route.yaml>
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le nom de fichier YAML généré.

En cas d’existence d’un secret et d’une paire de clés, le routeur servira le certificat généré si toutes les conditions préalables sont remplies.

Note

Dans le cas où .spec.tls.externalCertificate n’est pas fourni, le routeur utilisera les certificats générés par défaut.

Il est impossible de fournir le champ .spec.tls.certificate ou le champ .spec.tls.key lorsque vous utilisez le champ .spec.tls.externalCertificate.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat