Technische Übersicht - Amazon EKS

Technische Übersicht

2014 wurde AWS Identity and Access Management Unterstützung für Verbundidentitäten mit OpenID Connect (OIDC) hinzugefügt. Mit dieser Funktion können Sie AWS-API-Aufrufe mit unterstützten Identitätsanbietern authentifizieren und ein gültiges OIDC-JSON-Web-Token (JWT) erhalten. Sie können dieses Token an die AWS STS AssumeRoleWithWebIdentity-API-Operation übergeben und temporäre IAM-Rollen-Anmeldeinformationen erhalten. Sie können diese Anmeldeinformationen verwenden, um mit jedem AWS-Service wie Amazon S3 und DynamoDB zu interagieren.

Kubernetes verwendet seit langem Servicekonten als eigenes internes Identitätssystem. Pods können sich beim Kubernetes-API-Server mithilfe eines automatisch gemounteten Tokens (ein Nicht-OIDC-JWT) authentifizieren, das nur der Kubernetes-API-Server validieren kann. Diese Legacy-Servicekonto-Token laufen nicht ab und das Rotieren des Signaturschlüssels ist ein schwieriger Prozess. In Kubernetes-Version 1.12 wurde Unterstützung für eine neue ProjectedServiceAccountToken-Funktion hinzugefügt. Dabei handelt es sich um ein OIDC-JSON-Web-Token, das auch die Servicekontoidentität enthält und eine konfigurierbare Zielgruppe unterstützt.

Amazon EKS hostet jetzt einen öffentlichen OIDC-Erkennungsendpunkt pro Cluster, der die Signaturschlüssel für die ProjectedServiceAccountToken-JSON-Web-Token enthält, sodass externe Systeme wie IAM die von Kubernetes ausgegebenen OIDC-Token validieren und akzeptieren können.

IAM-Rollenkonfiguration

In IAM erstellen Sie eine IAM-Rolle mit einer Vertrauensstellung, die für den OIDC-Anbieter Ihres Clusters, den Servicekonto-Namespace und (optional) den Servicekontonamen gilt, und fügen dann die IAM-Richtlinie an, die Sie dem Servicekonto zuordnen möchten. Sie können mehrere Einträge in den Bedingungen StringEquals und StringLike unten hinzufügen, um mehrere Servicekonten oder Namespaces mit der Rolle zu verwenden.

  • So schränken Sie eine Rolle auf ein bestimmtes Servicekonto ein:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME" } } } ] }
  • So schränken Sie eine Rolle auf einen gesamten Namespace ein (um den Namespace als Grenze zu verwenden):

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:*" } } } ] }

Servicekontokonfiguration

In Kubernetes definieren Sie die IAM-Rolle, die mit einem Servicekonto in Ihrem Cluster verknüpft werden soll, indem Sie dem Servicekonto die eks.amazonaws.com/role-arn-Anmerkung hinzufügen.

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME

Pod-Konfiguration

Der Amazon-EKS-Pod-Identitäts-Webhook im Cluster sucht nach Pods, die mit Servicekonten mit dieser Anmerkung verknüpft sind, und wendet die folgenden Umgebungsvariablen auf sie an.

AWS_ROLE_ARN=arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
Anmerkung

Ihr Cluster muss nicht den mutierenden Webhook verwenden, um die Umgebungsvariablen und die Token-Dateimounts zu konfigurieren. Sie können Pods konfigurieren, um diese Umgebungsvariablen manuell hinzuzufügen.

Unterstützte Versionen des AWS SDK suchen zuerst im Anmeldeinformationskettenanbieter nach diesen Umgebungsvariablen. Die Anmeldeinformationen der Rolle werden für Pods verwendet, die diese Kriterien erfüllen.

Anmerkung

Wenn ein Pod AWS-Anmeldeinformationen aus einer IAM-Rolle verwendet, die einem Servicekonto zugeordnet ist, verwenden die AWS CLI oder andere SDKs in den Containern für diesen Pod die von dieser Rolle bereitgestellten Anmeldeinformationen. Der Pod hat weiterhin Zugriff auf die dem Amazon-EKS-Knoten-IAM-Rolle bereitgestellten Anmeldeinformationen, es sei denn, Sie beschränken den Zugriff auf diese Anmeldeinformationen. Weitere Informationen finden Sie unter Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist.

Standardmäßig verfügen nur Container, die als root ausgeführt werden, über die entsprechenden Dateisystemberechtigungen zum Lesen der Webidentitäts-Tokendatei. Sie können diese Berechtigungen bereitstellen, indem Sie Ihre Container als root ausführen lassen, oder indem Sie den folgenden Sicherheitskontext für die Container in Ihrem Manifest bereitstellen. Die fsGroup-ID ist beliebig, und Sie können eine beliebige gültige Gruppen-ID auswählen. Weitere Informationen zu den Auswirkungen beim Festlegen eines Sicherheitskontexts für Ihre Pods finden Sie unter Konfigurieren eines Sicherheitskontexts für einen Pod oder Container in der Kubernetes-Dokumentation.

Anmerkung

Die Bereitstellung dieses Sicherheitskontexts ist für Cluster der Version 1.19 oder höher nicht erforderlich.

apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: template: metadata: labels: app: my-app spec: serviceAccountName: my-app containers: - name: my-app image: my-app:latest securityContext: fsGroup: 1337 ...

Das kubelet fordert das Token im Namen des Pods an und speichert es. Standardmäßig aktualisiert das kubelet das Token, wenn es älter als 80 Prozent seiner gesamten TTL ist oder wenn das Token älter als 24 Stunden ist. Sie können die Ablaufdauer für jedes Konto mit Ausnahme des Standarddienstkontos mit den Einstellungen in Ihrer Pod-Spezifikation ändern. Weitere Informationen finden Sie unter Service Account Token Volume Projection in der Kubernetes-Dokumentation.

Kontoübergreifende IAM-Berechtigungen

Sie können kontoübergreifende IAM-Berechtigungen konfigurieren, indem Sie entweder einen Identitätsanbieter aus dem Cluster eines anderen Kontos erstellen oder verkettete AssumeRole-Operationen verwenden. In den folgenden Beispielen besitzt Konto A einen Amazon-EKS-Cluster, der IAM-Rollen für Servicekonten unterstützt. Pods, die auf diesem Cluster ausgeführt werden, müssen IAM-Berechtigungen von Konto B annehmen.

Beispiel : Erstellen eines Identitätsanbieters aus dem Cluster eines anderen Kontos

In diesem Beispiel würde Konto A dem Konto B die OIDC-Aussteller-URL aus seinem Cluster bereitstellen. Konto B befolgt die Anweisungen in Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster und Erstellen einer IAM-Rolle und -Richtlinie für Ihr Servicekonto unter Verwendung der OIDC-Aussteller-URL aus dem Cluster von Konto A. Anschließend kommentiert ein Cluster-Administrator das Servicekonto im Cluster von Konto A, um die Rolle aus Konto B zu verwenden.

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_B_ID:role/IAM_ROLE_NAME

Beispiel : Verwenden von verketteten AssumeRole-Operationen

In diesem Beispiel erstellt Konto B eine IAM-Richtlinie mit den Berechtigungen, die Pods im Cluster von Konto A erteilt werden sollen. Konto B fügt diese Richtlinie einer IAM-Rolle mit einer Vertrauensstellung an, die AssumeRole-Berechtigungen für Konto A (111111111111) gewährt, wie unten gezeigt.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }

Konto A erstellt eine Rolle mit einer Vertrauensrichtlinie, die Anmeldeinformationen von dem Identitätsanbieter erhält, der mit der OIDC-Aussteller-URL des Clusters erstellt wurde, wie unten gezeigt.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] }

Konto A fügt dieser Rolle eine Richtlinie mit den folgenden Berechtigungen an, um die Rolle anzunehmen, die Konto B erstellt hat.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/account-b-role" } ] }

Der Anwendungscode für Pods, die die Rolle von Konto B übernehmen sollen, verwendet zwei Profile: account_b_role und account_a_role. Das account_b_role-Profil verwendet das account_a_role-Profil als Quelle. Für die AWS CLI würde die ~/.aws/config-Datei wie im folgenden Beispiel aussehen.

[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::222222222222:role/account-b-role [profile account_a_role] web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111111111111:role/account-a-role

Informationen zum Festlegen von verketteten Profilen für andere AWS SDKs finden Sie in der entsprechenden Dokumentation.