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:
-
Höhere AWS-API-Servicekontingente. Kontingente werden auf AWS-Konten angewendet, und wenn Sie mehrere Konten für Ihre Workloads verwenden, erhöht sich das für Ihre Workloads verfügbare Gesamtkontingent.
-
Einfachere Richtlinien für Identity and Access Management (IAM). Wenn Sie Workloads und den Betreibern, die sie unterstützen, nur Zugriff auf ihre eigenen AWS-Konten gewähren, bedeutet dies weniger Zeit für die Erstellung detaillierter IAM-Richtlinien, um das Prinzip der geringsten Rechte zu erreichen.
-
Verbesserte Isolierung von AWS-Ressourcen. Standardmäßig sind alle innerhalb eines Kontos bereitgestellten Ressourcen logisch von Ressourcen isoliert, die in anderen Konten bereitgestellt werden. Diese Isolationsgrenze bietet Ihnen die Möglichkeit, das Risiko anwendungsbezogener Probleme, Fehlkonfigurationen oder böswilliger Aktionen zu begrenzen. Wenn ein Problem innerhalb eines Kontos auftritt, können die Auswirkungen auf die Workloads anderer Konten entweder reduziert oder vermieden werden.
-
Weitere Vorteile, wie im Whitepaper AWS Multi Account Strategy beschrieben
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)
In einer Multi-Workload-Kontostrategie für Multi-Tenant-Cluster orientieren sich AWS-Konten in der Regel an Kubernetes-Namespaces
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
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
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 das 12-stellige 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 Identities ist eine neue Methode zur Bereitstellung von AWS-Anmeldeinformationen für Ihre Workloads, die auf EKS ausgeführt werden. EKS-Pod-Identitäten vereinfachen die Konfiguration von AWS-Ressourcen, da Sie keine OIDC-Konfigurationen mehr verwalten müssen, um AWS-Anmeldeinformationen für Ihre Pods auf EKS bereitzustellen.
Aktivierung von EKS-Pod-Identitäten für kontoübergreifenden Zugriff
Im Gegensatz zu IRSA können EKS-Pod-Identitäten nur verwendet werden, um direkten Zugriff auf eine Rolle in demselben Konto wie der EKS-Cluster zu gewähren. Um auf eine Rolle in einem anderen AWS-Konto zuzugreifen, müssen Pods, die EKS-Pod-Identitäten verwenden, eine Rollenverkettung durchführen.
Die Rollenverkettung kann in einem Anwendungsprofil mit der zugehörigen AWS-Konfigurationsdatei mithilfe des in verschiedenen AWS SDKs verfügbaren Process Credentials Provider konfiguriert werden. credential_processkann bei der Konfiguration eines Profils als Quelle für Anmeldeinformationen verwendet werden, z. B.:
# Content of the AWS Config file [profile account_b_role] source_profile = account_a_role role_arn = arn:aws:iam::444455556666:role/account-b-role [profile account_a_role] credential_process = /eks-credential-processrole.sh
Die Quelle des von credentials al_process aufgerufenen Skripts:
#!/bin/bash # Content of the eks-credential-processrole.sh # This will retreive the credential from the pod identities agent, # and return it to the AWS SDK when referenced in a profile curl -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c '{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}'
Sie können wie oben gezeigt eine AWS-Konfigurationsdatei mit den Rollen Konto A und B erstellen und die Variablen AWS_CONFIG_FILE und AWS_PROFILE env in Ihrer Pod-Spezifikation angeben. Der EKS Pod Identity-Webhook überschreibt nicht, ob die Umgebungsvariablen bereits in der Pod-Spezifikation vorhanden sind.
# Snippet of the PodSpec containers: - name: container-name image: container-image:version env: - name: AWS_CONFIG_FILE value: path-to-customer-provided-aws-config-file - name: AWS_PROFILE value: account_b_role
Bei der Konfiguration von Richtlinien zur Rollenvertrauensstellung für die Rollenverkettung mit EKS-Pod-Identitäten können Sie EKS-spezifische Attribute als Sitzungs-Tags referenzieren und mithilfe der attributebasierten Zugriffskontrolle (ABAC) den Zugriff auf Ihre IAM-Rollen auf bestimmte EKS-Pod-Identitätssitzungen beschränken, z. B. auf das Kubernetes-Dienstkonto, zu dem ein Pod gehört.
Bitte beachten Sie, dass einige dieser Attribute möglicherweise nicht allgemein eindeutig sind. Beispielsweise können zwei EKS-Cluster identische Namespaces haben, und ein Cluster kann identische Dienstkonten in allen Namespaces haben. Wenn Sie also Zugriff über EKS Pod Identities und ABAC gewähren, empfiehlt es sich, bei der Gewährung des Zugriffs auf ein Dienstkonto immer den Cluster-ARN und den Namespace zu berücksichtigen.
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 erlaubt, dass eine Rolle von einer Rollensitzung übernommen wird, wenn die erwarteten Werte vorliegen. Mit der folgenden Richtlinie zur Rollenvertrauensstellung kann eine Rolle aus dem EKS-Clusterkonto (Konto-ID 111122223333) nur dann eine Rolle übernehmen, wenn die kubernetes-namespace Tagskubernetes-service-account, eks-cluster-arn und alle den erwarteten Wert haben.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:PrincipalTag/kubernetes-service-account": "PayrollApplication", "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster", "aws:PrincipalTag/kubernetes-namespace": "PayrollNamespace" } } } ] }
Bei der Verwendung dieser Strategie ist es eine bewährte Methode, sicherzustellen, dass die gemeinsame IAM-Rolle nur über sts:AssumeRole Berechtigungen und keinen anderen AWS-Zugriff verfügt.
Bei der Verwendung von ABAC ist es wichtig, dass Sie kontrollieren, wer IAM-Rollen und -Benutzer kennzeichnen darf, und zwar nur für diejenigen, die dies unbedingt benötigen. Jemand, der in der Lage ist, eine IAM-Rolle oder einen IAM-Benutzer zu taggen, könnte Tags auf roles/users identische Tags setzen, wie sie von EKS Pod Identities gesetzt würden, und möglicherweise seine Rechte erweitern. Mithilfe der IAM-Richtlinie oder der Service Control Policy (SCP) können Sie einschränken, wer Zugriff darauf hat, eks- Tags kubernetes- und Tags für IAM-Rollen und Benutzer festzulegen.
Dezentrale 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 vom jeweiligen Unit/Application teams. This model allows the creation of reusuable
blueprints for various cluster capabilities — AI/ML Business-Cluster, Batch-Verarbeitung, Allzweck usw. betrieben — und verkauft die Cluster auf der Grundlage der Anforderungen des Anwendungsteams. Sowohl Anwendungs- als auch Plattformteams arbeiten von ihren jeweiligen GitOps
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 eine zentrale Netzwerkverwaltung/-verwaltung, eine vereinfachte Netzwerkkonnektivität und dezentrale EKS-Cluster. In diesem AWS-Blog
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.
Zentralisierte und dezentrale EKS-Cluster
Die Entscheidung, mit einem zentralisierten oder dezentralen System zu arbeiten, hängt von Ihren Anforderungen ab. Diese Tabelle zeigt die wichtigsten Unterschiede der einzelnen Strategien.
| # | Zentralisierter EKS-Cluster | Dezentralisierte EKS-Cluster |
|---|---|---|
|
Clusterverwaltung: |
Die Verwaltung eines einzelnen EKS-Clusters ist einfacher als die Verwaltung mehrerer Cluster |
Eine effiziente Automatisierung der Clusterverwaltung ist erforderlich, um den betrieblichen Aufwand für die Verwaltung mehrerer EKS-Cluster zu reduzieren |
|
Kosteneffizienz: |
Ermöglicht die Wiederverwendung von EKS-Cluster- und Netzwerkressourcen, was die Kosteneffizienz fördert |
Erfordert Netzwerk- und Cluster-Setups pro Workload, was zusätzliche Ressourcen erfordert |
|
Belastbarkeit: |
Mehrere Workloads auf dem zentralisierten Cluster können beeinträchtigt werden, wenn ein Cluster beeinträchtigt wird |
Wenn ein Cluster beeinträchtigt wird, beschränkt sich der Schaden nur auf die Workloads, die auf diesem Cluster ausgeführt werden. Alle anderen Workloads sind davon nicht betroffen |
|
Isolierung und Sicherheit: |
Isolation/Soft-Mehrmandantenfähigkeit wird durch die Verwendung nativer k8s-Konstrukte wie erreicht. |
Stärkere Isolierung der Rechenressourcen, da die Workloads in einzelnen Clustern und Knoten ausgeführt werden, die sich keine Ressourcen teilen. AWS-Ressourcen sind in ihren eigenen Workload-Konten isoliert, auf die standardmäßig von anderen AWS-Konten aus nicht zugegriffen werden kann. |
|
Leistung und Skalierbarkeit: |
Wenn Workloads sehr groß werden, kann es sein, dass Kubernetes- und AWS-Servicequotas im Cluster-Konto auftreten. Sie können zusätzliche Cluster-Konten bereitstellen, um noch weiter zu skalieren |
Je mehr Cluster vorhanden VPCs sind, desto mehr verfügbare K8s und AWS-Servicequoten stehen für jeden Workload zur Verfügung. |
|
Netzwerkbetrieb: |
Pro Cluster wird eine einzige VPC verwendet, was eine einfachere Konnektivität für Anwendungen auf diesem Cluster ermöglicht |
Das Routing muss zwischen dem dezentralen EKS-Cluster eingerichtet werden VPCs |
|
Kubernetes-Zugriffsverwaltung: |
Sie müssen viele verschiedene Rollen und Benutzer im Cluster verwalten, um allen Workload-Teams Zugriff zu gewähren und sicherzustellen, dass die Kubernetes-Ressourcen ordnungsgemäß getrennt sind |
Vereinfachtes Zugriffsmanagement, da jeder Cluster einer Workload/einem Team zugewiesen ist |
|
AWS-Zugriffsmanagement: |
AWS-Ressourcen werden in einem eigenen Konto bereitgestellt, auf das standardmäßig nur mit IAM-Rollen im Workload-Konto zugegriffen werden kann. IAM-Rollen in den Workload-Konten werden kontenübergreifend entweder mit IRSA- oder EKS-Pod-Identitäten übernommen. |
AWS-Ressourcen werden in einem eigenen Konto bereitgestellt, auf das standardmäßig nur mit IAM-Rollen im Workload-Konto zugegriffen werden kann. IAM-Rollen in den Workload-Konten werden direkt an Pods mit IRSA- oder EKS-Pod-Identitäten bereitgestellt |
