Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Strategie für mehrere Konten

AWS empfiehlt, eine Strategie für mehrere Konten und AWS-Organisationen zu verwenden, um Ihre Geschäftsanwendungen und -daten zu isolieren und zu verwalten. Die Verwendung einer Strategie für mehrere Konten bietet viele Vorteile:

In den folgenden Abschnitten wird erklärt, wie Sie eine Strategie mit mehreren Konten für Ihre EKS-Workloads mithilfe eines zentralisierten oder dezentralen EKS-Cluster-Ansatzes implementieren.

Planung einer Kontenstrategie für mehrere Workloads für Multi-Tenant-Cluster

In einer AWS-Strategie mit mehreren Konten werden Ressourcen, die zu einem bestimmten Workload gehören, wie S3-Buckets, ElastiCache Cluster und DynamoDB-Tabellen, alle in einem AWS-Konto erstellt, das alle Ressourcen für diesen Workload enthält. Diese werden als Workload-Konto bezeichnet, und der EKS-Cluster wird in einem Konto bereitgestellt, das als Cluster-Konto bezeichnet wird. Clusterkonten werden im nächsten Abschnitt untersucht. Die Bereitstellung von Ressourcen in einem dedizierten Workload-Konto ähnelt der Bereitstellung von Kubernetes-Ressourcen in einem dedizierten Namespace.

Workload-Konten können dann gegebenenfalls weiter nach dem Lebenszyklus der Softwareentwicklung oder nach anderen Anforderungen unterteilt werden. Beispielsweise kann ein bestimmter Workload über ein Produktionskonto, ein Entwicklungskonto oder Konten für das Hosten von Instanzen dieses Workloads in einer bestimmten Region verfügen. Weitere Informationen finden Sie in diesem AWS-Whitepaper.

Bei der Implementierung der EKS-Strategie für mehrere Konten können Sie die folgenden Ansätze anwenden:

Zentralisierter EKS-Cluster

Bei diesem Ansatz wird Ihr EKS-Cluster in einem einzigen AWS-Konto namens bereitgestelltCluster Account. Mithilfe von IAM-Rollen für Service Accounts (IRSA) oder EKS-Pod-Identitäten zur Bereitstellung temporärer AWS-Anmeldeinformationen und AWS Resource Access Manager (RAM) zur Vereinfachung des Netzwerkzugriffs können Sie eine Strategie für mehrere Konten für Ihren EKS-Cluster mit mehreren Mandanten verfolgen. Das Clusterkonto enthält die VPC, die Subnetze, den EKS-Cluster, die EC2/Fargate Rechenressourcen (Worker-Knoten) und alle zusätzlichen Netzwerkkonfigurationen, die für den Betrieb Ihres EKS-Clusters erforderlich sind.

In einer Multi-Workload-Kontostrategie für Multi-Tenant-Cluster orientieren sich AWS-Konten in der Regel an Kubernetes-Namespaces als Mechanismus zur Isolierung von Ressourcengruppen. Bei der Implementierung einer Strategie für mehrere Konten für EKS-Cluster mit mehreren Mandanten sollten weiterhin die bewährten Methoden für die Mandantenisolierung innerhalb eines EKS-Clusters befolgt werden.

Es ist möglich, mehrere Cluster Accounts in Ihrer AWS-Organisation zu haben, und es ist eine bewährte Methode, mehrere zu habenCluster Accounts, die Ihren Anforderungen im Lebenszyklus der Softwareentwicklung entsprechen. Für Workloads, die in sehr großem Umfang ausgeführt werden, benötigen Sie möglicherweise mehrere, Cluster Accounts um sicherzustellen, dass für alle Ihre Workloads genügend Kubernetes- und AWS-Servicekontingente verfügbar sind.

|Im obigen Diagramm wird AWS-RAM verwendet, um Subnetze von einem Cluster-Konto für ein Workload-Konto gemeinsam zu nutzen. Dann verwenden Workloads, die in EKS-Pods ausgeführt werden, IRSA- oder EKS-Pod-Identitäten und Rollenverkettung, um eine Rolle in ihrem Workload-Konto zu übernehmen und auf ihre AWS-Ressourcen zuzugreifen.

Implementierung einer Multi-Workload-Kontostrategie für Multi-Tenant-Cluster

Teilen von Subnetzen mit AWS Resource Access Manager

Mit AWS Resource Access Manager (RAM) können Sie Ressourcen für mehrere AWS-Konten gemeinsam nutzen.

Wenn RAM für Ihre AWS-Organisation aktiviert ist, können Sie die VPC-Subnetze aus dem Cluster-Konto für Ihre Workload-Konten gemeinsam nutzen. Dadurch können AWS-Ressourcen, die Ihren Workload-Konten gehören, wie Amazon ElastiCache Clusters oder Amazon Relational Database Service (RDS) -Datenbanken, in derselben VPC wie Ihr EKS-Cluster bereitgestellt und von den Workloads genutzt werden, die auf Ihrem EKS-Cluster ausgeführt werden.

Um eine Ressource über RAM gemeinsam zu nutzen, öffnen Sie RAM in der AWS-Konsole des Cluster-Kontos und wählen Sie „Resource Shares“ und „Create Resource Share“ aus. Geben Sie Ihrem Resource Share einen Namen und wählen Sie die Subnetze aus, die Sie teilen möchten. Wählen Sie erneut Weiter aus und geben Sie die 12-stelligen Konto-IDs für die Workload-Konten ein, mit denen Sie die Subnetze teilen möchten. Wählen Sie erneut Weiter aus und klicken Sie auf Resource Share erstellen, um den Vorgang abzuschließen. Nach diesem Schritt kann das Workload-Konto Ressourcen in diesen Subnetzen bereitstellen.

RAM-Shares können auch programmgesteuert oder mit Infrastruktur als Code erstellt werden.

Wählen Sie zwischen EKS Pod Identities und IRSA

Auf der re:Invent 2023 hat AWS EKS Pod Identities als einfachere Möglichkeit eingeführt, temporäre AWS-Anmeldeinformationen für Ihre Pods auf EKS bereitzustellen. Sowohl IRSA- als auch EKS-Pod-Identitäten sind gültige Methoden für die Bereitstellung temporärer AWS-Anmeldeinformationen für Ihre EKS-Pods und werden weiterhin unterstützt. Sie sollten überlegen, welche Methode der Bereitstellung Ihren Anforderungen am besten entspricht.

Bei der Arbeit mit einem EKS-Cluster und mehreren AWS-Konten kann IRSA direkt Rollen in anderen AWS-Konten als dem Konto übernehmen, in dem der EKS-Cluster direkt gehostet wird, während für EKS-Pod-Identitäten die Konfiguration der Rollenverkettung erforderlich ist. Einen ausführlichen Vergleich finden Sie in der EKS-Dokumentation.

Zugreifen auf AWS-API-Ressourcen mit IAM-Rollen für Servicekonten

Mit IAM Roles for Service Accounts (IRSA) können Sie temporäre AWS-Anmeldeinformationen für Ihre Workloads bereitstellen, die auf EKS ausgeführt werden. IRSA kann verwendet werden, um temporäre Anmeldeinformationen für IAM-Rollen in den Workload-Konten vom Cluster-Konto abzurufen. Auf diese Weise können Ihre Workloads, die auf Ihren EKS-Clustern im Cluster-Konto ausgeführt werden, AWS-API-Ressourcen wie S3-Buckets, die im Workload-Konto gehostet werden, problemlos nutzen und die IAM-Authentifizierung für Ressourcen wie Amazon RDS-Datenbanken oder Amazon EFS verwenden. FileSystems

Auf AWS-API-Ressourcen und andere Ressourcen, die die IAM-Authentifizierung in einem Workload-Konto verwenden, kann nur über Anmeldeinformationen für IAM-Rollen in demselben Workload-Konto zugegriffen werden, es sei denn, der kontoübergreifende Zugriff ist möglich und wurde ausdrücklich aktiviert.

IRSA für kontoübergreifenden Zugriff aktivieren

Um IRSA für Workloads in Ihrem Cluster-Konto für den Zugriff auf Ressourcen in Ihren Workload-Konten zu aktivieren, müssen Sie zunächst einen IAM-OIDC-Identitätsanbieter in Ihrem Workload-Konto erstellen. Dies kann mit dem gleichen Verfahren für die Einrichtung von IRSA erfolgen, mit der Ausnahme, dass der Identity Provider im Workload-Konto erstellt wird.

Wenn Sie dann IRSA für Ihre Workloads auf EKS konfigurieren, können Sie dieselben Schritte wie in der Dokumentation befolgen, aber die 12-stellige Konto-ID des Workload-Kontos verwenden, wie im Abschnitt „Beispiel: Erstellen Sie einen Identitätsanbieter aus dem Cluster eines anderen Kontos“ beschrieben.

Nach der Konfiguration kann Ihre in EKS ausgeführte Anwendung ihr Dienstkonto direkt verwenden, um eine Rolle im Workload-Konto zu übernehmen und die darin enthaltenen Ressourcen zu nutzen.

Zugreifen auf AWS-API-Ressourcen mit EKS-Pod-Identitäten

EKS-Pod-Identitäten bieten eine weitere Möglichkeit, temporäre AWS-Anmeldeinformationen für Ihre Workloads bereitzustellen, die auf EKS ausgeführt werden. EKS Pod Identities lassen sich in die EKS-Steuerebene und einen Cluster-Agenten integrieren, sodass Pods Anmeldeinformationen erhalten, ohne dass Sie einen IAM-OIDC-Identitätsanbieter erstellen oder verwalten müssen. EKS-Pod-Identitäten sind der empfohlene Ansatz für neue Workloads auf unterstützten Knotentypen, während IRSA weiterhin eine vollständig unterstützte Alternative ist.

Mit EKS Pod Identities verknüpfen Sie ein Kubernetes-Servicekonto in Ihrem Cluster mit einer IAM-Rolle in demselben AWS-Konto wie der Cluster. EKS verwendet diese Zuordnung, um temporäre Anmeldeinformationen für diese IAM-Rolle abzurufen und sie sicher an Pods weiterzuleiten, die das Dienstkonto verwenden. Ihre Anwendung kann dann standardmäßige AWS-SDKs und die standardmäßige Anmeldeinformationskette verwenden, um AWS-APIs aufzurufen. Es sind keine benutzerdefinierten Anmeldeinformationsanbieter oder Konfigurationsdateien erforderlich.

Aktivierung von EKS Pod Identities für kontoübergreifenden Zugriff

EKS-Pod-Identitäten unterstützen nativ den kontenübergreifenden Zugriff, indem sie eine IAM-Zielrolle im Workload-Konto und die IAM-Rollenverkettung verwenden. Wenn Sie eine Pod Identity-Zuordnung für ein Kubernetes-Dienstkonto erstellen, geben Sie sowohl eine Pod-IAM-Rolle im Clusterkonto als auch eine Ziel-IAM-Rolle im Workload-Konto an. EKS Pod Identity verwendet die Pod-Rolle, um die Zielrolle anzunehmen, und gibt temporäre Anmeldeinformationen für die Zielrolle an den Pod zurück.

In diesem AWS-Blog finden Sie eine ausführliche Anleitung und Überlegungen zu diesem Ansatz.

ABAC- und EKS-Pod-Identitäten für kontoübergreifenden Zugriff

Wenn Sie EKS Pod Identities verwenden, um im Rahmen einer Strategie für mehrere Konten Rollen (Rollenverkettung) in anderen Konten zu übernehmen, haben Sie die Möglichkeit, jedem Dienstkonto, das auf ein anderes Konto zugreifen muss, eine eigene IAM-Rolle zuzuweisen oder eine gemeinsame IAM-Rolle für mehrere Dienstkonten zu verwenden und mit ABAC zu steuern, auf welche Konten es zugreifen kann.

Um mit ABAC zu steuern, welche Dienstkonten eine Rolle in ein anderes Konto mit Rollenverkettung übernehmen können, erstellen Sie eine Rollenvertrauensrichtlinie, die es nur zulässt, dass eine Rolle von der Pod-IAM-Rolle aus dem EKS-Clusterkonto (Konto-ID 111122223333) übernommen wird, wenn die erwarteten Werte vorhanden sind. Mit der folgenden Rollenvertrauensrichtlinie kann die Pod-IAM-Rolle aus dem EKS-Clusterkonto nur dann eine Rolle übernehmenkubernetes-service-account, wenn die kubernetes-namespace Tags, eks-cluster-arn und alle den erwarteten Wert haben.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/account-a-role"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-service-account": "PayrollApplication",
                    "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:RequestTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

Sie können auch die Sitzungsrichtlinien von EKS Pod Identity verwenden, um die Berechtigungen für einen Pod weiter einzuschränken, ohne zusätzliche IAM-Rollen zu erstellen. Sitzungsrichtlinien werden angewendet, wenn EKS Pod Identity die Rolle übernimmt und die daraus resultierenden Berechtigungen die Schnittmenge zwischen der Rollenrichtlinie und der Sitzungsrichtlinie bilden. Überlegungen und detaillierte Schritte finden Sie im AWS-Container-Blog Sitzungsrichtlinien für Amazon EKS Pod Identity.

Bei der Verwendung dieser Strategie ist es eine bewährte Methode, sicherzustellen, dass die gemeinsame IAM-Rolle nur über sts:TagSession Berechtigungen sts:AssumeRole und keinen anderen AWS-Zugriff verfügt.

Bei der Verwendung von ABAC ist es wichtig, dass Sie kontrollieren, wer IAM-Rollen, Benutzer und STS-Sitzungen nur für Personen kennzeichnen darf, die dies unbedingt benötigen. Jemand, der über die Fähigkeit verfügt, eks- Tags zu setzenkubernetes-, kann möglicherweise Tags setzen, die mit denen identisch sind, die bei der Rollenverkettung von EKS Pod Identity übergeben würden, und kann seine Rechte erweitern. Sie können mithilfe der IAM-Richtlinie oder der Service Control Policy (SCP) einschränken, wer Zugriff auf das Setzen dieser Tags hat. Kontrollen finden Sie beispielsweise unter und. ProtectPodIdentitiesTagsOnRolesAndUsersSTS-Protect-EKS-pod-identities-tags

Wählen Sie zwischen EKS Pod Identities und IRSA

Sowohl IRSA- als auch EKS-Pod-Identitäten sind gültige Optionen für die Bereitstellung temporärer AWS-Anmeldeinformationen für Ihre EKS-Workloads. EKS-Pod-Identitäten werden für neue Anwendungen empfohlen, die auf unterstützten Knotentypen ausgeführt werden, und IRSA eignet sich gut für Anwendungen, die bereits über OIDC und IRSA verfügen oder auf Plattformen ausgeführt werden, die EKS Pod Identities nicht unterstützen.

Beachten Sie bei der Entscheidung, welche Sie verwenden möchten, Folgendes:

IRSA und EKS Pod Identities unterstützen beide Strategien für mehrere Konten. Sie können beide Methoden einheitlich in Ihrem Cluster verwenden oder ein gemischtes Modell verwenden, bei dem ältere Workloads weiterhin IRSA und neue Workloads EKS Pod Identities verwenden.

De-centralized EKS-Cluster

Bei diesem Ansatz werden EKS-Cluster für die jeweiligen Workload-AWS-Konten bereitgestellt und zusammen mit anderen AWS-Ressourcen wie Amazon S3 S3-Buckets, VPCs, Amazon DynamoDB-Tabellen usw. betrieben. Jedes Workload-Konto ist unabhängig, autark und wird von den jeweiligen Geschäftsteams betrieben. Unit/Application Dieses Modell ermöglicht die Erstellung wiederverwendbarer Blueprints für verschiedene Cluster-Funktionen — AI/ML Cluster, Batch-Verarbeitung, allgemeine Zwecke usw. — und die Cluster auf der Grundlage der Anforderungen des Anwendungsteams zu verkaufen. Sowohl Anwendungs- als auch Plattformteams arbeiten von ihren jeweiligen GitOpsRepositorys aus, um die Bereitstellungen in den Workload-Clustern zu verwalten.

Im obigen Diagramm werden Amazon EKS-Cluster und andere AWS-Ressourcen für die jeweiligen Workload-Konten bereitgestellt. Dann verwenden Workloads, die in EKS-Pods ausgeführt werden, IRSA- oder EKS-Pod-Identitäten, um auf ihre AWS-Ressourcen zuzugreifen.

GitOps ist eine Methode zur Verwaltung der Anwendungs- und Infrastrukturbereitstellung, sodass das gesamte System deklarativ in einem Git-Repository beschrieben wird. Es handelt sich um ein Betriebsmodell, das Ihnen die Möglichkeit bietet, den Status mehrerer Kubernetes-Cluster mithilfe der bewährten Methoden der Versionskontrolle, unveränderlicher Artefakte und Automatisierung zu verwalten. In diesem Multi-Cluster-Modell ist jeder Workload-Cluster mit mehreren Git-Repos ausgestattet, sodass jedes Team (Anwendung, Plattform, Sicherheit usw.) seine jeweiligen Änderungen auf dem Cluster implementieren kann.

Sie würden in jedem Konto IAM-Rollen für Service Accounts (IRSA) oder EKS-Pod-Identitäten verwenden, damit Ihre EKS-Workloads temporäre AWS-Anmeldeinformationen für den sicheren Zugriff auf andere AWS-Ressourcen erhalten können. IAM-Rollen werden in den jeweiligen Workload-AWS-Konten erstellt und ihnen k8s-Servicekonten zugeordnet, um temporären IAM-Zugriff zu ermöglichen. Bei diesem Ansatz ist also kein kontoübergreifender Zugriff erforderlich. Informationen zur Einrichtung der einzelnen Workloads für IRSA finden Sie in der Dokumentation zu IAM-Rollen für Dienstkonten und in der Dokumentation zu EKS Pod-Identitäten, wie Sie EKS-Pod-Identitäten in jedem Konto einrichten.

Zentralisiertes Netzwerk

Sie können AWS-RAM auch verwenden, um die VPC-Subnetze für Workload-Konten gemeinsam zu nutzen und Amazon EKS-Cluster und andere AWS-Ressourcen darin zu starten. Dies ermöglicht ein zentralisiertes Netzwerk managment/administration, eine vereinfachte Netzwerkkonnektivität und dezentrale EKS-Cluster. In diesem AWS-Blog finden Sie eine detaillierte Anleitung und Überlegungen zu diesem Ansatz.

Im obigen Diagramm wird AWS-RAM verwendet, um Subnetze von einem zentralen Netzwerkkonto für ein Workload-Konto gemeinsam zu nutzen. Dann werden EKS-Cluster und andere AWS-Ressourcen in diesen Subnetzen in den jeweiligen Workload-Konten gestartet. EKS-Pods verwenden IRSA- oder EKS-Pod-Identitäten, um auf ihre AWS-Ressourcen zuzugreifen.

Zentralisiert im Vergleich zu EKS-Clustern De-centralized

Die Entscheidung, mit einem zentralisierten oder einem zentralisierten System zu arbeiten, De-centralized hängt von Ihren Anforderungen ab. In dieser Tabelle werden die wichtigsten Unterschiede der einzelnen Strategien veranschaulicht.