Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

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
Copier lien

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.

Note

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; \
      done
Copy to Clipboard Toggle word wrap

3.3.2. Ajouter un certificat de service
Copier lien

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.

Important

É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

  1. 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
    Copy to Clipboard Toggle word wrap
    1
    Remplacez <service_name> par le nom du service à sécuriser.
    2
    <secret_name> sera le nom du secret généré contenant le certificat et la paire de clés. Pour des raisons de commodité, il est recommandé que ce nom soit le même que celui de <service_name>.

    Par exemple, utilisez la commande suivante pour annoter le service test1: 

    $ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1
    Copy to Clipboard Toggle word wrap

  2. Examinez le service pour confirmer que les annotations sont présentes : 

    oc describe service <service_name> $ oc describe service <service_name>
    Copy to Clipboard Toggle word wrap

    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
...
    Copy to Clipboard Toggle word wrap

  3. Une fois que le cluster a généré un secret pour votre service, votre spec Pod peut le monter, et le pod s'exécutera dès qu'il sera disponible.

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.

Important

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

  1. 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
    Copy to Clipboard Toggle word wrap
    1
    Remplacez <config_map_name> par le nom de la carte de configuration à annoter.
    Note

    Le fait de référencer explicitement la clé service-ca.crt dans 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 champ optional sur true pour 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
    Copy to Clipboard Toggle word wrap

  2. Affichez la carte de configuration pour vous assurer que le service CA bundle a été injecté : 

    oc get configmap <config_map_name> -o yaml
    Copy to Clipboard Toggle word wrap

    La liasse d'AC est affichée en tant que valeur de la clé service-ca.crt dans la sortie YAML : 

    apiVersion: v1
data:
  service-ca.crt: |
    -----BEGIN CERTIFICATE-----
...
    Copy to Clipboard Toggle word wrap

3.3.4. Ajouter le service CA bundle à un service API
Copier lien

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

  1. 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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

  2. Affichez le service API pour vous assurer que le service CA bundle a été injecté : 

    oc get apiservice <api_service_name> -o yaml
    Copy to Clipboard Toggle word wrap

    L'ensemble de CA est affiché dans le champ spec.caBundle de la sortie YAML : 

    apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  annotations:
    service.beta.openshift.io/inject-cabundle: "true"
...
spec:
  caBundle: <CA_BUNDLE>
...
    Copy to Clipboard Toggle word wrap

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é.

Note

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

  1. Annoter le CRD avec service.beta.openshift.io/inject-cabundle=true: 

    $ oc annotate crd <crd_name> \
    1 
    
     service.beta.openshift.io/inject-cabundle=true
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

  2. Consultez le CRD pour vous assurer que le paquet d'AC de service a bien été injecté : 

    oc get crd <crd_name> -o yaml
    Copy to Clipboard Toggle word wrap

    L'ensemble de CA est affiché dans le champ spec.conversion.webhook.clientConfig.caBundle de 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>
...
    Copy to Clipboard Toggle word wrap

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é.

Note

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

  1. 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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

  2. 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
    Copy to Clipboard Toggle word wrap

    Le bundle CA est affiché dans le champ clientConfig.caBundle de 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>
...
    Copy to Clipboard Toggle word wrap

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é.

Note

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

  1. 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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

  2. 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
    Copy to Clipboard Toggle word wrap

    Le bundle CA est affiché dans le champ clientConfig.caBundle de 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>
...
    Copy to Clipboard Toggle word wrap

3.3.8. Rotation manuelle du certificat de service généré
Copier lien

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

  1. 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>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    ...
service.beta.openshift.io/serving-cert-secret-name: <secret>
...
    Copy to Clipboard Toggle word wrap

  2. 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
    Copy to Clipboard Toggle word wrap
    1
    Remplacez <secret> par le nom du secret de l'étape précédente.

  3. Confirmez que le certificat a été recréé en obtenant le nouveau secret et en examinant le site AGE. 

    oc get secret <service_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME              TYPE                DATA   AGE
<service.name>    kubernetes.io/tls   2      1s
    Copy to Clipboard Toggle word wrap

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.

Avertissement

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

  1. 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 -enddate
    Copy to Clipboard Toggle word wrap

  2. Rotation 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
    Copy to Clipboard Toggle word wrap

  3. 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; \
      done
    Copy to Clipboard Toggle word wrap
    Avertissement

    Cette 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.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat