本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

多账户策略

AWS 建议使用多账户策略和 AWS 组织来帮助隔离和管理您的业务应用程序和数据。使用多账户策略有很多好处：

以下各节将说明如何使用集中式或去中心化的 EKS 集群方法为 EKS 工作负载实施多账户策略。

为多租户集群规划多工作负载账户策略

在多账户 AWS 策略中，属于给定工作负载的资源（例如 S3 存储桶、 ElastiCache 集群和 DynamoDB 表）都是在包含该工作负载的所有资源的 AWS 账户中创建的。这些帐户被称为工作负载帐户，EKS 集群部署到称为集群帐户的账户中。下一节将探讨集群账户。将资源部署到专用工作负载账户与将 kubernetes 资源部署到专用命名空间类似。

然后，可以根据软件开发生命周期或其他要求（如果适用）进一步细分工作负载帐户。例如，给定的工作负载可以有一个生产账户、一个开发账户，或者一个用于在特定区域托管该工作负载的实例的账户。更多信息可在本 AWS 白皮书中找到。

在实施 EKS 多账户策略时，您可以采用以下方法：

集中式 EKS 集群

采用这种方法，您的 EKS 集群将部署在名为的单个 AWS 账户中Cluster Account。使用服务账户 (IRSA) 或 EKS Pod 身份的 IAM 角色来提供临时 AWS 证书，使用 AWS Resource Access Manager (RAM) 来简化网络访问，您可以为多租户 EKS 集群采用多账户策略。集群账户将包含 VPC、子网、EKS 集群、 EC2/Fargate 计算资源（工作节点）以及运行 EKS 集群所需的任何其他联网配置。

在多租户集群的多工作负载账户策略中，AWS 账户通常与 kubernetes 命名空间保持一致，以此作为隔离资源组的机制。在@@ 为多租户 EKS 集群实施多账户策略时，仍应遵循在 EKS 集群内进行租户隔离的最佳实践。

您的 AWS 组织Cluster Accounts中可能有多个，最佳做法是让多个Cluster Accounts符合您的软件开发生命周期需求的多个。对于大规模运行的工作负载，您可能需要多个，Cluster Accounts以确保有足够的 kubernetes 和 AWS 服务配额可供您的所有工作负载使用。

|在上图中，AWS RAM 用于将子网从集群账户共享到工作负载账户。然后，在 EKS 容器中运行的工作负载使用 IRSA 或 EKS Pod 身份和角色链在其工作负载账户中扮演角色并访问其 AWS 资源。

为多租户集群实施多工作负载账户策略

使用 AWS Resource Access Manager 共享子网

AWS Resource Access Manager (RAM) 允许您在 AWS 账户之间共享资源。

如果您的 AWS 组织启用了 RAM，则可以将集群账户中的 VPC 子网共享给您的工作负载账户。这将允许将您的工作负载账户拥有的 AWS 资源（例如亚马逊 ElastiCache集群或亚马逊关系数据库服务 (RDS) 数据库）部署到与您的 EKS 集群相同的 VPC 中，并且可供在 EKS 集群上运行的工作负载使用。

要通过 RAM 共享资源，请在集群账户的 AWS 控制台中打开 RAM，然后选择 “资源共享” 和 “创建资源共享”。命名您的资源共享并选择要共享的子网。再次选择 “下一步”，输入要与之共享子网的工作负载帐户的 12 位帐户 ID，再次选择 “下一步”，然后单击 “创建资源共享” 完成操作。完成此步骤后，工作负载帐户可以将资源部署到这些子网中。

也可以通过编程方式创建 RAM 共享，也可以使用基础架构即代码创建。

在 EKS Pod 身份和 IRSA 之间做出选择

在 re: Invent 2023 上，AWS 推出了 EKS Pod Identities，这是一种在 EKS 上向你的 pod 提供临时 AWS 证书的更简单方式。IRSA 和 EKS Pod 身份都是向您的 EKS 容器提供临时 AWS 证书的有效方法，并将继续得到支持。您应该考虑哪种交付方式最能满足您的需求。

在使用一个 EKS 集群和多个 AWS 账户时，IRSA 可以直接在 AWS 账户中扮演角色，而不是直接托管 EKS 集群的账户，而 EKS Pod 身份则需要您配置角色链。请参阅 EKS 文档进行深入比较。

使用服务账户的 IAM 角色访问 AWS API 资源

服务账户的 IAM 角色 (IRSA) 允许您向在 EKS 上运行的工作负载提供临时的 AWS 证书。IRSA 可用于从集群账户获取工作负载账户中 IAM 角色的临时证书。这允许您在集群账户中的 EKS 集群上运行的工作负载消耗 AWS API 资源，例如工作负载账户中托管的 S3 存储桶，并对 Amazon RDS 数据库或 Amazon EFS 等资源使用 IAM 身份验证。 FileSystems

在工作负载账户中使用 IAM 身份验证的 AWS API 资源和其他资源只能通过同一工作负载账户中的 IAM 角色的证书进行访问，除非支持跨账户访问且已明确启用。

启用 IRSA 进行跨账户访问

要为集群账户中的工作负载启用 IRSA 访问工作负载账户中的资源，您必须先在工作负载账户中创建 IAM OIDC 身份提供商。除了将在工作负载帐户中创建身份提供者之外，还可以使用与设置 IRSA 相同的步骤来完成此操作。

然后，在 EKS 上为工作负载配置 IRSA 时，您可以按照与文档相同的步骤进行操作，但要使用 “示例从其他账户的集群创建身份提供商” 一节中提到的工作负载帐户的 12 位数帐户 ID。

配置完成后，在 EKS 中运行的应用程序将能够直接使用其服务帐户在工作负载帐户中扮演角色，并使用其中的资源。

使用 EKS 容器身份访问 AWS API 资源

EKS Pod 身份提供了另一种向在 EKS 上运行的工作负载提供临时 AWS 证书的方法。EKS Pod Identities 与 EKS 控制平面和集群上代理集成，因此 Pod 无需您创建或管理 IAM OIDC 身份提供商即可接收证书。对于支持的节点类型上的新工作负载，推荐使用 EKS Pod Identities，而 IRSA 仍然是完全支持的替代方案。

使用 EKS Pod 身份，您可以将集群中的 Kubernetes 服务账户与集群所在的 AWS 账户中的 IAM 角色关联起来。EKS 使用此关联来获取该 IAM 角色的临时证书，并将其安全地交付给使用该服务账户的 pod。然后，您的应用程序可以使用标准 AWS 开发工具包和默认凭证链来调用 AWS API；无需自定义凭证提供程序或配置文件。

启用 EKS Pod 身份进行跨账户访问

EKS Pod Identities 通过在工作负载账户中使用目标 IAM 角色和 IAM 角色链原生支持跨账户访问。在为 Kubernetes 服务账户创建 Pod 身份关联时，您可以在集群账户中指定一个 pod IAM 角色，并在工作负载账户中指定目标 IAM 角色。EKS Pod Identity 使用 pod 角色担任目标角色，并将目标角色的临时证书返回给 pod。

有关此方法的详细演练和注意事项，请参阅此 AWS 博客。

用于跨账户访问的 ABAC 和 EKS Pod 身份

作为多账户策略的一部分，使用 EKS Pod Identities 在其他账户中扮演角色（角色链）时，您可以选择为需要访问另一个账户的每个服务账户分配一个唯一的 IAM 角色，或者在多个服务账户中使用通用 IAM 角色并使用 ABAC 来控制其可以访问的账户。

要使用 ABAC 控制哪些服务帐号可以通过角色链接将角色代入另一个账户，您需要创建一个角色信任策略声明，该声明仅允许在存在预期值时由 EKS 集群账户（账户 ID 111122223333）的 pod IAM 角色代入角色。只有在、eks-cluster-arn和kubernetes-namespace标签都具有预期值的情况下，以下角色信任策略才允许来自 EKS 集群账户的 pod IAM 角色代入角色。kubernetes-service-account

{
    "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 身份会话策略进一步缩小容器的权限范围，而无需创建其他 IAM 角色。会话策略在 EKS Pod Identity 担任角色时应用，由此产生的权限是角色策略和会话策略的交叉点；有关注意事项和详细步骤，请参阅 AWS Containers 博客 A mazon EKS Pod Identity 的会话策略。

使用此策略时，最佳做法是确保常见 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 身份都是向您的 EKS 工作负载提供临时 AWS 证书的有效选项。对于在支持的节点类型上运行的新应用程序，建议使用 EKS Pod 身份，而 IRSA 非常适合您已经安装了 OIDC 和 IRSA 或者在 EKS Pod Identitions 不支持的平台上运行的情况。

在决定要使用哪种方式时，请注意以下因素：

IRSA 和 EKS Pod 身份都支持多账户策略。你可以在集群中一致使用这两种方法，也可以采用混合模式，即传统工作负载继续使用 IRSA，而新的工作负载使用 EKS Pod Identities。

De-centralized EKS 集群

在这种方法中，EKS 集群部署到各自的工作负载 AWS 账户，并与其他 AWS 资源（例如 Amazon S3 存储桶、VPC、Amazon DynamoDB 表等）并存，每个工作负载账户都是独立的、自给自足的，由相应的业务团队运营。Unit/Application 该模型允许为各种集群功能（集群AI/ML 、批处理、通用等）创建可重复使用的蓝图，并根据应用团队的要求出售集群。应用程序和平台团队都通过各自的GitOps存储库进行操作，以管理工作负载集群的部署。

在上图中，Amazon EKS 集群和其他 AWS 资源部署到相应的工作负载账户。然后，在 EKS 容器中运行的工作负载使用 IRSA 或 EKS 容器身份访问其 AWS 资源。

GitOps 是一种管理应用程序和基础架构部署的方法，以便在 Git 存储库中以声明方式描述整个系统。它是一种操作模型，使您能够使用版本控制、不可变工件和自动化的最佳实践来管理多个 Kubernetes 集群的状态。在这种多集群模型中，每个工作负载集群都使用多个 Git 存储库进行引导，允许每个团队（应用程序、平台、安全等）在集群上部署各自的更改。

您将在每个账户中使用服务账户 (IRSA) 或 EKS Pod 身份的 IAM 角色来允许您的 EKS 工作负载获得临时的 aws 证书，从而安全地访问其他 AWS 资源。IAM 角色在相应的工作负载 AWS 账户中创建，并将其映射到 k8s 服务账户，以提供临时的 IAM 访问权限。因此，这种方法不需要跨账户访问权限。请按照服务账户的 IAM 角色文档了解如何在每个工作负载中为 IRSA 进行设置，以及有关如何在每个账户中设置 EKS 容器身份的 EKS Pod Identities 文档。

集中式联网

您还可以利用 AWS RAM 将 VPC 子网共享给工作负载账户，并在其中启动 Amazon EKS 集群和其他 AWS 资源。这支持集中式网络 managment/administration、简化的网络连接和去中心化的 EKS 集群。有关此方法的详细演练和注意事项，请参阅此 AWS 博客。

在上图中，AWS RAM 用于将子网从中央网络账户共享到工作负载账户。然后，EKS 集群和其他 AWS 资源将在相应的工作负载账户中的子网中启动。EKS 容器使用 IRSA 或 EKS 容器身份来访问其 AWS 资源。

集中式与 De-centralized EKS 集群

决定使用集中式还是 De-centralized 将取决于您的要求。下表说明了每种策略的主要区别。