4.11. Certificats d'ingérence

L'opérateur d'entrée utilise des certificats pour

Pour sécuriser l'accès aux mesures de l'opérateur d'entrée et du contrôleur d'entrée, l'opérateur d'entrée utilise des certificats de service. L'opérateur demande un certificat au contrôleur service-ca pour ses propres mesures, et le contrôleur service-ca place le certificat dans un secret nommé metrics-tls dans l'espace de noms openshift-ingress-operator. En outre, l'opérateur d'entrée demande un certificat pour chaque contrôleur d'entrée et le contrôleur service-ca place le certificat dans un secret nommé router-metrics-certs-<name>, où <name> est le nom du contrôleur d'entrée, dans l'espace de noms openshift-ingress.

Chaque contrôleur d'entrée dispose d'un certificat par défaut qu'il utilise pour les itinéraires sécurisés qui ne spécifient pas leurs propres certificats. À moins que vous n'indiquiez un certificat personnalisé, l'opérateur utilise par défaut un certificat auto-signé. L'opérateur utilise son propre certificat de signature auto-signé pour signer tout certificat par défaut qu'il génère. L'opérateur génère ce certificat de signature et le place dans un secret nommé router-ca dans l'espace de noms openshift-ingress-operator. Lorsque l'opérateur génère un certificat par défaut, il le place dans un secret nommé router-certs-<name> (où <name> est le nom du contrôleur d'entrée) dans l'espace de noms openshift-ingress.

Si le champ defaultCertificate est vide, l'opérateur d'entrée utilise son autorité de certification auto-signée pour générer un certificat de service pour le domaine spécifié.

Certificat et clé de l'autorité de certification par défaut générés par l'opérateur d'entrée. Utilisé pour signer les certificats de service par défaut générés par l'opérateur.

Dans le flux de travail par défaut, il s'agit du certificat de service par défaut avec caractère générique, créé par l'opérateur d'entrée et signé à l'aide du certificat de l'autorité de certification par défaut généré. Dans le flux de travail personnalisé, il s'agit du certificat fourni par l'utilisateur.

Le déploiement du routeur. Utilise le certificat dans secrets/router-certs-default comme certificat de serveur frontal par défaut.

Dans le flux de travail par défaut, le contenu du certificat de service par défaut (parties publique et privée) est copié ici pour permettre l'intégration OAuth. Dans le flux de travail personnalisé, il s'agit du certificat fourni par l'utilisateur.

La partie publique (certificat) du certificat de service par défaut. Remplace la ressource configmaps/router-ca.

L'utilisateur met à jour la configuration du proxy de cluster avec le certificat CA qui a signé le certificat de service ingresscontroller. Cela permet à des composants tels que auth, console et le registre de faire confiance au certificat de service.

Le groupe d'AC de confiance à l'échelle du cluster contenant les groupes d'AC combinés de Red Hat Enterprise Linux CoreOS (RHCOS) et fournis par l'utilisateur ou un groupe RHCOS uniquement si un groupe d'utilisateurs n'est pas fourni.

Le paquet de certificats CA personnalisés, qui indique à d'autres composants (par exemple, auth et console) de faire confiance à un ingresscontroller configuré avec un certificat personnalisé.

Le champ trustedCA est utilisé pour référencer l'ensemble de CA fourni par l'utilisateur.

L'opérateur du réseau de clusters injecte le paquet d'AC de confiance dans la carte de configuration proxy-ca.

OpenShift Container Platform 4.12 et les versions plus récentes utilisent default-ingress-cert.

Les délais d'expiration des certificats de l'opérateur d'entrée sont les suivants :

Vous ne pouvez pas spécifier de conditions d'expiration personnalisées pour les certificats créés par l'opérateur d'entrée ou le contrôleur service-ca.

Lors de l'installation d'OpenShift Container Platform, vous ne pouvez pas spécifier de délai d'expiration pour les certificats créés par l'opérateur d'ingestion ou le contrôleur service-ca.

Prometheus utilise les certificats qui sécurisent les métriques.

L'opérateur d'entrée utilise son certificat de signature pour signer les certificats par défaut qu'il génère pour les contrôleurs d'entrée pour lesquels vous ne définissez pas de certificats par défaut personnalisés.

Les composants du cluster qui utilisent des routes sécurisées peuvent utiliser le certificat par défaut du contrôleur d'entrée.

L'entrée dans le cluster via une route sécurisée utilise le certificat par défaut du contrôleur d'entrée par lequel la route est accessible, à moins que la route ne spécifie son propre certificat.

Les certificats d'entrée sont gérés par l'utilisateur. Pour plus d'informations, voir Remplacement du certificat d'entrée par défaut.

Le contrôleur service-ca effectue une rotation automatique des certificats qu'il émet. Cependant, il est possible d'utiliser oc delete secret <secret> pour effectuer une rotation manuelle des certificats de service.

L'opérateur d'ingestion n'effectue pas de rotation de son propre certificat de signature ou des certificats par défaut qu'il génère. Les certificats par défaut générés par l'opérateur sont destinés à remplacer les certificats par défaut personnalisés que vous configurez.