为多租户集群规划多工作负载账户策略集中式 EKS 集群去中心化的 EKS 集群集中式与去中心化 EKS 集群

多账户策略

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

增加了 AWS API 服务配额。配额适用于 AWS 账户，使用多个账户处理工作负载会增加工作负载可用的总配额。
更简单的身份和访问管理 (IAM) 策略。仅向工作负载和支持他们的操作员授予访问他们自己的 AWS 账户的权限意味着可以减少为实现最小权限原则而制定精细的 IAM 策略的时间。
改进了 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 位数帐户，再次选择 “下一步”，然后单击 “创建资源共享” 完成操作。 IDs 完成此步骤后，工作负载帐户可以将资源部署到这些子网中。

也可以通过编程方式创建 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 身份则需要您配置角色链。有关深入比较，请参阅 E KS 文档。

使用服务账户的 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 Identitions 是一种向在 EKS 上运行的工作负载提供 AWS 凭证的新方式。EKS 容器身份简化了 AWS 资源的配置，因为您不再需要管理 OIDC 配置即可向 EKS 上的容器提供 AWS 证书。

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

与 IRSA 不同，EKS Pod 身份只能用于直接向与 EKS 集群相同的账户中的角色授予访问权限。要访问其他 AWS 账户中的角色，使用 EKS Pod 身份的 pod 必须执行角色链接。

可以使用各种 AWS 中提供的流程证书提供程序，在应用程序配置文件中使用其 aws 配置文件配置角色链。 SDKs 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环境变量。如果 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 容器身份进行角色链接配置角色信任策略时，您可以将 E KS 的特定属性作为会话标签，并使用基于属性的访问控制 (ABAC) 将对您的 IAM 角色的访问权限限制为仅限特定的 EKS Pod 身份会话，例如 Pod 所属的 Kubernetes 服务账户。

请注意，其中一些属性可能不是普遍唯一的，例如，两个 EKS 集群可能具有相同的命名空间，而一个集群可能在不同命名空间中具有相同名称的服务帐户。因此，在通过 EKS Pod Identities 和 ABAC 授予访问权限时，最佳做法是在向服务帐号授予访问权限时始终考虑集群 arn 和命名空间。

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

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

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


{
    "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 Identitions 设置的标签 roles/users 相同，并且可以升级其权限。您可以使用 IAM 策略或服务控制策略 (SCP) 限制谁有权在 IAM 角色和用户上设置标签和eks-标签。kubernetes-

去中心化的 EKS 集群

在这种方法中，EKS 集群部署到各自的工作负载 AWS 账户，并与其他 AWS 资源（例如 Amazon S3 存储桶 VPCs、Amazon DynamoDB 表等）并存。每个工作负载账户都是独立的、自给自足的，由相应的Unit/Application teams. This model allows the creation of reusuable blueprints for various cluster capabilities — 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 资源。这可以实现集中式网络管理/管理、简化的网络连接和去中心化的 EKS 集群。有关此方法的详细演练和注意事项，请参阅此 AWS 博客。

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

集中式与去中心化 EKS 集群

选择集中式还是去中心化模式将取决于您的要求。下表说明了每种策略的主要区别。

#	集中式 EKS 集群	去中心化的 EKS 集群
集群管理：	管理单个 EKS 集群比管理多个集群更容易	为了减少管理多个 EKS 集群的运营开销，必须实现高效的集群管理自动化
成本效益：	允许重复使用 EKS 集群和网络资源，从而提高成本效益	每个工作负载都需要网络和集群设置，这需要额外的资源
弹性：	如果集群受损，集中式集群上的多个工作负载可能会受到影响	如果集群受损，则损害仅限于在该集群上运行的工作负载。所有其他工作负载均不受影响
隔离和安全：	隔离/软多租户是使用 k8s 原生构造来实现的，比如。`Namespaces`工作负载可能共享底层资源，例如 CPU、内存等。AWS 资源被隔离到自己的工作负载账户中，默认情况下，其他 AWS 账户无法访问这些账户。	由于工作负载在不共享任何资源的单个集群和节点中运行，因此对计算资源进行更强的隔离。AWS 资源被隔离到自己的工作负载账户中，默认情况下，其他 AWS 账户无法访问这些账户。
性能和可扩展性：	随着工作负载增长到非常大的规模，您可能会在集群账户中遇到 kubernetes 和 AWS 服务配额。您可以部署其他集群账户以进一步扩展	随着集群越来越多，每个工作负载都有更多可用 k8s 和 VPCs AWS 服务配额
联网：	每个集群使用一个 VPC，从而简化了该集群上的应用程序的连接	必须在去中心化的 EKS 集群之间建立路由 VPCs
Kubernetes 访问管理：	需要在集群中维护许多不同的角色和用户，以便为所有工作负载团队提供访问权限并确保 kubernetes 资源得到适当隔离	简化了访问管理，因为每个集群都专用于工作负载/团队
AWS 访问管理：	AWS 资源部署到他们自己的账户中，默认情况下，只能通过工作负载账户中的 IAM 角色进行访问。工作负载账户中的 IAM 角色是跨账户假设的，可以是 IRSA 或 EKS Pod 身份。	AWS 资源部署到他们自己的账户中，默认情况下，只能通过工作负载账户中的 IAM 角色进行访问。工作负载账户中的 IAM 角色直接传送到具有 IRSA 或 EKS Pod 身份的 pod

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

映像安全

集群访问管理