Tous les produits
Search

Ce produit

    Container Service for Kubernetes:Use ServiceAccount token volume projection

    Centre de documentation

    Container Service for Kubernetes:Use ServiceAccount token volume projection

    Dernière mise à jour :Sep 12, 2026

    Les jetons ServiceAccount authentifient la communication entre les pods et le serveur API Kubernetes. L'approche traditionnelle stocke ces jetons dans des Secrets et les monte sous forme de fichiers, exposant ainsi les pods à des attaques par usurpation d'identité, à une élévation de privilèges et à des jetons obsolètes qui n'expirent jamais. La projection de volume de jetons ServiceAccount élimine ces risques en montant directement des jetons à durée de vie limitée et liés à une audience spécifique en tant que volumes projetés, sans dépendre des Secrets.

    Contexte

    Les jetons ServiceAccount traditionnels présentent quatre faiblesses structurelles en matière de sécurité :

    • Audience non liée : les JSON Web Tokens (JWT) ne comportent aucune restriction audience. Un jeton compromis peut ainsi être rejoué contre n'importe quel service du cluster, permettant des attaques par usurpation d'identité.

    • Secrets surprivilégiés : les jetons sont stockés dans des Secrets et livrés sous forme de fichiers aux nœuds. Les jetons des composants système détiennent souvent des autorisations dépassant les besoins individuels des charges de travail, ce qui élargit la surface d'attaque.

    • Absence d'expiration : les JWT restent valides pendant toute la durée de vie du ServiceAccount. Leur rotation nécessite le remplacement manuel de la clé de signature, un processus que client-go n'automatise pas.

    • Prolifération des Secrets : un Secret par ServiceAccount dégrade l'élasticité du cluster à grande échelle.

    La projection de volume de jetons ServiceAccount résout ces quatre problèmes. Les jetons sont limités à une audience spécifique, expirent après une période configurable et sont automatiquement mis à jour par le kubelet, sans nécessiter de Secrets.

    Fonctionnement

    Lorsqu'un pod doté d'un volume de jeton ServiceAccount projeté démarre, le kubelet demande au serveur API un jeton signé à courte durée de vie et l'écrit dans le chemin de montage configuré à l'intérieur du conteneur. Le kubelet surveille le jeton et demande proactivement un remplacement avant son expiration. Il incombe à l'application de recharger le fichier de jeton lors de sa rotation ; un sondage toutes les cinq minutes suffit pour la plupart des charges de travail.

    Prérequis

    Avant de commencer, assurez-vous de disposer des éléments suivants :

    • Un cluster managé ACK, un cluster dédié ACK ou un cluster Serverless ACK exécutant Kubernetes 1.20 ou une version ultérieure. Consultez les rubriques Créer un cluster managé ACK, Créer un cluster dédié ACK (obsolète) et Créer un cluster Serverless ACK.

    • La fonctionnalité de projection de volume de jetons ServiceAccount activée sur le cluster. Cette fonctionnalité est activée par défaut dans les clusters exécutant Kubernetes 1.22 ou une version ultérieure. Pour mettre à niveau, consultez la rubrique Mettre à niveau manuellement les clusters ACK.

      Lorsqu'elle est activée, le serveur API et le controller-manager configurent automatiquement les paramètres de démarrage suivants :

      Paramètre Description Valeur par défaut Configurable via la console
      service-account-issuer L'émetteur du jeton, mappé au champ iss dans la charge utile JWT https://kubernetes.default.svc Oui
      api-audiences Identifiants API utilisés pour valider les jetons entrants. Séparez plusieurs valeurs par des virgules (,). https://kubernetes.default.svc Oui
      service-account-signing-key-file Chemin d'accès à la clé privée utilisée pour signer les jetons /etc/kubernetes/pki/sa.key Non (fixé à la valeur par défaut)

    Étape 1 : Créer un ServiceAccount

    Chaque namespace inclut un ServiceAccount default. Exécutez kubectl get serviceaccounts pour lister les comptes existants dans le namespace actuel.

    Pour attribuer une identité distincte à un pod, créez un ServiceAccount dédié :

    kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF

    Vérifiez que le ServiceAccount a bien été créé :

    kubectl get serviceaccounts/build-robot -o yaml

    Étape 2 : Déployer un pod avec projection de volume de jetons

    L'exemple suivant monte un jeton ServiceAccount projeté dans un pod nginx. Le jeton est limité à l'audience vault et expire après deux heures (7200 secondes).

    1. Créez un fichier nommé nginx.yaml :

      apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

    2. Appliquez le manifeste :

      kubectl apply -f nginx.yaml

    Vérifier l'expiration du jeton

    1. Confirmez que le pod est en cours d'exécution :

      kubectl get pod nginx

      Résultat attendu :

      NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          3m15s

    2. Extrayez le jeton du conteneur :

      kubectl exec -t nginx -- cat /var/run/secrets/tokens/vault-token > vault-token

    3. Décodez le jeton et affichez son heure d'expiration :

      cat vault-token | awk -F '.' '{print $2}' | base64 -d 2>/dev/null | jq '.exp' | xargs -I {} date -d @{}

      Exemple de résultat :

      Mon  Aug 26 15:45:59 CST 2024

    Notes d'utilisation

    Rotation des jetons : le kubelet effectue automatiquement la rotation du jeton avant son expiration. Configurez votre application pour qu'elle recharge le fichier de jeton selon une planification régulière ; un sondage toutes les cinq minutes suffit, indépendamment de la durée de vie réelle (TTL).

    Compatibilité SDK : le rechargement automatique des jetons en Go nécessite une version de client-go égale ou supérieure à 10.0.0.

    Autorisations de fichier : lorsque vous utilisez la projection de volume de jetons liés, les autorisations du fichier de jeton ServiceAccount passent de 644 à 600. Si fsGroup est défini dans le contexte de sécurité du pod, les autorisations sont définies sur 640.

    Étapes suivantes