3.3. Sécurisation du trafic des services à l'aide de secrets de certificats de service
3.3.1. Comprendre les certificats de service après-vente
Les certificats de service sont destinés à prendre en charge des applications intermédiaires complexes nécessitant un chiffrement. Ces certificats sont émis en tant que certificats de serveur web TLS.
Le contrôleur service-ca utilise l'algorithme de signature x509.SHA256WithRSA pour générer des certificats de service.
Le certificat et la clé générés sont au format PEM, stockés respectivement dans tls.crt et tls.key, au sein d'un secret créé. Le certificat et la clé sont automatiquement remplacés lorsqu'ils sont proches de l'expiration.
Le certificat de l'autorité de certification de service, qui émet les certificats de service, est valable 26 mois et fait l'objet d'une rotation automatique lorsqu'il reste moins de 13 mois de validité. Après la rotation, la configuration précédente de l'AC de service reste fiable jusqu'à son expiration. Cela permet à tous les services concernés de bénéficier d'une période de grâce pour actualiser leur matériel de clés avant l'expiration. Si vous ne mettez pas à niveau votre cluster pendant cette période de grâce, qui redémarre les services et actualise leurs clés, vous devrez peut-être redémarrer manuellement les services pour éviter les défaillances après l'expiration de l'ancienne autorité de certification.
Vous pouvez utiliser la commande suivante pour redémarrer manuellement tous les modules du cluster. Sachez que l'exécution de cette commande entraîne une interruption de service, car elle supprime tous les modules en cours d'exécution dans chaque espace de noms. Ces modules redémarreront automatiquement après avoir été supprimés.
$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
do oc delete pods --all -n $I; \
sleep 1; \
done3.3.2. Ajouter un certificat de service
Pour sécuriser la communication avec votre service, générez un certificat de service signé et une paire de clés dans un secret dans le même espace de noms que le service.
Le certificat généré n'est valable que pour le nom DNS du service interne <service.name>.<service.namespace>.svc, et n'est valable que pour les communications internes. Si votre service est un service headless (pas de valeur clusterIP définie), le certificat généré contient également un sujet joker au format *.<service.name>.<service.namespace>.svc.
Étant donné que les certificats générés contiennent des caractères génériques pour les services sans tête, vous ne devez pas utiliser l'autorité de certification de service si votre client doit faire la distinction entre les différents modules. Dans ce cas :
- Générer des certificats TLS individuels en utilisant une autre autorité de certification.
- N'acceptez pas l'autorité de certification de service comme autorité de certification de confiance pour les connexions qui sont dirigées vers des modules individuels et qui ne doivent pas être personnalisées par d'autres modules. Ces connexions doivent être configurées pour faire confiance à l'autorité de certification utilisée pour générer les certificats TLS individuels.
Prérequis :
- Un service doit être défini.
Procédure
Annoter le service avec
service.beta.openshift.io/serving-cert-secret-name:$ oc annotate service <service_name> \1 service.beta.openshift.io/serving-cert-secret-name=<secret_name> 2
Par exemple, utilisez la commande suivante pour annoter le service
test1:$ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1
Examinez le service pour confirmer que les annotations sont présentes :
oc describe service <service_name> $ oc describe service <service_name>
Exemple de sortie
... Annotations: service.beta.openshift.io/serving-cert-secret-name: <service_name> service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837 ...-
Une fois que le cluster a généré un secret pour votre service, votre spec
Podpeut le monter, et le pod s'exécutera dès qu'il sera disponible.
Ressources supplémentaires
- Vous pouvez utiliser un certificat de service pour configurer un itinéraire sécurisé à l'aide de la terminaison TLS reencrypt. Pour plus d'informations, voir Création d'un itinéraire reencrypt avec un certificat personnalisé.
3.3.3. Ajouter le service CA bundle à une carte de configuration
Un pod peut accéder au certificat de l'autorité de certification de service en montant un objet ConfigMap qui est annoté avec service.beta.openshift.io/inject-cabundle=true. Une fois annoté, le cluster injecte automatiquement le certificat de l'autorité de certification de service dans la clé service-ca.crt de la carte de configuration. L'accès à ce certificat CA permet aux clients TLS de vérifier les connexions aux services utilisant des certificats de service.
Après avoir ajouté cette annotation à une carte de configuration, toutes les données existantes sont supprimées. Il est recommandé d'utiliser une carte de configuration séparée pour contenir le site service-ca.crt, plutôt que d'utiliser la même carte de configuration que celle qui stocke la configuration de votre pod.
Procédure
Annoter la carte de configuration avec
service.beta.openshift.io/inject-cabundle=true:$ oc annotate configmap <config_map_name> \1 service.beta.openshift.io/inject-cabundle=true- 1
- Remplacez
<config_map_name>par le nom de la carte de configuration à annoter.
NoteLe fait de référencer explicitement la clé
service-ca.crtdans un montage de volume empêchera un pod de démarrer jusqu'à ce que la carte de configuration ait été injectée avec le bundle de l'autorité de certification. Ce comportement peut être modifié en définissant le champoptionalsurtruepour la configuration du certificat de service du volume.Par exemple, la commande suivante permet d'annoter la carte config
test1:$ oc annotate configmap test1 service.beta.openshift.io/inject-cabundle=true
Affichez la carte de configuration pour vous assurer que le service CA bundle a été injecté :
oc get configmap <config_map_name> -o yaml
La liasse d'AC est affichée en tant que valeur de la clé
service-ca.crtdans la sortie YAML :apiVersion: v1 data: service-ca.crt: | -----BEGIN CERTIFICATE----- ...
3.3.4. Ajouter le service CA bundle à un service API
Vous pouvez annoter un objet APIService avec service.beta.openshift.io/inject-cabundle=true pour que son champ spec.caBundle soit rempli avec le service CA bundle. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.
Procédure
Annoter le service API avec
service.beta.openshift.io/inject-cabundle=true:$ oc annotate apiservice <api_service_name> \1 service.beta.openshift.io/inject-cabundle=true- 1
- Remplacez
<api_service_name>par le nom du service API à annoter.
Par exemple, utilisez la commande suivante pour annoter le service API
test1:$ oc annotate apiservice test1 service.beta.openshift.io/inject-cabundle=true
Affichez le service API pour vous assurer que le service CA bundle a été injecté :
oc get apiservice <api_service_name> -o yaml
L'ensemble de CA est affiché dans le champ
spec.caBundlede la sortie YAML :apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: annotations: service.beta.openshift.io/inject-cabundle: "true" ... spec: caBundle: <CA_BUNDLE> ...
3.3.5. Ajouter le service CA bundle à une définition de ressource personnalisée
Vous pouvez annoter un objet CustomResourceDefinition (CRD) avec service.beta.openshift.io/inject-cabundle=true pour que son champ spec.conversion.webhook.clientConfig.caBundle soit rempli avec le bundle de l'autorité de certification de service. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.
Le service CA bundle ne sera injecté dans le CRD que si le CRD est configuré pour utiliser un webhook pour la conversion. Il n'est utile d'injecter le service CA bundle que si le webhook d'un CRD est sécurisé par un certificat de l'AC de service.
Procédure
Annoter le CRD avec
service.beta.openshift.io/inject-cabundle=true:$ oc annotate crd <crd_name> \1 service.beta.openshift.io/inject-cabundle=true- 1
- Remplacer
<crd_name>par le nom du CRD à annoter.
Par exemple, utilisez la commande suivante pour annoter le CRD
test1:$ oc annotate crd test1 service.beta.openshift.io/inject-cabundle=true
Consultez le CRD pour vous assurer que le paquet d'AC de service a bien été injecté :
oc get crd <crd_name> -o yaml
L'ensemble de CA est affiché dans le champ
spec.conversion.webhook.clientConfig.caBundlede la sortie YAML :apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: service.beta.openshift.io/inject-cabundle: "true" ... spec: conversion: strategy: Webhook webhook: clientConfig: caBundle: <CA_BUNDLE> ...
3.3.6. Ajouter le service CA bundle à une configuration webhook mutante
Vous pouvez annoter un objet MutatingWebhookConfiguration avec service.beta.openshift.io/inject-cabundle=true pour que le champ clientConfig.caBundle de chaque webhook soit rempli avec le service CA bundle. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.
Ne définissez pas cette annotation pour les configurations de webhooks d'admission qui doivent spécifier différents groupes d'autorités de certification pour différents webhooks. Si vous le faites, l'ensemble d'AC de service sera injecté pour tous les webhooks.
Procédure
Annoter la configuration du webhook en mutation avec
service.beta.openshift.io/inject-cabundle=true:$ oc annotate mutatingwebhookconfigurations <mutating_webhook_name> \1 service.beta.openshift.io/inject-cabundle=true- 1
- Remplacez
<mutating_webhook_name>par le nom de la configuration du webhook de mutation à annoter.
Par exemple, utilisez la commande suivante pour annoter la configuration du webhook de mutation
test1:$ oc annotate mutatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
Affichez la configuration du webhook de mutation pour vous assurer que le service CA bundle a été injecté :
oc get mutatingwebhookconfigurations <mutating_webhook_name> -o yaml
Le bundle CA est affiché dans le champ
clientConfig.caBundlede tous les webhooks dans la sortie YAML :apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration metadata: annotations: service.beta.openshift.io/inject-cabundle: "true" ... webhooks: - myWebhook: - v1beta1 clientConfig: caBundle: <CA_BUNDLE> ...
3.3.7. Ajouter le service CA bundle à une configuration de webhook de validation
Vous pouvez annoter un objet ValidatingWebhookConfiguration avec service.beta.openshift.io/inject-cabundle=true pour que le champ clientConfig.caBundle de chaque webhook soit rempli avec le service CA bundle. Cela permet au serveur API Kubernetes de valider le certificat de l'autorité de certification du service utilisé pour sécuriser le point de terminaison ciblé.
Ne définissez pas cette annotation pour les configurations de webhooks d'admission qui doivent spécifier différents groupes d'autorités de certification pour différents webhooks. Si vous le faites, l'ensemble d'AC de service sera injecté pour tous les webhooks.
Procédure
Annoter la configuration du webhook de validation avec
service.beta.openshift.io/inject-cabundle=true:$ oc annotate validatingwebhookconfigurations <validating_webhook_name> \1 service.beta.openshift.io/inject-cabundle=true- 1
- Remplacez
<validating_webhook_name>par le nom de la configuration du webhook de validation à annoter.
Par exemple, utilisez la commande suivante pour annoter la configuration du webhook de validation
test1:$ oc annotate validatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
Affichez la configuration du webhook de validation pour vous assurer que le service CA bundle a été injecté :
oc get validatingwebhookconfigurations <validating_webhook_name> -o yaml
Le bundle CA est affiché dans le champ
clientConfig.caBundlede tous les webhooks dans la sortie YAML :apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: annotations: service.beta.openshift.io/inject-cabundle: "true" ... webhooks: - myWebhook: - v1beta1 clientConfig: caBundle: <CA_BUNDLE> ...
3.3.8. Rotation manuelle du certificat de service généré
Vous pouvez faire pivoter le certificat de service en supprimant le secret associé. La suppression du secret entraîne la création automatique d'un nouveau secret, ce qui donne lieu à un nouveau certificat.
Conditions préalables
- Un secret contenant le certificat et la paire de clés doit avoir été généré pour le service.
Procédure
Examinez le service pour déterminer le secret contenant le certificat. Celui-ci se trouve dans l'annotation
serving-cert-secret-name, comme indiqué ci-dessous.oc describe service <service_name> $ oc describe service <service_name>
Exemple de sortie
... service.beta.openshift.io/serving-cert-secret-name: <secret> ...
Supprimer le secret généré pour le service. Ce processus recréera automatiquement le secret.
oc delete secret <secret> $ oc delete secret <secret> 1- 1
- Remplacez
<secret>par le nom du secret de l'étape précédente.
Confirmez que le certificat a été recréé en obtenant le nouveau secret et en examinant le site
AGE.oc get secret <service_name>
Exemple de sortie
NAME TYPE DATA AGE <service.name> kubernetes.io/tls 2 1s
3.3.9. Rotation manuelle du certificat de l'autorité de certification de service
L'AC de service est valable 26 mois et est automatiquement actualisé lorsqu'il reste moins de 13 mois de validité.
Si nécessaire, vous pouvez actualiser manuellement l'AC de service à l'aide de la procédure suivante.
Une AC de service à rotation manuelle ne maintient pas la confiance avec l'AC de service précédente. Vous risquez de subir une interruption de service temporaire jusqu'à ce que les pods du cluster soient redémarrés, ce qui garantit que les pods utilisent les certificats de service délivrés par la nouvelle autorité de certification de service.
Conditions préalables
- Vous devez être connecté en tant qu'administrateur de cluster.
Procédure
Affichez la date d'expiration du certificat de l'autorité de certification de service actuel à l'aide de la commande suivante.
$ oc get secrets/signing-key -n openshift-service-ca \ -o template='{{index .data "tls.crt"}}' \ | base64 --decode \ | openssl x509 -noout -enddateRotation manuelle de l'autorité de certification de service. Ce processus génère une nouvelle autorité de certification de service qui sera utilisée pour signer les nouveaux certificats de service.
$ oc delete secret/signing-key -n openshift-service-ca
Pour appliquer les nouveaux certificats à tous les services, redémarrez tous les pods de votre cluster. Cette commande garantit que tous les services utilisent les certificats mis à jour.
$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \ do oc delete pods --all -n $I; \ sleep 1; \ doneAvertissementCette commande provoque une interruption de service, car elle passe en revue et supprime tous les pods en cours d'exécution dans chaque espace de noms. Ces modules redémarreront automatiquement après avoir été supprimés.
