Kubernetes 1.37 révolutionne l'identité des workloads avec les Pod Certificates

Jusqu'à présent, l'identité des applications au sein de Kubernetes reposait principalement sur les jetons JWT (JSON Web Tokens, des jetons d'authentification au format JSON signés cryptographiquement) associés aux comptes de service (Service Accounts). Bien que pratiques et intégrés nativement dans le composant d'agent de nœud Kubelet (l'agent chargé de gérer les conteneurs sur chaque machine du cluster), ces jetons souffrent d'une limite structurelle : ce sont des bearer tokens (des jetons au porteur). Si un tiers intercepte un jeton, il peut usurper l'identité de l'application sans restriction.

Des certificats X.509 intégrés pour une sécurité renforcée

Pour corriger cette vulnérabilité, Kubernetes version 1.37 annonce le passage en disponibilité générale (GA, pour General Availability) des Pod Certificates et des Cluster Trust Bundles (des jeux centralisés de certificats de confiance). L'objectif est d'apporter le mécanisme de preuve de possession au niveau de chaque pod grâce au protocole TLS (Transport Layer Security, le protocole standard de chiffrement des communications réseau) et au mTLS (Mutual TLS, l'authentification mutuelle où le client et le serveur valident leurs identités respectives).

Un flux d'émission et de rotation entièrement automatisé

Le fonctionnement repose sur une collaboration étroite entre l'application, l'agent du nœud et un contrôleur de signature (signer controller) :

• Génération locale de la clé privée : Kubelet génère la clé privée directement sur le nœud et crée un objet PodCertificateRequest (une demande de certificat).
• Signature et émission : Le contrôleur de signature valide la requête et fournit la chaîne de certificats ainsi qu'une date de rafraîchissement dans l'attribut beginRefreshAt.
• Écriture sur le système de fichiers : Kubelet écrit la clé et le certificat sur le volume du pod sous forme de credential bundle (un fichier regroupant clé privée et certificats).
• Rotation automatique : La durée de vie maximale des certificats natifs sera de 24 heures (et plafonnée à 91 jours pour les signataires tiers). L'application doit surveiller les mises à jour via inotify (le système de notification de changements de fichiers du noyau Linux) ou par vérification régulière (polling).

"L'objectif des Pod Certificates est de rendre l'utilisation des certificats X.509 aussi simple que celle des jetons JWT de compte de service, tout en maintenant un niveau de sécurité élevé."

En matière de sécurité, le greffon d'admission node restriction (un composant de contrôle d'accès) garantit qu'un nœud compromis ne peut pas demander de certificats pour des pods exécutés ailleurs. L'intégration dans le manifeste de pod s'effectue directement via des sources de volumes projetés (projected volumes, une fonctionnalité permettant de regrouper plusieurs ressources dans un même répertoire) :

apiVersion: v1
kind: Pod
metadata:
  name: mon-application
spec:
  containers:
  - name: app
    image: my-app:1.0
    volumeMounts:
    - name: pod-certs
      mountPath: /var/run/secrets/pod-certs
  volumes:
  - name: pod-certs
    projected:
      sources:
      - podCertificate:
          signerName: ahmedtd.github.io/tinycert-spiffe
          keyType: ECDSA256
          credentialBundlePath: tls.crt

Quel impact pour vos architectures distribuées ?

Pour les développeurs et architectes, cette évolution facilite considérablement la mise en œuvre de normes comme SPIFFE (Secure Production Identity Framework for Everyone, un standard d'identification sécurisée des workloads) sans nécessiter de conteneurs d'accompagnement complexes (sidecars, des conteneurs secondaires adossés au conteneur principal). Même s'il faut adapter le code applicatif pour recharger dynamiquement les clés sur le disque lors des rotations, cette fonctionnalité réduit drastiquement la surface d'attaque en éliminant les jetons réutilisables.