規劃多租戶叢集的多工作負載帳戶策略集中式 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 身分可簡化 AWS 資源的組態，因為您不再需要管理 OIDC 組態，即可在 EKS 將 AWS 登入資料交付至您的 Pod。

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

與 IRSA 不同，EKS Pod 身分只能用來直接授予與 EKS 叢集相同帳戶中的角色存取權。若要存取另一個 AWS 帳戶中的角色，使用 EKS Pod 身分的 Pod 必須執行角色鏈結。

您可以使用各種 AWS SDKs中可用的程序登入資料提供者，在應用程式設定檔中設定角色鏈結及其 aws 組態檔案。 credential_process 可在設定設定檔時做為登入資料來源，例如：


# 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

Credential_process 呼叫的指令碼來源：


#!/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}'

您可以使用帳戶 A 和 B 角色建立 aws 組態檔案，並在 Pod 規格中指定 AWS_CONFIG_FILE 和 AWS_PROFILE env vars。如果 env vars 已存在於 Pod 規格中，EKS Pod 身分 Webhook 不會覆寫。


# 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

設定角色信任政策以使用 EKS Pod 身分進行角色鏈結時，您可以將 EKS 特定屬性參考為工作階段標籤，並使用屬性型存取控制 (ABAC)，將 IAM 角色的存取權限制為僅限特定 EKS Pod 身分工作階段，例如 Pod 所屬的 Kubernetes 服務帳戶。

請注意，其中一些屬性可能不是通用的，例如兩個 EKS 叢集可能具有相同的命名空間，而一個叢集可能具有跨命名空間的相同名稱服務帳戶。因此，透過 EKS Pod 身分和 ABAC 授予存取權時，最佳實務是在授予服務帳戶的存取權時，一律考慮叢集 Arn 和命名空間。

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

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

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


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

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

使用 ABAC 時，請務必控制誰能夠將 IAM 角色和使用者標記為僅需要標記的人員。能夠標記 IAM 角色或使用者的人員將能夠在角色/使用者上設定與 EKS Pod 身分所設定相同標籤，並且可以提升其權限。您可以使用 IAM 政策或服務控制政策 (SCP)，限制誰有權在 IAM 角色和使用者上設定 kubernetes-和 eks-標籤。

分散式 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 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

映像安全性

叢集存取管理