IAM-Rollen für Servicekonten (IRSA)

Wenn ein in EKS ausgeführter Pod eine AWS-API aufrufen muss – beispielsweise um aus S3 zu lesen oder in DynamoDB zu schreiben –, benötigt er AWS-Anmeldedaten. Der naheliegende Ansatz besteht darin, einen IAM-Benutzer zu erstellen und dessen Zugriffsschlüssel als Umgebungsvariablen fest zu hinterlegen. Das ist unsicher und verstößt gegen das Prinzip der geringsten Berechtigungen, da alle Pods auf demselben Knoten dieselben Anmeldedaten verwenden. IAM Roles for Service Accounts (IRSA) löst dieses Problem, indem detailliert berechtigte IAM-Rollen direkt an Kubernetes-ServiceAccounts gebunden werden.

IRSA funktioniert über die OpenID-Connect-(OIDC-)Föderation. EKS erstellt einen OIDC-Provider für Ihren Cluster. Wenn ein Pod auf einen ServiceAccount verweist, der mit einer IAM-Rollen-ARN annotiert ist, injiziert EKS ein signiertes projiziertes ServiceAccount-Token in den Pod. Das AWS SDK im Pod tauscht dieses Token über die API AssumeRoleWithWebIdentity von AWS STS gegen temporäre AWS-Anmeldedaten ein – langlebige Schlüssel sind nicht erforderlich.

Bevor Sie IRSA verwenden, müssen Sie den OIDC-Aussteller von EKS in Ihrem AWS-Konto als vertrauenswürdigen Identitätsanbieter verknüpfen. Dadurch wird eine IAM-OIDC-Provider-Ressource erstellt, die von AWS STS erkannt wird. Der Befehl eksctl übernimmt dies automatisch. Nach der Erstellung können Sie die Ressource in der IAM-Konsole unter „Identity Providers“ überprüfen.

Die IAM-Rolle für IRSA muss über eine Vertrauensrichtlinie verfügen, die es dem OIDC-Provider erlaubt, die Rolle zu übernehmen, wobei sie auf einen bestimmten Kubernetes-Namespace und ServiceAccount beschränkt wird. Die Bedingung verwendet den sub-Claim im OIDC-Token. Dieser ist auf system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME gesetzt. Dadurch wird sichergestellt, dass nur Pods, die diesen bestimmten ServiceAccount verwenden, die Rolle übernehmen können – nicht jeder Pod im Cluster.

Erstellen Sie im Ziel-Namespace einen Kubernetes-ServiceAccount und annotieren Sie ihn mit der IAM-Rollen-ARN. Wenn ein Pod auf diesen ServiceAccount verweist, injiziert EKS automatisch das OIDC-Token und zwei Umgebungsvariablen (AWS_WEB_IDENTITY_TOKEN_FILE und AWS_ROLE_ARN). Das AWS SDK erkennt diese automatisch und ruft STS auf, um temporäre Anmeldedaten abzurufen – an Ihrer Anwendung sind keine Codeänderungen erforderlich.

Setzen Sie in der Pod- oder Deployment-Spezifikation serviceAccountName auf den annotierten ServiceAccount. Wenn EKS den Pod einplant, bindet es das OIDC-Token automatisch unter /var/run/secrets/eks.amazonaws.com/serviceaccount/token ein und setzt die erforderlichen Umgebungsvariablen. Jeder Aufruf eines AWS SDK im Pod verwendet transparent die Anmeldedaten der zugeordneten IAM-Rolle, ohne dass Anmeldedaten explizit konfiguriert werden müssen.

Bei einer IAM-Rolle des Knotens erbt jeder Pod auf einem Knoten dieselben Berechtigungen – ein kompromittierter Pod kann auf alle AWS-Services zugreifen, für die der Knoten berechtigt ist. Bei IRSA übernimmt jeder Pod über seinen ServiceAccount nur die Rolle, die er benötigt. Dadurch wird das Prinzip der geringsten Berechtigungen auf Pod-Ebene umgesetzt und der Schadensradius eines Sicherheitsvorfalls begrenzt. AWS empfiehlt IRSA für alle neuen EKS-Bereitstellungen gegenüber Rollen auf Knotenebene.

eksctl kann die OIDC-Verknüpfung, die IAM-Rolle, die Vertrauensrichtlinie und die Annotation des Kubernetes-ServiceAccounts mit einem einzigen Befehl unter Verwendung von create iamserviceaccount erstellen. Dies ist die einfachste Möglichkeit, IRSA einzurichten, ohne die JSON-Datei der Vertrauensrichtlinie manuell zu schreiben. Sie geben den Namespace, den Namen des ServiceAccounts und die anzuhängende IAM-Policy-ARN an; eksctl übernimmt den Rest.

Viele EKS-Add-ons und -Controller benötigen IRSA, um zu funktionieren: Cluster Autoscaler benötigt die Berechtigung zum Aufrufen der EC2 Auto Scaling API, der AWS Load Balancer Controller benötigt die Berechtigung zum Erstellen und Verwalten von ELB-Ressourcen, external-dns benötigt Schreibzugriff auf Route 53 und der EBS CSI driver benötigt die Berechtigung zum Erstellen und Anbinden von EBS-Volumes. Verwenden Sie für diese Systemkomponenten immer IRSA – erteilen Sie die Berechtigungen niemals auf Ebene der IAM-Rolle des Knotens.

IRSA-Token sind kurzlebig und werden vom Kubernetes-Controller für die Token-Projektion vor ihrem Ablauf automatisch rotiert. Die Standard-Audience des Tokens ist sts.amazonaws.com und seine Gültigkeit beträgt 24 Stunden. Der Controller aktualisiert es jedoch nach 80 % seiner Gültigkeitsdauer. Auch die über IRSA bezogenen AWS-STS-Anmeldedaten sind temporär und gelten normalerweise 1 Stunde. Diese automatische Rotation beseitigt den Aufwand für die Rotation von Anmeldedaten, der bei langlebigen IAM-Zugriffsschlüsseln entsteht.

Jedes Mal, wenn ein Pod über IRSA eine IAM-Rolle übernimmt, zeichnet AWS CloudTrail ein AssumeRoleWithWebIdentity-Ereignis auf. Das Ereignis enthält die ARN der übernommenen Rolle, das Subjekt des OIDC-Tokens (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) und die Quell-IP-Adresse. Dadurch erhalten Sie einen vollständigen Prüfpfad darüber, welche Pods wann auf welche AWS-Services zugegriffen haben – entscheidend für Compliance und die Untersuchung von Sicherheitsvorfällen in regulierten Umgebungen.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: IRSA verwendet OIDC-Föderation, um Kubernetes-ServiceAccount-Token gegen temporäre AWS-Anmeldedaten einzutauschen; Vertrauensrichtlinien von IAM-Rollen beschränken den Zugriff auf einen bestimmten Namespace und ServiceAccount; und IRSA ermöglicht eine geringste Rechtevergabe pro Pod, die Rollen auf Knotenebene deutlich überlegen ist. Als Nächstes sehen wir uns CloudWatch-Metriken, Namespaces und Dimensionen zur Überwachung Ihrer AWS-Ressourcen an.