Rechercher

16.3. Gestion des clés de chiffrement du serveur Tang

download PDF

Le mécanisme cryptographique permettant de recréer la clé de chiffrement est basé sur le site blinded key stocké sur le nœud et sur la clé privée des serveurs Tang concernés. Pour se protéger contre la possibilité qu'un attaquant obtienne à la fois la clé privée du serveur Tang et le disque crypté du nœud, il est conseillé de recréer périodiquement une clé.

Vous devez effectuer l'opération de renouvellement de clé pour chaque nœud avant de pouvoir supprimer l'ancienne clé du serveur Tang. Les sections suivantes décrivent les procédures de recodage et de suppression des anciennes clés.

16.3.1. Sauvegarde des clés d'un serveur Tang

Le serveur Tang utilise /usr/libexec/tangd-keygen pour générer de nouvelles clés et les stocke par défaut dans le répertoire /var/db/tang. Pour récupérer le serveur Tang en cas de panne, sauvegardez ce répertoire. Les clés sont sensibles et, comme elles sont capables d'effectuer le décryptage du disque de démarrage de tous les hôtes qui les ont utilisées, elles doivent être protégées en conséquence.

Procédure

  • Copiez la clé de sauvegarde du répertoire /var/db/tang dans le répertoire temp à partir duquel vous pouvez restaurer la clé.

16.3.2. Récupération des clés d'un serveur Tang

Vous pouvez récupérer les clés d'un serveur Tang en accédant aux clés d'une sauvegarde.

Procédure

  • Restaurer la clé de votre dossier de sauvegarde dans le répertoire /var/db/tang/.

    Lorsque le serveur Tang démarre, il annonce et utilise ces clés restaurées.

16.3.3. Remise en service des serveurs Tang

Cette procédure utilise comme exemple un ensemble de trois serveurs Tang, chacun avec des clés uniques.

L'utilisation de serveurs Tang redondants réduit les risques d'échec du démarrage automatique des nœuds.

Le recodage d'un serveur Tang et de tous les nœuds chiffrés NBDE associés est une procédure en trois étapes.

Conditions préalables

  • Une installation fonctionnelle de Network-Bound Disk Encryption (NBDE) sur un ou plusieurs nœuds.

Procédure

  1. Générer une nouvelle clé de serveur Tang.
  2. Recomposer la clé de tous les nœuds chiffrés par l'EDNB de manière à ce qu'ils utilisent la nouvelle clé.
  3. Supprimer l'ancienne clé du serveur Tang.

    Note

    La suppression de l'ancienne clé avant que tous les nœuds chiffrés par l'EDNB n'aient terminé leur remise en clé entraîne une dépendance excessive de ces nœuds à l'égard de tout autre serveur Tang configuré.

Figure 16.1. Exemple de flux de travail pour le changement de clé d'un serveur Tang

Rekeying a Tang server

16.3.3.1. Générer une nouvelle clé de serveur Tang

Conditions préalables

  • Un shell root sur la machine Linux qui exécute le serveur Tang.
  • Pour faciliter la vérification de la rotation des clés du serveur Tang, cryptez un petit fichier test avec l'ancienne clé :

    # echo plaintext | clevis encrypt tang '{"url":"http://localhost:7500"}' -y >/tmp/encrypted.oldkey
  • Vérifiez que le cryptage a réussi et que le fichier peut être décrypté pour produire la même chaîne plaintext:

    # clevis decrypt </tmp/encrypted.oldkey

Procédure

  1. Localisez et accédez au répertoire qui stocke la clé du serveur Tang. Il s'agit généralement du répertoire /var/db/tang. Vérifiez l'empreinte de la clé actuellement annoncée :

    # tang-show-keys 7500

    Exemple de sortie

    36AHjNH3NZDSnlONLz1-V4ie6t8

  2. Entrez le répertoire des clés du serveur Tang :

    # cd /var/db/tang/
  3. Liste des clés actuelles du serveur Tang :

    # ls -A1

    Exemple de sortie

    36AHjNH3NZDSnlONLz1-V4ie6t8.jwk
    gJZiNPMLRBnyo_ZKfK4_5SrnHYo.jwk

    Lors du fonctionnement normal du serveur Tang, ce répertoire contient deux fichiers .jwk: l'un pour la signature et la vérification, l'autre pour la dérivation des clés.

  4. Désactiver la publicité des anciennes clés :

    # for key in *.jwk; do \
      mv -- "$key" ".$key"; \
    done

    Les nouveaux clients qui configurent le cryptage des disques liés au réseau (NBDE) ou qui demandent des clés ne verront plus les anciennes clés. Les clients existants peuvent toujours accéder aux anciennes clés et les utiliser jusqu'à ce qu'elles soient supprimées. Le serveur Tang lit les clés stockées dans les fichiers cachés UNIX, qui commencent par le caractère ., mais n'en fait pas la publicité.

  5. Générer une nouvelle clé :

    # /usr/libexec/tangd-keygen /var/db/tang
  6. Lister les clés actuelles du serveur Tang pour vérifier que les anciennes clés ne sont plus annoncées, car elles sont désormais des fichiers cachés, et que de nouvelles clés sont présentes :

    # ls -A1

    Exemple de sortie

    .36AHjNH3NZDSnlONLz1-V4ie6t8.jwk
    .gJZiNPMLRBnyo_ZKfK4_5SrnHYo.jwk
    Bp8XjITceWSN_7XFfW7WfJDTomE.jwk
    WOjQYkyK7DxY_T5pMncMO5w0f6E.jwk

    Tang annonce automatiquement les nouvelles clés.

    Note

    Les installations plus récentes du serveur Tang comprennent un répertoire d'aide /usr/libexec/tangd-rotate-keys qui se charge de désactiver la publicité et de générer les nouvelles clés simultanément.

  7. Si vous utilisez plusieurs serveurs Tang derrière un équilibreur de charge qui partagent le même matériel clé, assurez-vous que les modifications apportées ici sont correctement synchronisées sur l'ensemble des serveurs avant de continuer.

Vérification

  1. Vérifiez que le serveur Tang annonce la nouvelle clé et non l'ancienne :

    # tang-show-keys 7500

    Exemple de sortie

    WOjQYkyK7DxY_T5pMncMO5w0f6E

  2. Vérifiez que l'ancienne clé, bien qu'elle ne soit pas annoncée, est toujours disponible pour les demandes de déchiffrement :

    # clevis decrypt </tmp/encrypted.oldkey

16.3.3.2. Recomposition de tous les nœuds de l'EDNB

Vous pouvez recléer tous les nœuds d'un cluster distant à l'aide d'un objet DaemonSet sans que le cluster distant ne subisse de temps d'arrêt.

Note

Si un nœud perd de l'énergie pendant le rekeying, il est possible qu'il devienne non amorçable et qu'il doive être redéployé via Red Hat Advanced Cluster Management (RHACM) ou un pipeline GitOps.

Conditions préalables

  • cluster-admin à tous les clusters dotés de nœuds NBDE (Network-Bound Disk Encryption).
  • Tous les serveurs Tang doivent être accessibles à chaque nœud de l'EDNB lors du renouvellement des clés, même si les clés d'un serveur Tang n'ont pas changé.
  • Obtenir l'URL du serveur Tang et l'empreinte de la clé pour chaque serveur Tang.

Procédure

  1. Créez un objet DaemonSet basé sur le modèle suivant. Ce modèle met en place trois serveurs Tang redondants, mais peut être facilement adapté à d'autres situations. Modifiez les URL et les empreintes des serveurs Tang dans l'environnement NEW_TANG_PIN pour les adapter à votre environnement :

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: tang-rekey
      namespace: openshift-machine-config-operator
    spec:
      selector:
        matchLabels:
          name: tang-rekey
      template:
        metadata:
          labels:
            name: tang-rekey
        spec:
          containers:
          - name: tang-rekey
            image: registry.access.redhat.com/ubi8/ubi-minimal:8.4
            imagePullPolicy: IfNotPresent
            command:
            - "/sbin/chroot"
            - "/host"
            - "/bin/bash"
            - "-ec"
            args:
            - |
              rm -f /tmp/rekey-complete || true
              echo "Current tang pin:"
              clevis-luks-list -d $ROOT_DEV -s 1
              echo "Applying new tang pin: $NEW_TANG_PIN"
              clevis-luks-edit -f -d $ROOT_DEV -s 1 -c "$NEW_TANG_PIN"
              echo "Pin applied successfully"
              touch /tmp/rekey-complete
              sleep infinity
            readinessProbe:
              exec:
                command:
                - cat
                - /host/tmp/rekey-complete
              initialDelaySeconds: 30
              periodSeconds: 10
            env:
            - name: ROOT_DEV
              value: /dev/disk/by-partlabel/root
            - name: NEW_TANG_PIN
              value: >-
                {"t":1,"pins":{"tang":[
                  {"url":"http://tangserver01:7500","thp":"WOjQYkyK7DxY_T5pMncMO5w0f6E"},
                  {"url":"http://tangserver02:7500","thp":"I5Ynh2JefoAO3tNH9TgI4obIaXI"},
                  {"url":"http://tangserver03:7500","thp":"38qWZVeDKzCPG9pHLqKzs6k1ons"}
                ]}}
            volumeMounts:
            - name: hostroot
              mountPath: /host
            securityContext:
              privileged: true
          volumes:
          - name: hostroot
            hostPath:
              path: /
          nodeSelector:
            kubernetes.io/os: linux
          priorityClassName: system-node-critical
          restartPolicy: Always
          serviceAccount: machine-config-daemon
          serviceAccountName: machine-config-daemon

    Dans ce cas, même s'il s'agit d'une nouvelle clé pour tangserver01, vous devez spécifier non seulement la nouvelle empreinte de tangserver01, mais aussi les empreintes actuelles de tous les autres serveurs Tang. Le fait de ne pas spécifier toutes les empreintes pour une opération de recomposition de clé ouvre la voie à une attaque de type "man-in-the-middle".

  2. Pour distribuer le jeu de démons à tous les clusters qui doivent être recodés, exécutez la commande suivante :

    $ oc apply -f tang-rekey.yaml

    Cependant, pour fonctionner à l'échelle, il faut envelopper l'ensemble de démons dans une politique ACM. Cette configuration ACM doit contenir une politique pour déployer l'ensemble de démons, une deuxième politique pour vérifier que tous les pods de l'ensemble de démons sont PRÊTS, et une règle de placement pour l'appliquer à l'ensemble approprié de clusters.

Note

Après avoir vérifié que l'ensemble de démons a réussi à recoder tous les serveurs, supprimez l'ensemble de démons. Si vous ne supprimez pas le jeu de démons, il doit l'être avant la prochaine opération de recomposition de clés.

Vérification

Après avoir distribué le jeu de démons, surveillez les jeux de démons pour vous assurer que la reconnexion s'est bien déroulée. Le script de l'exemple de jeu de démons se termine par une erreur si le rechargement a échoué, et reste dans l'état CURRENT s'il a réussi. Il existe également une sonde de préparation qui marque le pod comme READY lorsque le rekeying a été effectué avec succès.

  • Voici un exemple de liste de sortie pour l'ensemble de démons avant que la recomposition des clés ne soit terminée :

    $ oc get -n openshift-machine-config-operator ds tang-rekey

    Exemple de sortie

    NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
    tang-rekey   1         1         0       1            0           kubernetes.io/os=linux   11s

  • Voici un exemple de liste de sortie pour l'ensemble de démons après que la recomposition des clés a été effectuée avec succès :

    $ oc get -n openshift-machine-config-operator ds tang-rekey

    Exemple de sortie

    NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
    tang-rekey   1         1         1       1            1           kubernetes.io/os=linux   13h

La recomposition de la clé ne prend généralement que quelques minutes.

Note

Si vous utilisez des stratégies ACM pour distribuer les ensembles de démons à plusieurs clusters, vous devez inclure une stratégie de conformité qui vérifie que le compte READY de chaque ensemble de démons est égal au compte DESIRED. De cette façon, la conformité à une telle politique démontre que tous les pods de l'ensemble démon sont READY et que le rekeying s'est déroulé avec succès. Vous pouvez également utiliser une recherche ACM pour interroger tous les états des ensembles de démons.

16.3.3.3. Dépannage des erreurs de recomposition temporaire des clés pour les serveurs Tang

Pour déterminer si la condition d'erreur liée à la recomposition des clés des serveurs Tang est temporaire, procédez comme suit. Les conditions d'erreur temporaires peuvent être les suivantes

  • Interruptions temporaires du réseau
  • Maintenance du serveur Tang

En général, lorsque ce type d'erreur temporaire se produit, vous pouvez attendre que l'ensemble de démons parvienne à résoudre l'erreur ou vous pouvez supprimer l'ensemble de démons et ne pas réessayer tant que l'erreur temporaire n'a pas été résolue.

Procédure

  1. Redémarrez le pod qui effectue l'opération de remise en clé à l'aide de la politique normale de redémarrage des pods de Kubernetes.
  2. Si l'un des serveurs Tang associés n'est pas disponible, essayez d'établir une nouvelle clé jusqu'à ce que tous les serveurs soient de nouveau en ligne.

16.3.3.4. Dépannage des erreurs de recomposition permanente des clés pour les serveurs Tang

Si, après la remise en service des serveurs Tang, le nombre de READY n'est pas égal au nombre de DESIRED après une période prolongée, cela peut indiquer une condition de défaillance permanente. Dans ce cas, les conditions suivantes peuvent s'appliquer :

  • Une erreur typographique dans l'URL du serveur Tang ou dans l'empreinte de la définition de NEW_TANG_PIN.
  • Le serveur Tang est mis hors service ou les clés sont définitivement perdues.

Conditions préalables

  • Les commandes présentées dans cette procédure peuvent être exécutées sur le serveur Tang ou sur tout système Linux ayant un accès réseau au serveur Tang.

Procédure

  1. Validez la configuration du serveur Tang en effectuant une simple opération de cryptage et de décryptage sur la configuration de chaque serveur Tang, telle qu'elle est définie dans le jeu de démons.

    Voici un exemple de tentative de cryptage et de décryptage avec une mauvaise empreinte :

    $ echo "okay" | clevis encrypt tang \
      '{"url":"http://tangserver02:7500","thp":"badthumbprint"}' | \
      clevis decrypt

    Exemple de sortie

    Unable to fetch advertisement: 'http://tangserver02:7500/adv/badthumbprint'!

    Voici un exemple de tentative de cryptage et de décryptage avec une bonne empreinte :

    $ echo "okay" | clevis encrypt tang \
      '{"url":"http://tangserver03:7500","thp":"goodthumbprint"}' | \
      clevis decrypt

    Exemple de sortie

    okay

  2. Après avoir identifié la cause première, il faut remédier à la situation sous-jacente :

    1. Supprimer le jeu de démons qui ne fonctionne pas.
    2. Modifiez la définition du jeu de démons pour résoudre le problème sous-jacent. Il peut s'agir de l'une des actions suivantes :

      • Modifier l'entrée d'un serveur Tang pour corriger l'URL et l'empreinte.
      • Supprimer un serveur Tang qui n'est plus en service.
      • Ajouter un nouveau serveur Tang en remplacement d'un serveur déclassé.
  3. Distribuer à nouveau le jeu de démons mis à jour.
Note

Lors du remplacement, de la suppression ou de l'ajout d'un serveur Tang dans une configuration, l'opération de reconnexion réussit si au moins un serveur d'origine est encore fonctionnel, y compris le serveur en cours de reconnexion. Si aucun des serveurs Tang d'origine n'est fonctionnel ou ne peut être récupéré, la récupération du système est impossible et vous devez redéployer les nœuds concernés.

Vérification

Vérifiez les journaux de chaque module de l'ensemble de démons pour déterminer si la recomposition s'est déroulée correctement. En cas d'échec, les journaux peuvent indiquer une condition d'échec.

  1. Localisez le nom du conteneur qui a été créé par l'ensemble de démons :

    $ oc get pods -A | grep tang-rekey

    Exemple de sortie

    openshift-machine-config-operator  tang-rekey-7ks6h  1/1  Running   20 (8m39s ago)  89m

  2. Imprimez les journaux du conteneur. Le journal suivant est celui d'une opération de recomposition de clé réussie :

    $ oc logs tang-rekey-7ks6h

    Exemple de sortie

    Current tang pin:
    1: sss '{"t":1,"pins":{"tang":[{"url":"http://10.46.55.192:7500"},{"url":"http://10.46.55.192:7501"},{"url":"http://10.46.55.192:7502"}]}}'
    Applying new tang pin: {"t":1,"pins":{"tang":[
      {"url":"http://tangserver01:7500","thp":"WOjQYkyK7DxY_T5pMncMO5w0f6E"},
      {"url":"http://tangserver02:7500","thp":"I5Ynh2JefoAO3tNH9TgI4obIaXI"},
      {"url":"http://tangserver03:7500","thp":"38qWZVeDKzCPG9pHLqKzs6k1ons"}
    ]}}
    Updating binding...
    Binding edited successfully
    Pin applied successfully

16.3.4. Suppression des anciennes clés du serveur Tang

Conditions préalables

  • Un shell root sur la machine Linux qui exécute le serveur Tang.

Procédure

  1. Localisez et accédez au répertoire où la clé du serveur Tang est stockée. Il s'agit généralement du répertoire /var/db/tang:

    # cd /var/db/tang/
  2. Liste des clés actuelles du serveur Tang, indiquant les clés annoncées et non annoncées :

    # ls -A1

    Exemple de sortie

    .36AHjNH3NZDSnlONLz1-V4ie6t8.jwk
    .gJZiNPMLRBnyo_ZKfK4_5SrnHYo.jwk
    Bp8XjITceWSN_7XFfW7WfJDTomE.jwk
    WOjQYkyK7DxY_T5pMncMO5w0f6E.jwk

  3. Supprimer les anciennes clés :

    # rm .*.jwk
  4. Dresser la liste des clés actuelles du serveur Tang pour vérifier que les clés non annoncées ne sont plus présentes :

    # ls -A1

    Exemple de sortie

    Bp8XjITceWSN_7XFfW7WfJDTomE.jwk
    WOjQYkyK7DxY_T5pMncMO5w0f6E.jwk

Vérification

À ce stade, le serveur annonce toujours les nouvelles clés, mais toute tentative de décryptage sur la base de l'ancienne clé échoue.

  1. Demande au serveur Tang les empreintes de clés actuellement annoncées :

    # tang-show-keys 7500

    Exemple de sortie

    WOjQYkyK7DxY_T5pMncMO5w0f6E

  2. Décrypter le fichier test créé précédemment pour vérifier que le décryptage avec les anciennes clés échoue :

    # clevis decrypt </tmp/encryptValidation

    Exemple de sortie

    Error communicating with the server!

Si vous utilisez plusieurs serveurs Tang derrière un équilibreur de charge qui partagent le même matériel clé, assurez-vous que les modifications apportées sont correctement synchronisées sur l'ensemble des serveurs avant de poursuivre.

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.

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

© 2024 Red Hat, Inc.