Rechercher

Chapitre 3. Configuration des certificats

download PDF

3.1. Remplacement du certificat d'entrée par défaut

3.1.1. Comprendre le certificat d'entrée par défaut

Par défaut, OpenShift Container Platform utilise l'opérateur d'ingestion pour créer une autorité de certification interne et émettre un certificat générique valable pour les applications du sous-domaine .apps. La console web et le CLI utilisent également ce certificat.

Les certificats de l'autorité de certification de l'infrastructure interne sont auto-signés. Bien que ce processus puisse être perçu comme une mauvaise pratique par certaines équipes de sécurité ou d'ICP, le risque est minime. Les seuls clients qui font implicitement confiance à ces certificats sont les autres composants du cluster. Le remplacement du certificat joker par défaut par un certificat délivré par une autorité de certification publique déjà incluse dans le paquet d'autorités de certification fourni par l'espace utilisateur du conteneur permet aux clients externes de se connecter en toute sécurité aux applications fonctionnant sous le sous-domaine .apps.

3.1.2. Remplacement du certificat d'entrée par défaut

Vous pouvez remplacer le certificat d'entrée par défaut pour toutes les applications sous le sous-domaine .apps. Après avoir remplacé le certificat, toutes les applications, y compris la console web et le CLI, bénéficieront du cryptage fourni par le certificat spécifié.

Conditions préalables

  • Vous devez disposer d'un certificat Wildcard pour le sous-domaine .apps entièrement qualifié et de la clé privée correspondante. Chaque certificat doit se trouver dans un fichier séparé au format PEM.
  • La clé privée doit être non chiffrée. Si votre clé est cryptée, décryptez-la avant de l'importer dans OpenShift Container Platform.
  • Le certificat doit inclure l'extension subjectAltName indiquant *.apps.<clustername>.<domain>.
  • Le fichier de certificats peut contenir un ou plusieurs certificats dans une chaîne. Le certificat générique doit être le premier certificat du fichier. Il peut être suivi de tous les certificats intermédiaires, et le fichier doit se terminer par le certificat de l'autorité de certification racine.
  • Copiez le certificat de l'autorité de certification racine dans un fichier supplémentaire au format PEM.

Procédure

  1. Créez une carte de configuration qui inclut uniquement le certificat de l'autorité de certification racine utilisé pour signer le certificat générique :

    $ oc create configmap custom-ca \
         --from-file=ca-bundle.crt=</path/to/example-ca.crt> \1
         -n openshift-config
    1
    </path/to/example-ca.crt> est le chemin d'accès au fichier du certificat de l'autorité de certification racine sur votre système de fichiers local.
  2. Mettre à jour la configuration du proxy à l'échelle du cluster avec la carte de configuration nouvellement créée :

    $ oc patch proxy/cluster \
         --type=merge \
         --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
  3. Créez un secret qui contient la chaîne et la clé du certificat générique :

    $ oc create secret tls <secret> \1
         --cert=</path/to/cert.crt> \2
         --key=</path/to/cert.key> \3
         -n openshift-ingress
    1
    <secret> est le nom du secret qui contiendra la chaîne de certificats et la clé privée.
    2
    </path/to/cert.crt> est le chemin d'accès à la chaîne de certificats sur votre système de fichiers local.
    3
    </path/to/cert.key> est le chemin d'accès à la clé privée associée à ce certificat.
  4. Mettre à jour la configuration du contrôleur d'entrée avec le nouveau secret créé :

    $ oc patch ingresscontroller.operator default \
         --type=merge -p \
         '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \1
         -n openshift-ingress-operator
    1
    Remplacez <secret> par le nom utilisé pour le secret à l'étape précédente.

Ressources supplémentaires

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.