14.2. Configuration des jetons de compte de service lié à l'aide de la projection de volume

Procédure

1. Optionnel : Définir l'émetteur du compte de service.

   Cette étape n'est généralement pas nécessaire si les jetons liés ne sont utilisés qu'au sein du cluster.

   Important

   Si vous remplacez l'émetteur du compte de service par un émetteur personnalisé, l'émetteur précédent du compte de service reste fiable pendant les 24 heures suivantes.

   Vous pouvez forcer tous les détenteurs à demander un nouveau jeton lié soit en redémarrant manuellement tous les pods dans le cluster, soit en effectuant un redémarrage continu des nœuds. Avant d'effectuer l'une ou l'autre de ces actions, attendez qu'une nouvelle révision des pods du serveur API Kubernetes soit déployée avec les modifications de l'émetteur de votre compte de service.

   1. Modifier l'objet cluster Authentication :

      $ oc edit authentications cluster

   2. Réglez le champ spec.serviceAccountIssuer sur la valeur de l'émetteur du compte de service souhaité :

      spec:
        serviceAccountIssuer: https://test.default.svc 1

      1

      Cette valeur doit être une URL à partir de laquelle le destinataire d'un jeton lié peut obtenir les clés publiques nécessaires pour vérifier la signature du jeton. La valeur par défaut est https://kubernetes.default.svc.

   3. Enregistrez le fichier pour appliquer les modifications.

   4. Attendez qu'une nouvelle révision des pods de serveur de l'API Kubernetes soit déployée. La mise à jour de tous les nœuds vers la nouvelle révision peut prendre plusieurs minutes. Exécutez la commande suivante :

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

      Examinez la condition d'état NodeInstallerProgressing pour le serveur API Kubernetes afin de vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :

      AllNodesAtLatestRevision
      3 nodes are at revision 12 1

      1

      Dans cet exemple, le dernier numéro de révision est 12.

      Si la sortie affiche un message similaire à l'un des messages suivants, la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.

      • 3 nodes are at revision 11; 0 nodes have achieved new revision 12
      • 2 nodes are at revision 11; 1 nodes are at revision 12

   5. Facultatif : Forcer le détenteur à demander un nouveau jeton lié, soit en effectuant un redémarrage continu des nœuds, soit en redémarrant manuellement tous les pods du cluster.

      • Effectuer un redémarrage progressif du nœud :

        Avertissement

        Il n'est pas recommandé d'effectuer un redémarrage progressif des nœuds si des charges de travail personnalisées sont exécutées sur votre cluster, car cela peut entraîner une interruption de service. Au lieu de cela, redémarrez manuellement tous les pods du cluster.

        Redémarrer les nœuds de manière séquentielle. Attendez que le nœud soit entièrement disponible avant de redémarrer le nœud suivant. Voir Rebooting a node gracefully pour savoir comment drainer, redémarrer et marquer un nœud comme étant à nouveau planifiable.

      • Redémarrer manuellement tous les pods du cluster :

        Avertissement

        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.

        Exécutez la commande suivante :

        $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
              do oc delete pods --all -n $I; \
              sleep 1; \
              done

2. Configurer un pod pour utiliser un jeton de compte de service lié en utilisant la projection de volume.

   1. Créez un fichier appelé pod-projected-svc-token.yaml avec le contenu suivant :

      apiVersion: v1
      kind: Pod
      metadata:
        name: nginx
      spec:
        containers:
        - image: nginx
          name: nginx
          volumeMounts:
          - mountPath: /var/run/secrets/tokens
            name: vault-token
        serviceAccountName: build-robot 1
        volumes:
        - name: vault-token
          projected:
            sources:
            - serviceAccountToken:
                path: vault-token 2
                expirationSeconds: 7200 3
                audience: vault 4

      1

      Une référence à un compte de service existant.

      2

      Le chemin relatif au point de montage du fichier dans lequel le jeton doit être projeté.

      3

      Il est possible de définir l'expiration du jeton de compte de service, en secondes. La valeur par défaut est de 3600 secondes (1 heure) et doit être d'au moins 600 secondes (10 minutes). Le kubelet commencera à essayer de faire pivoter le jeton s'il a dépassé 80 % de sa durée de vie ou s'il a dépassé 24 heures.

      4

      Le destinataire du jeton doit vérifier que l'identité du destinataire correspond à la déclaration du jeton. Le destinataire d'un jeton doit vérifier que l'identité du destinataire correspond à l'audience déclarée du jeton, sinon il doit rejeter le jeton. Par défaut, l'audience est l'identifiant du serveur API.

   2. Créer la capsule :

      $ oc create -f pod-projected-svc-token.yaml

      Le kubelet demande et stocke le jeton au nom du pod, met le jeton à la disposition du pod dans un chemin d'accès configurable et rafraîchit le jeton à l'approche de son expiration.

3. L'application qui utilise le jeton lié doit gérer le rechargement du jeton lorsqu'il tourne.

   Le kubelet fait pivoter le jeton s'il a dépassé 80 % de sa durée de vie ou s'il a plus de 24 heures.