Chapitre 3. Configuration des certificats
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
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.
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"}}}'
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
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.