3.10. Des secrets de certificat de service
Les secrets de certificat de service sont destinés à prendre en charge les applications complexes de middleware qui ont besoin de certificats out-of-the-box. Il a les mêmes paramètres que les certificats de serveur générés par l’outil administrateur pour les nœuds et les maîtres.
Procédure
Afin de sécuriser la communication à votre service, demandez au cluster de générer une paire de certificats / clé de service signée dans un secret dans votre espace de noms.
Définissez l’annotation de nom service.beta.openshift.io/serving-cert-secret sur votre service avec la valeur définie au nom que vous souhaitez utiliser pour votre secret.
Ensuite, votre PodSpec peut monter ce secret. Lorsqu’il est disponible, votre pod fonctionne. Le certificat est bon pour le service interne DNS nom, <service.name>.<service.namespace>.svc.
Le certificat et la clé sont au format PEM, stockés respectivement dans tls.crt et tls.key. La paire de certificats/clés est automatiquement remplacée lorsqu’elle est proche de l’expiration. Afficher la date d’expiration dans le service.beta.openshift.io/expiry annotation sur le secret, qui est au format RFC3339.
Dans la plupart des cas, le nom DNS du service <service.name>.<service.namespace>.svc n’est pas routable à l’extérieur. L’utilisation principale de <service.name>.<service.namespace>.svc est pour la communication intracluster ou intraservice, et avec re-crypter les routes.
D’autres pods peuvent faire confiance aux certificats créés en cluster, qui ne sont signés que pour les noms DNS internes, en utilisant le paquet d’autorité de certification (CA) dans le fichier /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt qui est automatiquement monté dans leur pod.
L’algorithme de signature de cette fonctionnalité est x509.SHA256WithRSA. Afin de tourner manuellement, supprimer le secret généré. Création d’un nouveau certificat.