3.2. Ajout de certificats de serveur API
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.
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
Connectez-vous à la nouvelle API en tant qu'utilisateur
kubeadmin
.$ oc login -u kubeadmin -p <password> https://FQDN:6443
Obtenir le fichier
kubeconfig
.oc config view --flatten > kubeconfig-newapi
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
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
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> ...
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
signaleraTrue
.$ oc get clusteroperators kube-apiserver
Ne passez pas à l'étape suivante tant que
PROGRESSING
n'est pas répertorié commeFalse
, 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
afficheTrue
, attendez quelques minutes et réessayez.