Rechercher

3.2. Ajout de certificats de serveur API

download PDF

Le certificat du serveur API par défaut est émis par une autorité de certification interne du cluster OpenShift Container Platform. Les clients extérieurs au cluster ne pourront pas vérifier le certificat du serveur API par défaut. Ce certificat peut être remplacé par un certificat émis par une autorité de certification à laquelle les clients font confiance.

3.2.1. Ajouter un serveur API nommé certificat

Le certificat du serveur API par défaut est émis par une autorité de certification interne du cluster OpenShift Container Platform. Vous pouvez ajouter un ou plusieurs certificats alternatifs que le serveur API renverra en fonction du nom de domaine entièrement qualifié (FQDN) demandé par le client, par exemple lorsqu'un proxy inverse ou un équilibreur de charge est utilisé.

Conditions préalables

  • Vous devez disposer d'un certificat pour le FQDN et de la clé privée correspondante. Chacun d'eux 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 le FQDN.
  • Le fichier de certificats peut contenir un ou plusieurs certificats dans une chaîne. Le certificat pour le FQDN du serveur API 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.
Avertissement

Ne fournissez pas de certificat nommé pour l'équilibreur de charge interne (nom d'hôte api-int.<cluster_name>.<base_domain>). Si vous le faites, votre cluster se retrouvera dans un état dégradé.

Procédure

  1. Connectez-vous à la nouvelle API en tant qu'utilisateur kubeadmin.

    $ oc login -u kubeadmin -p <password> https://FQDN:6443
  2. Obtenir le fichier kubeconfig.

    oc config view --flatten > kubeconfig-newapi
  3. Créez un secret contenant la chaîne de certificats et la clé privée dans l'espace de noms openshift-config.

    $ oc create secret tls <secret> \1
         --cert=</path/to/cert.crt> \2
         --key=</path/to/cert.key> \3
         -n openshift-config
    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 le serveur API pour qu'il fasse référence au secret créé.

    $ oc patch apiserver cluster \
         --type=merge -p \
         '{"spec":{"servingCerts": {"namedCertificates":
         [{"names": ["<FQDN>"], 1
         "servingCertificate": {"name": "<secret>"}}]}}}' 2
    1
    Remplacez <FQDN> par le FQDN pour lequel le serveur API doit fournir le certificat.
    2
    Remplacez <secret> par le nom utilisé pour le secret à l'étape précédente.
  5. Examinez l'objet apiserver/cluster et confirmez que le secret est maintenant référencé.

    $ oc get apiserver cluster -o yaml

    Exemple de sortie

    ...
    spec:
      servingCerts:
        namedCertificates:
        - names:
          - <FQDN>
          servingCertificate:
            name: <secret>
    ...

  6. Consultez l'opérateur kube-apiserver et vérifiez qu'une nouvelle révision du serveur API Kubernetes est déployée. L'opérateur peut mettre une minute à détecter le changement de configuration et à déclencher un nouveau déploiement. Pendant le déploiement de la nouvelle révision, PROGRESSING signalera True.

    $ oc get clusteroperators kube-apiserver

    Ne passez pas à l'étape suivante tant que PROGRESSING n'est pas répertorié comme False, comme le montre le résultat suivant :

    Exemple de sortie

    NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    kube-apiserver   4.12.0     True        False         False      145m

    Si PROGRESSING affiche True, attendez quelques minutes et réessayez.

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.