Kubernetes v1.34: Integration von Service Account Tokens für Image Pulls erreicht Beta

TL;DR

Die Kubernetes-Version 1.34 hat die Integration von Service Account Tokens für Image Pulls in den Beta-Status überführt. Diese Funktion ermöglicht eine sichere und temporäre Authentifizierung für Container -Images, wodurch die Abhängigkeit von langfristigen Anmeldeinformationen reduziert wird.

Kubernetes v1.34 bringt wesentliche Verbesserungen in der Sicherheit und Handhabung von Service Account Tokens. Nach dem erfolgreichen Alpha-Release in der Vorgängerversion ermöglicht die nun in Beta überführte Funktion Credential Providers, spezifische Service Account Tokens zu verwenden, um Anmeldeinformationen für Container -Registries zu erhalten. Dies stellt eine sichere und kurzlebige Alternative zu herkömmlichen Image Pull Secrets dar.

Wichtige Neuerungen im Beta-Status

Die Beta-Version führt mehrere entscheidende Änderungen ein, die die Funktion robuster und produktionsbereit machen. Eine der bedeutendsten Änderungen ist das erforderliche cacheType-Feld in der Konfiguration des Credential Providers. Dieses Feld muss spezifiziert werden, um das richtige Caching-Verhalten sicherzustellen. Es stehen zwei Caching-Strategien zur Verfügung:

1. Token: Diese Strategie speichert Anmeldeinformationen pro Service Account Token. Sie ist nützlich, wenn die Lebensdauer der Anmeldeinformationen an das Token gebunden ist.
2. ServiceAccount: Hierbei werden Anmeldeinformationen pro Service Account Identität zwischengespeichert, was bedeutet, dass die Anmeldeinformationen für alle Pods, die denselben Service Account verwenden, gültig sind.

Sicherheitsverbesserungen

Die Beta-Version verbessert die Sicherheit, indem sie eine stärkere Isolation von Container -Images ermöglicht. Pods können nur auf Images zugreifen, die mit den Service Accounts abgerufen wurden, für die sie autorisiert sind. Dies verhindert unbefugten Zugriff auf sensible Container-Images und ermöglicht eine granulare Zugriffskontrolle, bei der unterschiedliche Workloads verschiedene Berechtigungen für Registries basierend auf ihrem Service Account haben können.

Wenn Credential Providers Service Account Tokens verwenden, verfolgt das System die Identität des Service Accounts (Namespace, Name und UID) für jedes abgerufene Image. Bei einem Zugriff auf ein zwischengespeichertes Image überprüft das System, ob der Service Account des Pods mit demjenigen übereinstimmt, der ursprünglich für den Abruf des Images verwendet wurde. Administratoren können den Zugriff auf zuvor abgerufene Images widerrufen, indem sie den Service Account löschen und neu erstellen, was die UID ändert und den Zugriff auf zwischengespeicherte Images ungültig macht.

Technische Details und Implikationen

Die Konfiguration für Credential Providers erfolgt über das tokenAttributes-Feld. Es ist wichtig zu beachten, dass die Kubelet-Instanz nicht in der Lage ist, Service Account Tokens direkt an Registries zu senden. Stattdessen sind Credential Provider Plugins erforderlich, um Tokens in das von Registries erwartete Benutzername/Passwort-Format umzuwandeln.

Der Image Pull Prozess verläuft in mehreren Schritten: Wenn das Image nicht lokal vorhanden ist, prüft die Kubelet-Instanz den Credential Cache. Bei Bedarf wird ein Service Account Token angefordert, das dann in Anmeldeinformationen umgewandelt wird. Diese werden zwischengespeichert und verwendet, um das Image abzurufen. Wenn das Image bereits lokal vorhanden ist, wird die Übereinstimmung der Service Account Koordinaten überprüft, um sicherzustellen, dass der Zugriff autorisiert ist.

Fazit/Ausblick

Die Einführung der Integration von Service Account Tokens in Kubernetes v1.34 stellt einen bedeutenden Fortschritt in der Sicherheit und Handhabung von Container -Images dar. Diese Entwicklung könnte die Art und Weise, wie Authentifizierungs- und Autorisierungsmechanismen in Kubernetes-Umgebungen implementiert werden, nachhaltig verändern.