4.2. Certificats de procuration
4.2.1. Objectif
Les certificats proxy permettent aux utilisateurs de spécifier un ou plusieurs certificats d'autorité de certification (CA) personnalisés utilisés par les composants de la plate-forme lors de l'établissement de connexions de sortie.
Le champ trustedCA de l'objet Proxy est une référence à une carte de configuration qui contient un ensemble d'autorités de certification (CA) de confiance fourni par l'utilisateur. Cet ensemble est fusionné avec l'ensemble de confiance de Red Hat Enterprise Linux CoreOS (RHCOS) et injecté dans le magasin de confiance des composants de la plate-forme qui effectuent des appels HTTPS de sortie. Par exemple, image-registry-operator appelle un registre d'images externe pour télécharger des images. Si trustedCA n'est pas spécifié, seul l'ensemble de confiance RHCOS est utilisé pour les connexions HTTPS proxy. Fournissez des certificats CA personnalisés à l'ensemble de confiance RHCOS si vous souhaitez utiliser votre propre infrastructure de certificats.
Le champ trustedCA ne doit être consommé que par un validateur de proxy. Le validateur est chargé de lire le paquet de certificats de la clé requise ca-bundle.crt et de le copier dans une carte de configuration nommée trusted-ca-bundle dans l'espace de noms openshift-config-managed. L'espace de noms de la carte de configuration référencée par trustedCA est openshift-config:
apiVersion: v1
kind: ConfigMap
metadata:
name: user-ca-bundle
namespace: openshift-config
data:
ca-bundle.crt: |
-----BEGIN CERTIFICATE-----
Custom CA certificate bundle.
-----END CERTIFICATE-----Ressources supplémentaires
4.2.2. Gestion des certificats proxy lors de l'installation
La valeur additionalTrustBundle de la configuration de l'installateur est utilisée pour spécifier tout certificat d'autorité de certification approuvé par le proxy lors de l'installation. Par exemple :
$ cat install-config.yaml
Exemple de sortie
...
proxy:
httpProxy: http://<https://username:password@proxy.example.com:123/>
httpsProxy: https://<https://username:password@proxy.example.com:123/>
noProxy: <123.example.com,10.88.0.0/16>
additionalTrustBundle: |
-----BEGIN CERTIFICATE-----
<MY_HTTPS_PROXY_TRUSTED_CA_CERT>
-----END CERTIFICATE-----
...
4.2.3. Location
L'ensemble de confiance fourni par l'utilisateur est représenté sous la forme d'une carte de configuration. La carte de configuration est montée dans le système de fichiers des composants de la plate-forme qui effectuent des appels HTTPS de sortie. En règle générale, les opérateurs montent la carte de configuration sur /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, mais cela n'est pas exigé par le proxy. Un proxy peut modifier ou inspecter la connexion HTTPS. Dans les deux cas, il doit générer et signer un nouveau certificat pour la connexion.
La prise en charge complète du proxy signifie que l'on se connecte au proxy spécifié et que l'on fait confiance à toutes les signatures qu'il a générées. Il est donc nécessaire de permettre à l'utilisateur de spécifier une racine de confiance, de sorte que toute chaîne de certificats connectée à cette racine de confiance soit également fiable.
Si vous utilisez l'ensemble de confiance RHCOS, placez les certificats d'autorité de certification à l'adresse /etc/pki/ca-trust/source/anchors.
Pour plus d'informations, reportez-vous à la section Utilisation de certificats de système partagés dans la documentation de Red Hat Enterprise Linux.
4.2.4. Expiration
L'utilisateur définit la durée d'expiration de l'ensemble de confiance fourni par l'utilisateur.
Le délai d'expiration par défaut est défini par le certificat de l'autorité de certification lui-même. Il appartient à l'administrateur de l'autorité de certification de la configurer pour le certificat avant qu'il ne puisse être utilisé par OpenShift Container Platform ou RHCOS.
Red Hat ne surveille pas l'expiration des AC. Cependant, en raison de la longue durée de vie des AC, ce n'est généralement pas un problème. Cependant, il se peut que vous deviez périodiquement mettre à jour l'ensemble de confiance.
4.2.5. Services
Par défaut, tous les composants de la plate-forme qui effectuent des appels HTTPS sortants utiliseront l'ensemble de confiance RHCOS. Si trustedCA est défini, il sera également utilisé.
Tout service fonctionnant sur le nœud RHCOS peut utiliser l'ensemble de confiance du nœud.
4.2.6. Management
Ces certificats sont gérés par le système et non par l'utilisateur.
4.2.7. Personnalisation
La mise à jour de l'ensemble de confiance fourni par l'utilisateur consiste soit à
-
mise à jour des certificats codés en PEM dans la carte de configuration référencée par
trustedCA,ou -
création d'une carte de configuration dans l'espace de noms
openshift-configqui contient le nouveau paquet de confiance et mise à jour detrustedCApour faire référence au nom de la nouvelle carte de configuration.
Le mécanisme d'écriture des certificats CA dans le trust bundle du RHCOS est exactement le même que l'écriture de n'importe quel autre fichier dans le RHCOS, qui se fait par l'utilisation de configs de machine. Lorsque l'opérateur de configuration de machine (MCO) applique la nouvelle configuration de machine qui contient les nouveaux certificats d'autorité de certification, le nœud est redémarré. Lors du prochain redémarrage, le service coreos-update-ca-trust.service s'exécute sur les nœuds du RHCOS, qui mettent automatiquement à jour le trust bundle avec les nouveaux certificats d'autorité de certification. Par exemple :
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 50-examplecorp-ca-cert
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
mode: 0644
overwrite: true
path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crtLe registre de confiance des machines doit également permettre de mettre à jour le registre de confiance des nœuds.
4.2.8. Renouvellement
Aucun opérateur ne peut renouveler automatiquement les certificats sur les nœuds RHCOS.
Red Hat ne surveille pas l'expiration des AC. Cependant, en raison de la longue durée de vie des AC, ce n'est généralement pas un problème. Cependant, il se peut que vous deviez périodiquement mettre à jour l'ensemble de confiance.
