規劃多租戶叢集的多工作負載帳戶策略集中式 EKS 叢集分散式 EKS 叢集集中式與分散式 EKS 叢集

多帳戶策略

AWS 建議使用多帳戶策略和 AWS 組織來協助隔離和管理業務應用程式和資料。使用多帳戶策略有許多好處：

增加 AWS API 服務配額。配額會套用至 AWS 帳戶，而針對工作負載使用多個帳戶會增加工作負載可用的整體配額。
簡化 Identity and Access Management (IAM) 政策。授予工作負載和運算子僅支援他們存取自己的 AWS 帳戶，意味著減少制定精細 IAM 政策以實現最低權限原則的時間。
改善 AWS 資源的隔離。根據設計，帳戶內佈建的所有資源都會邏輯上與其他帳戶中佈建的資源隔離。此隔離界限可讓您限制應用程式相關問題、組態錯誤或惡意動作的風險。如果一個帳戶內發生問題，可以減少或消除對其他帳戶中所含工作負載的影響。
更多好處，如 AWS 多帳戶策略白皮書所述

下列各節將說明如何使用集中式或非集中式 EKS 叢集方法，為您的 EKS 工作負載實作多帳戶策略。

規劃多租戶叢集的多工作負載帳戶策略

在多帳戶 AWS 策略中，屬於指定工作負載的資源，例如 S3 儲存貯體、ElastiCache 叢集和 DynamoDB Tables，都會在包含該工作負載所有資源的 AWS 帳戶中建立。這些稱為工作負載帳戶，EKS 叢集會部署到稱為叢集帳戶的帳戶中。叢集帳戶將在下一節中探索。將資源部署到專用工作負載帳戶類似於將 kubernetes 資源部署到專用命名空間。

工作負載帳戶接著可以依軟體開發生命週期或其他適當需求進一步細分。例如，指定的工作負載可以擁有生產帳戶、開發帳戶，或在特定區域中託管該工作負載執行個體的帳戶。如需詳細資訊，請參閱本 AWS 白皮書。

您可以在實作 EKS 多帳戶策略時採用下列方法：

集中式 EKS 叢集

在此方法中，您的 EKS 叢集將部署在名為的單一 AWS 帳戶中Cluster Account。使用服務帳戶 (IRSA) 或 EKS Pod 身分的 IAM 角色交付臨時 AWS 登入資料和 AWS Resource Access Manager (RAM) 來簡化網路存取，您可以為多租戶 EKS 叢集採用多帳戶策略。 https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html叢集帳戶將包含 VPC、子網路、EKS 叢集、EC2/Fargate 運算資源（工作者節點），以及執行 EKS 叢集所需的任何其他聯網組態。

在多租戶叢集的多工作負載帳戶策略中，AWS 帳戶通常會與 kubernetes 命名空間保持一致，做為隔離資源群組的機制。為多租戶 EKS 叢集實作多帳戶策略時，仍應遵循 EKS 叢集內的租戶隔離最佳實務。

您可以在 Cluster Accounts AWS 組織中擁有多個，而且最佳實務是擁有多個 Cluster Accounts，以符合您的軟體開發生命週期需求。對於大規模操作的工作負載，您可能需要多個 Cluster Accounts ，以確保有足夠的 kubernet 和 AWS 服務配額可供所有工作負載使用。

|在上圖中，AWS RAM 用於將子網路從叢集帳戶共用到工作負載帳戶。然後，在 EKS Pod 中執行的工作負載會使用 IRSA 或 EKS Pod 身分和角色鏈結，在其工作負載帳戶中擔任角色並存取其 AWS 資源。

為多租戶叢集實作多工作負載帳戶策略

與 AWS Resource Access Manager 共用子網路

AWS Resource Access Manager (RAM) 可讓您跨 AWS 帳戶共用資源。

如果您的 AWS Organization 已啟用 RAM，您可以將 VPC 子網路從叢集帳戶共用至工作負載帳戶。這將允許工作負載帳戶擁有的 AWS 資源，例如 Amazon ElastiCache 叢集或 Amazon Relational Database Service (RDS) 資料庫，部署到與 EKS 叢集相同的 VPC 中，並可供在 EKS 叢集上執行的工作負載使用。

若要透過 RAM 共用資源，請在叢集帳戶的 AWS 主控台中開啟 RAM，然後選取「資源共用」和「建立資源共用」。為您的資源共用命名，然後選取您要共用的子網路。再次選取下一步，然後輸入您要與其共用子網路之工作負載帳戶的 IDs，再選取一次，然後按一下建立資源共用以完成。在此步驟之後，工作負載帳戶可以將資源部署到這些子網路。

RAM 共用也可以以程式設計方式建立，或使用基礎設施做為程式碼。

在 EKS Pod 身分和 IRSA 之間進行選擇

在 re：Invent 2023 上，AWS 啟動了 EKS Pod 身分，作為在 EKS 上將臨時 AWS 登入資料交付至 Pod 的更簡單方式。IRSA 和 EKS Pod 身分都是將臨時 AWS 登入資料交付至 EKS Pod 的有效方法，將持續受到支援。您應該考慮哪種交付方法最符合您的需求。

使用 EKS 叢集和多個 AWS 帳戶時，IRSA 可以直接在 EKS 叢集託管帳戶以外的 AWS 帳戶中擔任角色，而 EKS Pod 身分需要您設定角色鏈結。如需深入比較，請參閱 EKS 文件。

使用服務帳戶的 IAM 角色存取 AWS API 資源

服務帳戶的 IAM 角色 (IRSA) 可讓您將臨時 AWS 登入資料交付至在 EKS 上執行的工作負載。IRSA 可用來從叢集帳戶取得工作負載帳戶中 IAM 角色的臨時登入資料。這可讓您在叢集帳戶中的 EKS 叢集上執行的工作負載，以無預警的方式取用 AWS API 資源，例如工作負載帳戶中託管的 S3 儲存貯體，並針對 Amazon RDS 資料庫或 Amazon EFS FileSystems 等資源使用 IAM 身分驗證。

在工作負載帳戶中使用 IAM 身分驗證的 AWS API 資源和其他資源只能由相同工作負載帳戶中 IAM 角色的憑證存取，除非跨帳戶存取能夠且已明確啟用。

啟用 IRSA 進行跨帳戶存取

若要讓叢集帳戶中工作負載的 IRSA 存取工作負載帳戶中的資源，您必須先在工作負載帳戶中建立 IAM OIDC 身分提供者。這可以透過設定 IRSA 的相同程序來完成，但將在工作負載帳戶中建立身分提供者。

然後，在 EKS 上設定工作負載的 IRSA 時，您可以遵循與文件相同的步驟，但使用工作負載帳戶的 12 位數帳戶 ID，如「從另一個帳戶的叢集建立身分提供者範例」一節所述。

設定完成後，在 EKS 中執行的應用程式將能夠直接使用其服務帳戶來擔任工作負載帳戶中的角色，並使用其中的資源。

使用 EKS Pod 身分存取 AWS API 資源

EKS Pod 身分提供另一種方式，可將臨時 AWS 登入資料交付至在 EKS 上執行的工作負載。EKS Pod 身分與 EKS 控制平面和叢集上代理程式整合，讓 Pod 接收登入資料，而不需要您建立或管理 IAM OIDC 身分提供者。對於支援節點類型上的新工作負載，EKS Pod 身分是建議的方法，而 IRSA 仍然是完全支援的替代方案。

使用 EKS Pod 身分，您可以將叢集中的 Kubernetes 服務帳戶與叢集所在相同 AWS 帳戶中的 IAM 角色建立關聯。EKS 使用此關聯來取得該 IAM 角色的臨時登入資料，並將其安全地交付給使用該服務帳戶的 Pod。然後，您的應用程式可以使用標準 AWS SDKs和預設登入資料鏈來呼叫 AWS APIs；不需要自訂登入資料提供者或組態檔案。

啟用跨帳戶存取的 EKS Pod 身分

EKS Pod 身分透過在工作負載帳戶和 IAM 角色鏈結中使用目標 IAM 角色，原生支援跨帳戶存取。當您為 Kubernetes 服務帳戶建立 Pod Identity 關聯時，您可以在叢集帳戶中指定 Pod IAM 角色，並在工作負載帳戶中指定目標 IAM 角色。EKS Pod Identity 使用 Pod 角色擔任目標角色，並將目標角色的臨時登入資料傳回 Pod。

如需此方法的詳細演練和考量事項，請參閱此 AWS 部落格。

跨帳戶存取的 ABAC 和 EKS Pod 身分

使用 EKS Pod 身分作為多帳戶策略的一部分在其他帳戶中擔任角色（角色鏈結）時，您可以選擇為每個需要存取另一個帳戶的服務帳戶指派唯一的 IAM 角色，或跨多個服務帳戶使用通用 IAM 角色，並使用 ABAC 控制其可存取的帳戶。

若要使用 ABAC 來控制哪些服務帳戶可以使用角色鏈結來擔任另一個帳戶的角色，您可以建立角色信任政策陳述式，當預期值存在時，僅允許來自 EKS 叢集帳戶（帳戶 ID 111122223333) 的 Pod IAM 角色擔任角色。下列角色信任政策只會讓來自 EKS 叢集帳戶的 Pod IAM 角色在 kubernetes-service-accounteks-cluster-arn和 kubernetes-namespace標籤都具有預期值時擔任角色。


{
    "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"
                }
            }
        }
    ]
}

您也可以使用 EKS Pod Identity 工作階段政策進一步縮小 Pod 的許可範圍，而無需建立其他 IAM 角色。當 EKS Pod Identity 擔任角色且產生的許可是角色政策和工作階段政策的交集時，會套用工作階段政策；如需考量和詳細步驟，請參閱 Amazon EKS Pod Identity 的 AWS Containers 部落格工作階段政策。

使用此策略時，最佳實務是確保常見的 IAM 角色只有 sts:AssumeRole和 sts:TagSession許可，且沒有其他 AWS 存取。

使用 ABAC 時，請務必控制誰能夠將 IAM 角色、使用者和 STS 工作階段標記為僅需要標記的人員。具有設定 kubernetes- 或 eks- 標籤功能的人，可以設定與 EKS Pod Identity 角色鏈結期間傳遞的標籤相同的標籤，也可以提升其權限。您可以限制誰有權使用 IAM 政策或服務控制政策 (SCP) 設定這些標籤；例如控制項，請參閱 ProtectPodIdentitiesTagsOnRolesAndUsers 和 STS-Protect-EKS-pod-identities-tags。

在 EKS Pod 身分和 IRSA 之間進行選擇

IRSA 和 EKS Pod 身分都是將臨時 AWS 登入資料交付至 EKS 工作負載的有效選項。對於在支援的節點類型上執行的新應用程式，建議使用 EKS Pod 身分，而且 IRSA 非常適合您已有 OIDC 和 IRSA，或在 EKS Pod 身分不支援的平台上執行。

在決定要使用哪個時，請考慮下列事項：

在下列情況下選擇 EKS Pod 身分：
- 您正在設計新的工作負載，並希望避免建立和管理 IAM OIDC 身分提供者。
- 您想要使用目標 IAM 角色進行跨帳戶存取的原生支援，而無需將自訂登入資料指令碼或 AWS 組態檔案新增至您的 Pod。
- 您偏好叢集管理員管理哪些 Kubernetes 服務帳戶可以擔任哪些角色，而 IAM 管理員則管理這些角色的許可。
- 您希望憑證販賣有效率地擴展，並避免達到 IAM Quota 限制。
在下列情況下選擇 IRSA：
- 您已成功使用 IRSA，並具有 OIDC 提供者和 IAM 角色的標準模式。
- 您的工作負載會在不支援 EKS Pod 身分的環境中執行，例如 AWS Fargate、Windows 節點，或使用不支援的 AWS SDKs的應用程式。
- 您需要工作負載帳戶中角色的直接 OIDC 型聯合模型，而且您的安全控制已經以 OIDC 供應商為基礎建置。

IRSA 和 EKS Pod 身分都支援多帳戶策略。您可以在叢集中一致地使用方法，或採用混合模型，其中舊版工作負載會繼續使用 IRSA，而新工作負載則會使用 EKS Pod 身分。

分散式 EKS 叢集

在此方法中，EKS 叢集會部署到各自的工作負載 AWS 帳戶，並與其他 AWS 資源一起運作，例如 Amazon S3 儲存貯體、VPCs、Amazon DynamoDB 資料表等，每個工作負載帳戶都是獨立的、自給自足的，並由各自的業務單位/應用程式團隊運作。此模型允許為各種叢集功能建立可重複使用的藍圖： AI/ML 叢集、批次處理、一般用途等，並根據應用程式團隊需求提供叢集。應用程式和平台團隊都會在各自的 GitOps 儲存庫之外操作，以管理工作負載叢集的部署。

在上圖中，Amazon EKS 叢集和其他 AWS 資源會部署到各自的工作負載帳戶。然後，在 EKS Pod 中執行的工作負載會使用 IRSA 或 EKS Pod 身分來存取其 AWS 資源。

GitOps 是管理應用程式和基礎設施部署的一種方式，以便在 Git 儲存庫中宣告地描述整個系統。這是一種操作模型，可讓您使用版本控制、不可變成品和自動化的最佳實務來管理多個 Kubernetes 叢集的狀態。在此多叢集模型中，每個工作負載叢集都會使用多個 Git 儲存庫啟動，允許每個團隊（應用程式、平台、安全性等）在叢集上部署各自的變更。

您可以在每個帳戶中使用服務帳戶 (IRSA) 或 EKS Pod 身分的 IAM 角色，讓您的 EKS 工作負載取得臨時 aws 登入資料，以安全地存取其他 AWS 資源。 https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html在個別工作負載 AWS 帳戶中建立 IAM 角色，並將其映射至 k8s 服務帳戶，以提供暫時 IAM 存取。因此，此方法不需要跨帳戶存取。遵循服務帳戶的 IAM 角色文件，了解如何在 IRSA 的每個工作負載中設定，以及 EKS Pod 身分文件，了解如何在每個帳戶中設定 EKS Pod 身分。

集中式聯網

您也可以利用 AWS RAM 將 VPC 子網路共用至工作負載帳戶，並在其中啟動 Amazon EKS 叢集和其他 AWS 資源。這可實現集中式網路管理/管理、簡化的網路連線，以及分散式 EKS 叢集。如需此方法的詳細演練和考量，請參閱此 AWS 部落格。

在上圖中，AWS RAM 用於將子網路從中央聯網帳戶共用到工作負載帳戶。然後，EKS 叢集和其他 AWS 資源會在個別工作負載帳戶中的這些子網路中啟動。EKS Pod 使用 IRSA 或 EKS Pod 身分來存取其 AWS 資源。

集中式與分散式 EKS 叢集

使用集中式或非集中式執行的決定將取決於您的需求。此表示範每個策略的主要差異。

#	集中式 EKS 叢集	分散式 EKS 叢集
叢集管理：	管理單一 EKS 叢集比管理多個叢集更容易	為了降低管理多個 EKS 叢集的操作負荷，需要有效率的叢集管理自動化
成本效益：	允許重複使用 EKS 叢集和網路資源，以提高成本效益	需要每個工作負載的聯網和叢集設定，這需要額外的資源
彈性：	如果叢集受損，集中式叢集上的多個工作負載可能會受到影響	如果叢集受損，則損壞僅限於在該叢集上執行的工作負載。所有其他工作負載不受影響
隔離與安全：	隔離/軟多租用戶是使用 k8s 原生建構達成的，例如 `Namespaces`。工作負載可能會共用基礎資源，例如 CPU、記憶體等。AWS 資源會隔離到自己的工作負載帳戶，預設情況下無法從其他 AWS 帳戶存取。	當工作負載在未共用任何資源的個別叢集和節點中執行時，對運算資源進行更強大的隔離。AWS 資源會隔離到自己的工作負載帳戶，預設情況下無法從其他 AWS 帳戶存取。
效能與擴展：	隨著工作負載擴展到非常大的規模，您可能會在叢集帳戶中遇到 kubernet 和 AWS 服務配額。您可以部署額外的叢集帳戶以進一步擴展	隨著存在更多叢集和 VPCs，每個工作負載都有更多可用的 k8s 和 AWS 服務配額
網路：	每個叢集使用單一 VPC，為該叢集上的應用程式提供更簡單的連線	必須在分散式 EKS 叢集 VPCs 之間建立路由
Kubernetes Access Management：	需要在叢集中維護許多不同的角色和使用者，以便為所有工作負載團隊提供存取權，並確保已正確隔離 kubernetes 資源	簡化存取管理，因為每個叢集專用於工作負載/團隊
AWS Access Management：	AWS 資源會部署到自己的帳戶，預設只能透過工作負載帳戶中的 IAM 角色存取。工作負載帳戶中的 IAM 角色會擔任具有 IRSA 或 EKS Pod 身分的跨帳戶。	AWS 資源會部署到自己的帳戶，預設只能透過工作負載帳戶中的 IAM 角色存取。工作負載帳戶中的 IAM 角色會直接交付至具有 IRSA 或 EKS Pod 身分的 Pod

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

映像安全性

叢集存取管理