**帮助改进此页面**
要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。
# 了解 Amazon EKS 中的访问控制工作原理
了解如何管理对您的 Amazon EKS 集群的访问权限。使用 Amazon EKS 需要了解 Kubernetes 和 AWS Identity and Access Management（AWS IAM）如何处理访问控制。
**本部分包括：**
**[向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)** – 了解如何允许应用程序或用户对 Kubernetes API 进行身份验证。您可以使用访问条目、aws-auth ConfigMap 或外部 OIDC 提供商。
**[在 AWS 管理控制台中查看 Kubernetes 资源](view-kubernetes-resources.md)** – 了解如何将 AWS 管理控制台 配置为与 Amazon EKS 集群进行通信。使用控制台查看集群中的 Kubernetes 资源，例如命名空间、节点和容器组（pod）。
**[向 AWS 服务授予对 Kubernetes API 的写入权限](mutate-kubernetes-resources.md)**：了解修改 Kubernetes 资源所需的权限。
**[通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)** – 了解如何将 kubectl 配置为与 Amazon EKS 集群进行通信。请使用 AWS CLI 创建 kubeconfig 文件。
**[使用 Kubernetes 服务账户授予 Kubernetes 工作负载访问 AWS 的权限](service-accounts.md)** – 了解如何将 Kubernetes 服务账户与 AWS IAM 角色关联。您可以将容器组身份或 IAM 角色用于服务账户的（IRSA）。
## 常见任务
+ 向开发人员授予对 Kubernetes API 的访问权限。在 AWS 管理控制台中查看 Kubernetes 资源。
+ 解决方案：[使用访问条目](access-entries.md)将 Kubernetes RBAC 权限与 AWS IAM 用户或角色相关联。
+ 将 kubectl 配置为使用 AWS 凭证与 Amazon EKS 集群通信。
+ 解决方案使用 AWS CLI [创建 kubeconfig 文件](create-kubeconfig.md)。
+ 使用外部身份提供者（例如 Ping Identity）对 Kubernetes API 进行用户身份验证。
+ 解决方案：[链接外部 OIDC 提供商](authenticate-oidc-identity-provider.md)。
+ 授予 Kubernetes 集群上的工作负载调用 AWS API 的能力。
+ 解决方案：[使用容器组身份](pod-identities.md)将 AWS IAM 角色与 Kubernetes 服务账户关联。
## 背景
+ [了解 Kubernetes 服务账户的工作原理。](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [查看 Kubernetes 基于角色的访问控制（RBAC）模型](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ 有关管理对 AWS 资源的访问权限的更多信息，请参阅《AWS IAM 用户指南》[https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html)。或者，请参加[有关使用 AWS IAM 的免费入门培训](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam)。
## EKS 自动模式注意事项
EKS 自动模式与 EKS 容器组身份和 EKS 访问条目集成。
+ EKS 自动模式使用访问条目向 EKS 控制面板授予 Kubernetes 权限。例如，访问策略允许 EKS 自动模式读取有关网络端点和服务的信息。
+ 您不能在 EKS 自动模式集群上禁用访问条目。
+ 您可以选择启用 `aws-auth` `ConfigMap`。
+ EKS 自动模式的访问条目是自动配置的。您可以查看这些访问条目，但不能对其进行修改。
+ 如果您使用节点类创建自定义节点 IAM 角色，则需要使用 AmazonEKSAutoNodePolicy 访问策略为该角色创建访问条目。
+ 要向工作负载授予 AWS 服务的权限，请使用 EKS 容器组身份。
+ 您无需在 EKS 自动模式集群上安装容器组身份代理。
# 向 IAM 用户和角色授予对 Kubernetes API 的访问权限
集群有一个 Kubernetes API 端点。Kubectl 使用此 API。您可以使用两种类型的身份对此 API 进行身份验证：
+ **AWS Identity and Access Management（IAM）*主体*（角色或用户）**– 此类型需要对 IAM 进行身份验证。用户可以使用通过身份源提供的凭证以 [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 用户或[联合身份](https://aws.amazon.com/identity/federation/)登录到 AWS。如果您的管理员以前使用 IAM 角色设置了身份联合验证，则用户只能使用联合身份登录。当用户使用联合身份验证访问 AWS 时，他们就是在间接[分派角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole)。当用户使用此类身份时，您：
+ 可以为用户分配 Kubernetes 权限，以便他们使用集群上的 Kubernetes 对象。有关如何为 IAM 主体分配权限以便他们能够访问集群上的 Kubernetes 对象的更多信息，请参阅[使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。
+ 可以为他们分配 IAM 权限，以便其使用 Amazon EKS API、AWS CLI、AWS、AWS 管理控制台 CloudFormation 或 `eksctl` 使用您的 Amazon EKS 集群及其资源。有关更多信息，请参阅《服务授权参考》中的 [Amazon Elastic Kubernetes Service 定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。
+ 节点通过分派 IAM 角色加入您的集群。使用 IAM 主体访问集群的能力由[适用于 Kubernetes 的 AWS IAM 身份验证器](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme)提供，该工具在 Amazon EKS 控制面板上运行。
+ **您自己的 OpenID Connect（OIDC）提供者中的用户** – 此类型需要对您的 [OIDC](https://openid.net/connect/) 提供者进行身份验证。有关使用 Amazon EKS 集群设置自己的 OIDC 提供者的更多信息，请参阅[通过外部 OIDC 提供者向用户授予 Kubernetes 访问权限](authenticate-oidc-identity-provider.md)。当用户使用此类身份时，您：
+ 可以为用户分配 Kubernetes 权限，以便他们使用集群上的 Kubernetes 对象。
+ 无法向他们分配 IAM 权限，使他们能够使用 Amazon EKS API、AWS CLI、AWS CloudFormation、AWS 管理控制台或 `eksctl` 使用您的 Amazon EKS 集群及其资源。
您可以在集群中使用这两种类型的身份。IAM 身份验证方法无法禁用。OIDC 身份验证方法是可选的。
## 将 IAM 身份与 Kubernetes 权限相关联
[适用于 Kubernetes 的 AWS IAM 身份验证器](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme)安装在集群的控制面板上。该工具使您允许的 [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)（IAM）主体（角色和用户）能够访问集群上的 Kubernetes 资源。您可以使用以下某一种方法，允许 IAM 主体访问集群上的 Kubernetes 对象：
+ **创建访问条目** – 如果集群的 Kubernetes 版本等于或高于[先决条件](access-entries.md)部分所列的平台版本，建议使用此选项。
使用*访问条目*管理集群外的 IAM 主体的 Kubernetes 权限。您可以使用 EKS API、AWS 命令行界面、AWS SDK、AWS CloudFormation 和 AWS 管理控制台来添加和管理对集群的访问权限。这意味着您可以使用与创建集群相同的工具来管理用户。
首先[将身份验证模式改为使用访问条目](setting-up-access-entries.md)，然后[将现有 aws-auth ConfigMap 条目迁移到访问条目](migrating-access-entries.md)。
+ **向 `aws-auth` `ConfigMap` 中添加条目** – 如果集群的平台版本早于[先决条件](access-entries.md)部分中列出的版本，则必须使用此选项。对于集群的 Kubernetes 版本，如果集群的平台版本等于或高于[先决条件](access-entries.md)部分所列的平台版本，并且您已向 `ConfigMap` 添加了条目，建议将这些条目迁移到访问条目。但是，您无法迁移 Amazon EKS 添加到 `ConfigMap` 的条目，例如与托管节点组结合使用的 IAM 角色的条目或 Fargate 配置文件。有关更多信息，请参阅 [向 IAM 用户和角色授予对 Kubernetes API 的访问权限](#grant-k8s-access)。
+ 如果必须使用 `aws-auth` `ConfigMap` 选项，则可以使用 `eksctl create iamidentitymapping` 命令向 `ConfigMap` 中添加条目。有关更多信息，请参阅 `eksctl` 文档中的[管理 IAM 用户和角色](https://eksctl.io/usage/iam-identity-mappings/)。
## 设置集群身份验证模式
每个集群都有一种*身份验证模式*。身份验证模式决定了您可以使用哪些方法来允许 IAM 主体访问集群上的 Kubernetes 对象。有三种身份验证模式。
**重要**
一旦启用了访问条目方法，就无法将其禁用。
如果在创建集群时未启用 `ConfigMap` 方法，则以后无法启用它。在引入访问条目之前创建的所有集群都启用了 `ConfigMap` 方法。
如果您在集群中使用混合节点，则必须使用 `API` 或 `API_AND_CONFIG_MAP` 集群身份验证模式。
**集群内部的 `aws-auth` `ConfigMap`**
这是 Amazon EKS 集群的原始身份验证模式。创建集群的 IAM 主体是可以使用 `kubectl` 访问集群的初始用户。初始用户必须将其他用户添加到 `aws-auth` `ConfigMap` 中的列表中，并分配影响集群内其他用户的权限。这些其它用户无法管理或移除初始用户，因为 `ConfigMap` 中没有要管理的条目。
**`ConfigMap` 和访问条目**
使用这种身份验证模式，您可以使用这两种方法向集群添加 IAM 主体。请注意，每种方法都存储单独的条目；例如，如果您从 AWS CLI 中添加访问条目，`aws-auth` `ConfigMap` 则不会更新。
**仅访问条目**
使用这种身份验证模式，您可以使用 EKS API、AWS 命令行界面、AWS SDK、AWS CloudFormation 和 AWS 管理控制台来管理 IAM 主体对集群的访问权限。
每个访问条目都有一种*类型*，您可以使用*访问范围*将主体限制在特定的命名空间和*访问策略*的组合来设置预先配置且可重复使用的权限策略。您也可以使用 STANDARD 类型和 Kubernetes RBAC 组来分配自定义权限。
| 身份验证模式 | 方法 |
| --- | --- |
| 仅 `ConfigMap` (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| EKS API 和 `ConfigMap` (`API_AND_CONFIG_MAP`) | 访问 EKS API、AWS 命令行界面、AWS SDK、AWS CloudFormation AWS 管理控制台 和 `aws-auth` `ConfigMap` 中的条目 |
| 仅 EKS API (`API`) | 访问 EKS API、AWS 命令行界面、AWS SDK、AWS CloudFormation 和 AWS 管理控制台中的条目 |
**注意**
Amazon EKS 自动模式需要使用访问条目。
# 使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限
本节旨在向您展示如何使用访问条目和策略管理 IAM 主体对 Amazon Elastic Kubernetes Service（EKS）中 Kubernetes 集群的访问权限。您将找到有关更改身份验证模式；从旧版 `aws-auth` ConfigMap 条目迁移；创建、更新和删除访问条目；将策略与条目关联；查看预定义策略权限，以及安全访问管理的关键先决条件和注意事项的详细信息。
## 概览
EKS 访问条目是向用户授予 Kubernetes API 访问权限的最佳方式。例如，您可以使用访问条目向开发人员授予使用 kubectl 的权限。从根本上讲，EKS 访问条目会将一组 Kubernetes 权限与某个 IAM 身份（例如 IAM 角色）关联起来。例如，开发人员可以担任某个 IAM 角色并使用该角色对 EKS 集群进行身份验证。
## 特征
+ **集中式身份验证和授权**：直接通过 Amazon EKS API 控制对 Kubernetes 集群的访问，无需在 AWS 和 Kubernetes API 之间切换即可获得用户权限。
+ **精细权限管理**：使用访问条目和策略为 AWS IAM 主体定义精细权限，包括修改或撤销创建者的集群管理员访问权限。
+ **IaC 工具集成**：支持 AWS CloudFormation、Terraform 和 AWS CDK 等基础设施即代码工具，以便在集群创建期间定义访问配置。
+ **错误配置恢复**：允许通过 Amazon EKS API 恢复集群访问权限，而无需直接访问 Kubernetes API。
+ **降低开销并增强安全性**：集中运营以降低开销，同时利用 AWS IAM 功能（如 CloudTrail 审计日志和多重身份验证）提升安全性。
## 如何附加权限
您可以通过两种方式将 Kubernetes 权限附加到访问条目：
+ 使用访问策略。访问策略是由 AWS 维护的预定义 Kubernetes 权限模板。有关更多信息，请参阅 [检查访问策略权限](access-policy-permissions.md)。
+ 引用 Kubernetes 组。如果您将某个 IAM 身份与某个 Kubernetes 组关联，则可以创建向该组授予权限 Kubernetes 资源。有关更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
## 注意事项
在现有集群上启用 EKS 访问条目时，请注意以下事项：
+ **旧版集群行为**：对于在引入访问条目之前创建的集群（初始平台版本早于[平台版本要求](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)中指定的版本），EKS 会自动创建一个反映先前已存在权限的访问条目。此条目包括最初创建集群的 IAM 身份以及在创建集群期间授予该身份的管理权限。
+ **处理旧版 `aws-auth` ConfigMap**：如果您的集群依赖旧版 `aws-auth` ConfigMap 进行访问管理，则启用访问条目后，仅自动创建原始集群创建者的访问条目。添加到 ConfigMap 的其他角色或权限（例如，开发人员或服务的自定义 IAM 角色）不会自动迁移。要解决此问题，请手动创建相应的访问条目。
## 开始使用
1. 确定您要使用的 IAM 身份和访问策略。
+ [检查访问策略权限](access-policy-permissions.md)
1. 在集群上启用 EKS 访问条目。确认您有受支持的平台版本。
+ [更改身份验证模式以使用访问条目](setting-up-access-entries.md)
1. 创建一个访问条目，将某个 IAM 身份与 Kubernetes 权限关联起来。
+ [创建访问条目](creating-access-entries.md)
1. 使用该 IAM 身份向集群进行身份验证。
+ [设置 AWS CLI](install-awscli.md)
+ [设置 `kubectl` 和 `eksctl`](install-kubectl.md)
# 将访问策略与访问条目关联起来
您可以为*类型*为 `STANDARD` 的*访问条目*分配一个或多个访问策略。Amazon EKS 会自动向其他类型的访问条目授予在您的集群中正常运行所需的权限。Amazon EKS 访问策略包含 Kubernetes 权限，但不包含 IAM 权限。在将访问策略关联到访问条目之前，请确保您熟悉每个访问策略中包含的 Kubernetes 权限。有关更多信息，请参阅 [检查访问策略权限](access-policy-permissions.md)。如果所有访问策略都不符合您的要求，则不要将访问策略与访问条目相关联。而是为访问条目指定一个或多个*组名称*，然后创建和管理 Kubernetes 基于角色的访问控制对象。有关更多信息，请参阅 [创建访问条目](creating-access-entries.md)。
+ 现有的访问条目。要创建该文件，请参阅 [创建访问条目](creating-access-entries.md)。
+ 具有以下权限的 AWS Identity and Access Management 角色或用户：`ListAccessEntries`、`DescribeAccessEntry`、`UpdateAccessEntry`、`ListAccessPolicies`、`AssociateAccessPolicy` 和 `DisassociateAccessPolicy`。有关更多信息，请参阅《服务授权参考》中的 [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)**。
在将访问策略与访问条目关联之前，请考虑以下要求：
+ 您可以将多个访问策略关联到每个访问条目，但只能将每个策略与一个访问条目关联一次。如果您关联多个访问策略，则访问条目的 IAM 主体拥有所有关联访问策略中包含的所有权限。
+ 您可以将访问策略的范围限定为集群上的所有资源，也可以指定一个或多个 Kubernetes 命名空间的名称。您可以为命名空间名称使用通配符。例如，如果要将访问策略的范围限定为以 `dev-` 开头的所有命名空间，则可以指定 `dev-*` 为命名空间名称。请确保您的集群上存在命名空间，并且拼写与集群上的实际命名空间名称相匹配。Amazon EKS 不会确认您的集群上命名空间的拼写或是否存在。
+ 将访问策略与访问条目关联后，您可以更改访问策略的*访问范围*。如果已将访问策略的范围限定为 Kubernetes 命名空间，则可根据需要为关联添加和移除命名空间。
+ 如果您将访问策略关联到同时指定了*组名称*的访问条目，则 IAM 主体拥有所有关联访问策略中的所有权限。该主体还拥有在指定组名称的任何 Kubernetes `Role` 和 `RoleBinding` 对象中指定的任何 Kubernetes `Role` 或 `ClusterRole` 对象中的所有权限。
+ 如果运行 `kubectl auth can-i --list` 命令，则不会看到访问策略分配的任何 Kubernetes 权限，这些权限与您在运行命令时使用的 IAM 主体的访问条目相关联。只有已经在 Kubernetes `Role` 或 `ClusterRole` 对象中授予 Kubernetes 权限，并且已经将这些权限绑定到为访问条目指定的组名称或用户名时，该命令才会显示这些权限。
+ 如果您在与集群上的 Kubernetes 对象交互时伪装成 Kubernetes 用户或组，例如使用带 `--as username ` 或 `--as-group group-name ` 的 `kubectl` 命令，则表示您强制使用 Kubernetes RBAC 授权。因此，IAM 主体没有与访问条目关联的任何访问策略所分配的权限。IAM 主体伪装的用户或组拥有的唯一 Kubernetes 权限是您在 Kubernetes `Role` 或 `ClusterRole` 对象中向其授予的 Kubernetes 权限，这些权限已绑定到组名称或用户名。要使 IAM 主体拥有相关访问策略中的权限，请不要伪装成 Kubernetes 用户或组。IAM 主体仍将拥有您在 Kubernetes `Role` 或 `ClusterRole` 对象中向其授予的任何权限，这些权限已绑定到为访问条目指定的组名称或用户名。有关更多信息，请参阅 Kubernetes 文档中的[用户伪装](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)。
您可以使用 AWS 管理控制台 或 AWS CLI 将访问策略与访问条目相关联。
## AWS 管理控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择具有要与访问策略关联的访问条目的集群的名称。
1. 选择**访问**选项卡。
1. 如果访问条目的类型为**标准**，则可以关联或取消关联 Amazon EKS **访问策略**。如果您的访问条目类型不是**标准**，则此选项不可用。
1. 选择**关联访问策略**。
1. 对于**策略名称**，选择具有您希望 IAM 主体拥有的权限的策略。要查看每个策略包含的权限，请参阅 [检查访问策略权限](access-policy-permissions.md)。
1. 对于**访问范围**，选择一个访问范围。如果选择**集群**，则访问策略中的权限将授予 IAM 主体以访问所有 Kubernetes 命名空间中的资源。如果选择 **Kubernetes 命名空间**，则可选择**添加新命名空间**。可在显示的**命名空间**字段中，输入集群上 Kubernetes 命名空间的名称。如果您希望 IAM 主体拥有跨多个命名空间的权限，则可以输入多个命名空间。
1. 选择**添加访问策略**。
## AWS CLI
1. 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
1. 查看可用的访问策略。
```
aws eks list-access-policies --output table
```
示例输出如下。
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
要查看每个策略包含的权限，请参阅 [检查访问策略权限](access-policy-permissions.md)。
1. 查看您现有的访问条目。将 *my-cluster* 替换为您的集群的名称。
```
aws eks list-access-entries --cluster-name my-cluster
```
示例输出如下。
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. 将访问策略与访问条目关联。以下示例将 `AmazonEKSViewPolicy` 访问策略与访问条目关联。每当 *my-role* IAM 角色尝试访问集群上的 Kubernetes 对象时，Amazon EKS 都将授权该角色使用策略中的权限仅访问 *my-namespace1* 和 *my-namespace2* Kubernetes 命名空间中的 Kubernetes 对象。将 *my-cluster* 替换为集群的名称，将 *111122223333* 替换为 AWS 账户 ID，将 *my-role* 替换为您希望 Amazon EKS 授权其访问 Kubernetes 集群对象的 IAM 角色的名称。
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
如果您希望 IAM 主体拥有整个集群的权限，请将 `type=namespace,namespaces=my-namespace1,my-namespace2 ` 替换为 `type=cluster`。如果要将多个访问策略关联到访问条目，请多次运行该命令，每个访问条目都有唯一的访问策略。每个关联的访问策略都有自己的范围。
**注意**
如果以后要更改关联访问策略的范围，请使用新的范围再次运行前面的命令。例如，如果您想移除 *my-namespace2*，则只能使用 `type=namespace,namespaces=my-namespace1 ` 再次运行该命令。如果要将范围从 `namespace` 更改为 `cluster`，则可以使用 `type=cluster` 再次运行该命令并移除 `type=namespace,namespaces=my-namespace1,my-namespace2 `。
1. 确定哪些访问策略与访问条目关联。
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
示例输出如下。
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
在前面的示例中，此访问条目的 IAM 主体拥有集群上所有命名空间的查看权限，以及对两个 Kubernetes 命名空间的管理员权限。
1. 取消访问策略与访问条目的关联。在此示例中，`AmazonEKSAdminPolicy` 策略与访问条目取消关联。但是，IAM 主体保留 `AmazonEKSViewPolicy` 访问策略中对 *my-namespace1* 和 *my-namespace2* 命名空间中对象的权限，因为该访问策略并未与访问条目取消关联。
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
要列出可用的访问策略，请参阅[检查访问策略权限](access-policy-permissions.md)。
# 将现有 `aws-auth ConfigMap` 条目迁移至访问条目
如果您已向集群的 `aws-auth` `ConfigMap` 中添加了条目，我们建议您为 `aws-auth` `ConfigMap` 中的现有条目创建访问条目。创建访问条目后，您可以从 `ConfigMap` 中移除这些条目。不能将[访问策略](access-policies.md)关联到 `aws-auth` `ConfigMap` 中的条目。如果您想将访问策略与您的 IAM 主体相关联，请创建访问条目。
**重要**
当集群处于 `API_AND_CONFIGMAP` 身份验证模式并且在 `aws-auth` `ConfigMap` 和访问条目中都存在同一 IAM 角色的映射时，该角色将使用访问条目的映射进行身份验证。对于同一 IAM 主体，访问条目优先于 `ConfigMap` 条目。
在移除 Amazon EKS 为[托管节点组](managed-node-groups.md)创建的现有 `aws-auth` `ConfigMap` 条目或集群的 [Fargate 配置文件](fargate-profile.md)之前，请仔细检查您的 Amazon EKS 集群中是否存在这些特定资源的正确访问条目。如果您移除 Amazon EKS 在 `ConfigMap` 中创建的条目而没有等效的访问条目，您的集群将无法正常运行。
## 先决条件
+ 熟悉访问条目和访问策略。有关更多信息，请参阅[使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)和[将访问策略与访问条目关联起来](access-policies.md)。
+ 一个平台版本等于或高于[使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)主题中“先决条件”部分所列版本的现有版本。
+ 您的设备或 AWS CloudShell 上安装 `0.215.0` 版或更高版本的 `eksctl` 命令行工具。要安装或更新 `eksctl`，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
+ 用于修改 `kube-system` 命名空间中的 `aws-auth` `ConfigMap` 的 Kubernetes 权限。
+ 具有以下权限的 AWS Identity and Access Management 角色或用户：`CreateAccessEntry` 和 `ListAccessEntries`。有关更多信息，请参阅《服务授权参考》中的 [Amazon Elastic Kubernetes Service 定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。
## `eksctl`
1. 查看您的 `aws-auth ConfigMap` 中的现有条目。将 *my-cluster* 替换为您的集群的名称。
```
eksctl get iamidentitymapping --cluster my-cluster
```
示例输出如下。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:user/my-user my-user
arn:aws:iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws:iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. 为您创建的并在上一个输出中返回的任何 `ConfigMap` 条目[创建访问条目](creating-access-entries.md)。创建访问条目时，请确保为输出中返回的 `ARN`、`USERNAME`、`GROUPS` 和 `ACCOUNT` 指定相同的值。在此示例输出中，您将为除最后两个条目外的其他所有条目创建访问条目，因为最后两个条目是由 Amazon EKS 为 Fargate 配置文件和托管节点组创建的。
1. 从 `ConfigMap` 中删除您创建的任何访问条目对应的条目。如果您不从 `ConfigMap` 中删除条目，则 IAM 主体 ARN 的访问条目设置将覆盖 `ConfigMap` 条目。将 *111122223333* 替换为您的 AWS 账户 ID，将 *EKS-my-cluster-my-namespace-Viewers* 替换为您的 `ConfigMap` 中相应条目的角色名称。如果您要移除的条目是用于 IAM 用户而不是 IAM 角色的，请将 `role` 替换为 `user`，将 *EKS-my-cluster-my-namespace-Viewers* 替换为用户名。
```
eksctl delete iamidentitymapping --arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# 检查访问策略权限
访问策略包括包含 Kubernetes `verbs`（权限）和 `resources` 的 `rules`。访问策略不包括 IAM 权限或资源。访问策略与 Kubernetes `Role` 和 `ClusterRole` 对象类似，仅包括 `allow` `rules`。您无法修改访问策略的内容。您无法创建自己的访问策略。如果访问策略中的权限不符合需求，请创建 Kubernetes RBAC 对象并为访问条目指定*组名称*。有关更多信息，请参阅 [创建访问条目](creating-access-entries.md)。访问策略中包含的权限与 Kubernetes 面向用户的集群角色中的权限类似。有关更多信息，请参阅 Kubernetes 文档中的[面向用户的角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)。
## 列出所有策略
使用此页面上列出的任何一个访问策略，或者使用 AWS CLI 检索所有可用访问策略的列表：
```
aws eks list-access-policies
```
预期输出应如下所示（为简洁起见已缩写）：
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## AmazonEKSAdminPolicy
此访问策略包括授予 IAM 主体对资源的大部分权限的权限。当与访问条目关联时，其访问范围通常是一个或多个 Kubernetes 命名空间。如果您希望 IAM 主体拥有集群上所有资源的管理员访问权限，请改为将 [AmazonEKSClusterAdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) 访问策略关联到您的访问条目。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## AmazonEKSClusterAdminPolicy
此访问策略包括授予 IAM 主体对集群的管理员访问权限的权限。当与访问条目关联时，其访问范围通常是集群，而不是 Kubernetes 命名空间。如果您希望 IAM 主体的管理范围更有限，请考虑将 [AmazonEKSAdminPolicy](#access-policy-permissions-amazoneksadminpolicy) 访问策略与您的访问条目相关联。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Kubernetes API 组 | Kubernetes 非资源 URL | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## AmazonEKSAdminViewPolicy
此访问策略包括授予 IAM 主体列出/查看集群中所有资源的权限。请注意，此项包括 [Kubernetes 密钥](https://kubernetes.io/docs/concepts/configuration/secret/)。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## AmazonEKSEditPolicy
此访问策略包括允许 IAM 主体编辑大多数 Kubernetes 资源的权限。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## AmazonEKSViewPolicy
此访问策略包括允许 IAM 主体查看大多数 Kubernetes 资源的权限。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`、`events`、`limitranges`、`namespaces/status`、`pods/log`、`pods/status`、`replicationcontrollers/status`、`resourcequotas`、r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## AmazonEKSSecretReaderPolicy
此访问策略包括允许 IAM 主体读取 [Kubernetes 密钥](https://kubernetes.io/docs/concepts/configuration/secret/)的权限。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## AmazonEKSAutoNodePolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
此策略包含允许 Amazon EKS 组件完成以下任务的下列权限：
+ `kube-proxy` – 监控网络端点和服务，并管理相关事件。这将启用集群范围的网络代理功能。
+ `ipamd` – 管理 AWS VPC 联网资源和容器网络接口（CNI）。这将允许 IP 地址管理进程守护程序处理容器组联网。
+ `coredns` – 访问端点和服务等服务发现资源。这将在集群内启用 DNS 解析。
+ `ebs-csi-driver` – 使用 Amazon EBS 卷的存储相关资源。这将允许动态预置和挂载持久性卷。
+ `neuron` – 监控 AWS Neuron设备的节点和容器组。这将有助于 AWS Inferentia 和 Trainium 加速器的管理。
+ `node-monitoring-agent` – 访问节点诊断和事件。这将启用集群运行状况监控和诊断收集。
每个组件都使用一个专用的服务账户，并且仅限于其特定功能所需的权限。
如果您在 NodeClass 中手动指定节点 IAM 角色，则需要创建一个访问条目，将新的节点 IAM 角色与该访问策略关联。
## AmazonEKSBlockStoragePolicy
**注意**
此策略仅适用于 AWS 服务相关角色，不能与客户自行管理的角色一起使用。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
此策略包含允许 Amazon EKS 管理用于存储操作的领导副本选择和协调资源的权限：
+ `coordination.k8s.io` – 创建和管理领导副本选择的租赁对象。这将使 EKS 存储组件能够通过领导副本选择机制来协调其在集群中的活动。
此策略的范围限于 EKS 存储组件使用的特定租赁资源，以防止对集群中其他协调资源的访问权限冲突。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持块存储功能的正常运行。
## AmazonEKSLoadBalancingPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
此策略包含允许 Amazon EKS 管理用于负载均衡的领导副本选择的权限：
+ `coordination.k8s.io` – 创建和管理领导副本选择的租赁对象。这让 EKS 负载均衡组件能够通过领导副本选择来协调多个副本之间的活动。
此策略的范围特别限于负载均衡租赁资源，以确保适当的协调，同时防止访问集群中的其他租赁资源。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持联网功能的正常运行。
## AmazonEKSNetworkingPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
此策略包含允许 Amazon EKS 管理用于联网的领导副本选择的权限：
+ `coordination.k8s.io` – 创建和管理领导副本选择的租赁对象。这让 EKS 网络组件能够通过领导副本选择来协调 IP 地址分配活动。
此策略的范围特别限于联网租赁资源，以确保适当的协调，同时防止访问集群中的其他租赁资源。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持联网功能的正常运行。
## AmazonEKSComputePolicy
**注意**
此策略仅适用于 AWS 服务相关角色，不能与客户自行管理的角色一起使用。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
此策略包含允许 Amazon EKS 管理用于计算操作的领导副本选择资源的权限：
+ `coordination.k8s.io` – 创建和管理领导副本选择的租赁对象。这让 EKS 计算组件能够通过领导副本选择来协调节点扩缩活动。
此策略的范围特别限于计算管理租赁资源，同时允许对集群中所有租赁资源的基本读取访问权限（`get`、`watch`）。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持联网功能的正常运行。
## AmazonEKSBlockStorageClusterPolicy
**注意**
此策略仅适用于 AWS 服务相关角色，不能与客户自行管理的角色一起使用。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
此策略将授予 Amazon EKS 自动模式块存储功能的必要权限，有助于对 Amazon EKS 集群中块存储资源的高效管理。 策略包含以下权限：
CSI 驱动程序管理：
+ 创建、读取、更新和删除 CSI 驱动程序，尤其是针对块存储。
卷管理：
+ 列出、观察、创建、更新、修补和删除持久性卷。
+ 列出、观察和更新持久性卷声明。
+ 修补持久性卷声明状态。
节点和容器组交互：
+ 读取节点和容器组信息。
+ 管理与存储操作相关的事件。
存储类和属性：
+ 读取存储类和 CSI 节点。
+ 读取卷属性类。
卷挂载：
+ 列出、观察和修改卷挂载及其状态。
快照操作：
+ 管理卷快照、快照内容和快照类别。
+ 处理卷组快照和相关资源的操作。
此策略适用于在自动模式下运行的 Amazon EKS 集群，旨在支持全面的块存储管理。此策略将各种操作的权限进行组合，包括块存储卷的预置、挂载、大小调整和快照创建等。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持块存储功能的正常运行。
## AmazonEKSComputeClusterPolicy
**注意**
此策略仅适用于 AWS 服务相关角色，不能与客户自行管理的角色一起使用。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
此策略将授予 Amazon EKS 自动模式计算管理功能的必要权限，有助于在 Amazon EKS 集群中实现高效的计算资源编排和扩缩。 策略包含以下权限：
节点管理：
+ 创建、读取、更新、删除和管理节点池和节点声明的状态。
+ 管理节点类，包括创建、修改和删除。
调度和资源管理：
+ 对容器组、节点、持久性卷、持久性卷声明、复制控制器和命名空间的读取权限。
+ 对存储类、CSI 节点和卷挂载的读取权限。
+ 列出和观察部署、进程守护程序集、副本集和有状态集。
+ 读取容器组中断预算。
事件处理：
+ 创建、读取和管理集群事件。
节点取消预置和容器组弹出：
+ 更新、修补和删除节点。
+ 创建容器组弹出并在必要时删除容器组。
自定义资源定义（CRD）管理：
+ 创建新建 CRD。
+ 管理与节点管理相关的特定 CRD（节点类、节点池、节点声明和节点诊断）。
此策略适用于在自动模式下运行的 Amazon EKS 集群，旨在支持全面的计算管理。此策略将各种操作的权限进行组合，包括节点预置、调度、扩缩和资源优化。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持计算管理功能的正常运行。
## AmazonEKSLoadBalancingClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
此策略将授予 Amazon EKS 自动模式负载均衡功能的必要权限，有助于对 Amazon EKS 集群中负载均衡资源的高效管理和配置。 策略包含以下权限：
事件和资源管理：
+ 创建和修补事件。
+ 对容器组、节点、端点和命名空间的读取权限。
+ 更新容器组状态。
服务和 Ingress 管理：
+ 全面管理服务及其状态。
+ 全面控制 Ingress 及其状态。
+ 对端点切片和 Ingress 类的读取权限。
目标组绑定：
+ 创建和修改目标组绑定及其状态。
+ 对 Ingress 类参数的读取权限。
自定义资源定义（CRD）管理：
+ 创建并读取所有 CRD。
+ 对 targetgroupbindings.eks.amazonaws.com 和 ingressclassparams.eks.amazonaws.com CRD 的具体管理。
Webhook 配置：
+ 创建和读取变异和验证性 Webhook 配置。
+ 管理 eks-load-balancing-webhook 配置。
此策略适用于在自动模式下运行的 Amazon EKS 集群，旨在支持全面的负载均衡管理。此策略将各种操作的权限进行组合，包括服务公开、Ingress 路由以及与 AWS 负载均衡服务的集成。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持负载均衡功能的正常运行。
## AmazonEKSNetworkingClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
AmazonEKSNetworkingClusterPolicy
此策略将授予 Amazon EKS 自动模式联网功能的必要权限，有助于对 Amazon EKS 集群中联网资源的高效管理和配置。 策略包含以下权限：
节点和容器组管理：
+ 对节点类及其状态的读取权限。
+ 对节点声明及其状态的读取权限。
+ 对容器组的读取权限。
CNI 节点管理：
+ CNINodes 及其状态的权限，包括创建、读取、更新、删除和修补。
自定义资源定义（CRD）管理：
+ 创建并读取所有 CRD。
+ cninodes.eks.amazonaws.com CRD 的具体管理（更新、修补、删除）。
事件管理：
+ 创建和修补事件。
此策略适用于在自动模式下运行的 Amazon EKS 集群，旨在支持全面的联网管理。此策略将各种操作的权限进行组合，包括节点联网配置、CNI（容器网络接口）管理和相关的自定义资源处理。
此策略允许联网组件与节点相关资源进行交互，管理特定于 CNI 的节点配置，以及处理对集群中联网操作至关重要的自定义资源。
启用自动模式后，Amazon EKS 会自动使用此访问策略为集群 IAM 角色创建访问条目，从而确保具备必要的权限来支持联网功能的正常运行。
## AmazonEKSHybridPolicy
**注意**
此策略仅适用于 AWS 服务相关角色，不能与客户自行管理的角色一起使用。
此访问策略包含授予 EKS 访问集群节点的权限。当与访问条目关联时，其访问范围通常是集群，而不是 Kubernetes 命名空间。此策略由 Amazon EKS 混合节点功能使用。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Kubernetes API 组 | Kubernetes 非资源 URL | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## AmazonEKSClusterInsightsPolicy
**注意**
此策略仅适用于 AWS 服务相关角色，不能与客户自行管理的角色一起使用。
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
此策略授予 Amazon EKS 集群见解功能的只读权限。 策略包含以下权限：
节点访问权限：– 列出并查看集群节点 – 读取节点状态信息
DaemonSet 访问权限：– 读取 kube-proxy 配置的访问权限
此策略由 EKS 集群见解服务自动管理。有关更多信息，请参阅 [利用集群见解为 Kubernetes 版本升级做好准备并对错误配置进行问题排查](cluster-insights.md)。
## AWSBackupFullAccessPolicyForBackup
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
此策略授予 AWS Backup 管理和创建 EKS 集群备份所需的权限。该策略包含以下权限：
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
此策略授予 AWS Backup 管理和还原 EKS 集群备份所需的权限。该策略包含以下权限：
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## AmazonEKSACKPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
此策略授予 AWS Controllers for Kubernetes（ACK）功能所需的权限，以管理来自 Kubernetes 的 AWS 资源。 策略包含以下权限：
ACK 自定义资源管理：
+ 对 50 多项 AWS 服务的所有 ACK 服务自定义资源的完全访问权限，包括 S3、RDS、DynamoDB、Lambda、EC2 等。
+ 创建、读取、更新和删除 ACK 自定义资源定义。
命名空间访问权限：
+ 读取命名空间，用于整理资源。
主节点选举：
+ 创建和读取协调租约，用于主节点选举。
+ 更新和删除特定的 ACK 服务控制器租约。
事件管理：
+ 创建和修补事件，用于 ACK 操作。
此策略旨在通过 Kubernetes API 支持全面的 AWS 资源管理。创建 ACK 功能时，Amazon EKS 会自动使用此访问策略为所提供的功能 IAM 角色创建访问条目。
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`（仅限特定的 ACK 服务控制器租约） | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## AmazonEKSArgoCDClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
此策略授予 Argo CD 功能发现资源和管理集群范围对象所需的集群级权限。 策略包含以下权限：
命名空间管理：
+ 创建、读取、更新和删除命名空间，用于管理应用程序命名空间。
自定义资源定义管理：
+ 管理特定于 Argo CD 的 CRD（Applications、AppProjects、ApplicationSets）。
API 发现：
+ 读取 Kubernetes API 端点，用于资源发现。
此策略旨在支持集群级 Argo CD 操作，包括管理命名空间和安装 CRD。创建 Argo CD 功能时，Amazon EKS 会自动使用此访问策略为所提供的功能 IAM 角色创建访问条目。
| Kubernetes API 组 | Kubernetes 非资源 URL | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions`（仅限 Argo CD CRD） | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## AmazonEKSArgoCDPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
此策略授予 Argo CD 功能部署和管理应用程序所需的命名空间级权限。 策略包含以下权限：
密钥管理：
+ 对密钥的完全访问权限，用于 Git 凭证和集群密钥。
ConfigMap 访问权限：
+ 读取 ConfigMap，以便在客户尝试使用不支持的 Argo CD ConfigMap 时发送警告。
事件管理：
+ 读取和创建事件，用于应用程序生命周期跟踪。
Argo CD 资源管理：
+ 对 Applications、ApplicationSets 和 AppProjects 的完全访问权限。
+ 管理 Argo CD 资源的终结器和状态。
此策略旨在支持命名空间级 Argo CD 操作，包括部署和管理应用程序。创建 Argo CD 功能时，Amazon EKS 会自动使用此访问策略为所提供的功能 IAM 角色创建访问条目，作用范围为 Argo CD 命名空间。
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## AmazonEKSKROPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
此策略授予 kro（Kube Resource Orchestrator）功能创建和管理自定义 Kubernetes API 所需的权限。 策略包含以下权限：
kro 资源管理：
+ 对所有 kro 资源的完全访问权限，包括 ResourceGraphDefinitions 和自定义资源实例。
自定义资源定义管理：
+ 创建、读取、更新和删除由 ResourceGraphDefinitions 定义的自定义 API 的 CRD。
主节点选举：
+ 创建和读取协调租约，用于主节点选举。
+ 更新和删除 kro 控制器租约。
事件管理：
+ 创建和修补事件，用于 kro 操作。
此策略旨在通过 kro 支持全面的资源组合和自定义 API 管理。创建 kro 功能时，Amazon EKS 会自动使用此访问策略为所提供的功能 IAM 角色创建访问条目。
| Kubernetes API 组 | Kubernetes 资源 | Kubernetes 动词（权限） |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`（仅限 kro 控制器租约） | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## 访问策略更新
查看有关自引入访问策略以来更新的详细信息。要获得有关此页面更改的自动提示，请订阅 [文档历史记录](doc-history.md) 中的 RSS 源。
| 更改 | 描述 | 日期 |
| --- | --- | --- |
| 添加适用于 EKS 功能的策略 | 发布用于管理 EKS 功能的 `AmazonEKSACKPolicy`、`AmazonEKSArgoCDClusterPolicy`、`AmazonEKSArgoCDPolicy` 和 `AmazonEKSKROPolicy` | 2025 年 11 月 22 日 |
| 添加 `AmazonEKSSecretReaderPolicy` | 添加用于密钥只读访问的新策略 | 2025 年 11 月 6 日 |
| 为 EKS 集群见解添加策略 | 发布 `AmazonEKSClusterInsightsPolicy` | 2024 年 12 月 2 日 |
| 增加了适用于 Amazon EKS 混合节点功能的策略 | 发布 `AmazonEKSHybridPolicy` | 2024 年 12 月 2 日 |
| 增加了适用于 Amazon EKS 自动模式的策略 | 这些访问策略授予集群 IAM 角色和节点 IAM 角色调用 Kubernetes API 的权限。AWS 使用这些策略来自动执行存储、计算和联网资源的例行任务。 | 2024 年 12 月 2 日 |
| 添加 `AmazonEKSAdminViewPolicy` | 添加新策略以扩展查看权限，包括 Secrets 等资源。 | 2024 年 4 月 23 日 |
| 引入访问策略。 | Amazon EKS 引入访问策略。 | 2023 年 5 月 29 日 |
# 更改身份验证模式以使用访问条目
要开始使用访问条目，必须将集群的身份验证模式更改为 `API_AND_CONFIG_MAP` 或 `API` 模式。这为访问条目添加了 API。
## AWS 控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择要在其中创建访问条目的集群的名称。
1. 选择**访问**选项卡。
1. **身份验证模式**会显示集群的当前身份验证模式。如果模式显示 EKS API，您已经可以添加访问条目了，可以跳过其余的步骤。
1. 选择**管理访问**。
1. 对于**集群身份验证模式**，请使用 EKS API 选择一种模式。请注意，您不能将身份验证模式更改回移除 EKS API 和访问条目的模式。
1. 选择**保存更改**。Amazon EKS 开始更新集群，集群的状态更改为“更新中”，更改记录在**更新历史记录**选项卡中。
1. 等待集群的状态恢复为“活动”。当集群处于“活动”状态时，您可以按照[创建访问条目](creating-access-entries.md)中的步骤为 IAM 主体添加对集群的访问权限。
## AWS CLI
1. 按照《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)部分的描述安装 AWS CLI。
1. 运行以下命令。将 *my-cluster* 替换为您的集群的名称。如果要永久禁用 `ConfigMap` 方法，请将 `API_AND_CONFIG_MAP` 替换为 `API`。
Amazon EKS 开始更新集群，集群的状态更改为“更新中”，更改记录在 **aws eks list-updates** 中。
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. 等待集群的状态恢复为“活动”。当集群处于“活动”状态时，您可以按照[创建访问条目](creating-access-entries.md)中的步骤为 IAM 主体添加对集群的访问权限。
## 所需平台版本
要使用*访问条目*，集群的平台版本必须与下表中所列的版本相同或更高，或者为高于下表中所列版本的 Kubernetes 版本。如果您的 Kubernetes 版本未列出，则所有平台版本都支持访问条目。
| Kubernetes 版本 | 平台版本 |
| --- | --- |
| 未列出 | 全部受支持 |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
有关更多信息，请参阅 [platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)。
# 创建访问条目
在创建访问条目之前，请考虑以下事项：
+ 身份验证模式设置正确。请参阅[更改身份验证模式以使用访问条目](setting-up-access-entries.md)。
+ *访问条目*包含一个（且仅限一个）现有 IAM 主体的 Amazon 资源名称（ARN）。一个 IAM 主体不能包含在多个访问条目中。您指定的 ARN 的其他注意事项：
+ IAM 最佳实践建议使用具有短期凭证的 IAM *角色*而不是具有长期凭证的 IAM *用户*访问您的集群。有关更多信息，请参阅《IAM 用户指南》中的[要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)**。
+ 如果 ARN 适用于 IAM 角色，则*可以*包含路径。`aws-auth` `ConfigMap` 条目中的 ARN *不能*包含路径。例如，您的 ARN 可以是 ` arn:aws:iam::<111122223333>:role/` 或 ` arn:aws:iam::<111122223333>:role/`。
+ 如果访问条目的类型不是 `STANDARD`（请参阅下文关于类型的注意事项），则 ARN 必须位于与您的集群相同的 AWS 账户。如果类型为 `STANDARD`，则 ARN 可以位于与您的集群所在的账户相同或不同的 AWS 账户。
+ 在创建访问条目后，您将无法更改 IAM 主体。
+ 如果您删除了具有此 ARN 的 IAM 主体，则访问条目不会自动删除。对于已删除的 IAM 主体，我们建议您删除具有 ARN 的访问条目。如果您不删除访问条目并重新创建 IAM 主体，即使该访问条目具有相同的 ARN，也将无法运行。这是因为尽管重新创建的 IAM 主体的 ARN 相同，但对于重新创建的 IAM 主体，`roleID` 或 `userID`（您可以用 `aws sts get-caller-identity` AWS CLI 命令查看）与原始 IAM 主体不同。即使您看不到 IAM 主体的 `roleID` 或 `userID` 访问条目，Amazon EKS 也会将其与访问条目一起存储。
+ 每个访问条目都有一种*类型*。访问条目的类型取决于与其关联的资源类型，并且不定义权限。如果不指定类型，Amazon EKS 会自动将类型设置为 `STANDARD`
+ `EC2_LINUX`：适用于与 Linux 或 Bottlerocket 自主管理型节点一起使用的 IAM 角色
+ `EC2_WINDOWS`：适用于与 Windows 自主管理型节点一起使用的 IAM 角色
+ `FARGATE_LINUX`：适用于与 AWS Fargate（Fargate）一起使用的 IAM 角色
+ `HYBRID_LINUX`：适用于与混合节点一起使用的 IAM 角色
+ `STANDARD`：若未指定，则采用默认类型
+ `EC2`：适用于 EKS 自动模式自定义节点类。有关更多信息，请参阅 [创建节点类访问条目](create-node-class.md#auto-node-access-entry)。
+ 在创建访问条目后，您将无法更改类型。
+ 无需为用于托管式节点组或 Fargate 配置文件的 IAM 角色创建访问条目。EKS 将创建访问条目（如果启用），或者更新身份验证配置映射（如果访问条目不可用）
+ 如果访问条目的类型为 `STANDARD`，则可以为该访问条目指定*用户名*。如果您没有为用户名指定值，Amazon EKS 会根据访问条目的类型以及您指定的 IAM 主体是 IAM 角色还是 IAM 用户，为您设置以下值之一。除非您出于特定原因要指定自己的用户名，否则我们建议您不要指定用户名，而是让 Amazon EKS 为您自动生成用户名。如果您指定自己的用户名：
+ 不能以 `system:`、`eks:`、`aws:`、`amazon:` 或 `iam:` 开头。
+ 如果该用户名用于 IAM 角色，我们建议您在用户名的末尾添加 `{{SessionName}}` 或 `{{SessionNameRaw}}`。如果您在用户名中添加 `{{SessionName}}` 或 `{{SessionNameRaw}}`，则该用户名必须在 \$1\$1SessionName\$1\$1 *之前*加一个冒号。如果担任此角色，则担任此角色时指定的 AWS STS 会话名称将自动传递到集群，并显示在 CloudTrail 日志中。例如，您不能将用户名设置为 `john{{SessionName}}`。用户名必须是 `:john{{SessionName}}` 或 `jo:hn{{SessionName}}`。冒号只能在 `{{SessionName}}` 前面。下表中由 Amazon EKS 生成的用户名包含一个 ARN。由于 ARN 包含冒号，因此符合此要求。如果用户名中未包含 `{{SessionName}}`，则不需要使用冒号。请注意，会话名称 `{{SessionName}}` 中的特殊字符“@”已替换为“-”。`{{SessionNameRaw}}` 保留会话名称中的所有特殊字符。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/creating-access-entries.html)
创建访问条目后，您可以更改用户名。
+ 如果访问条目的类型为 `STANDARD`，并且您想使用 Kubernetes RBAC 授权，则可以在访问条目中添加一个或多个*组名称*。创建访问条目后，您可以添加和移除组名。要让 IAM 主体能够访问集群上的 Kubernetes 对象，您必须创建和管理 Kubernetes 基于角色的授权（RBAC）对象。在集群上创建 Kubernetes `RoleBinding` 或 `ClusterRoleBinding` 对象，将组名称指定为 `kind: Group` 的 `subject`。Kubernetes 授权 IAM 主体访问您已在 Kubernetes `Role` 或 `ClusterRole` 对象中指定的任何集群对象（您也在绑定的 `roleRef` 中指定了这些对象）。如果指定组名称，建议熟悉 Kubernetes 基于角色的授权（RBAC）对象。有关更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
**重要**
Amazon EKS 不会确认您集群上存在的任何 Kubernetes RBAC 对象是否包含您指定的任何组名称。例如，假设您为某个当前不存在的组创建访问条目，EKS 将会创建该组而不是返回错误。
除了 Kubernetes 授权 IAM 主体访问集群上的 Kubernetes 对象之外，您还可以将 Amazon EKS *访问策略*关联到访问条目。Amazon EKS 授权 IAM 主体使用访问策略中的权限访问您集群上的 Kubernetes 对象。您可以将访问策略的权限范围限定到自己指定的 Kubernetes 命名空间。使用访问策略不需要您管理 Kubernetes RBAC 对象。有关更多信息，请参阅 [将访问策略与访问条目关联起来](access-policies.md)。
+ 如果您创建类型为 `EC2_LINUX` 或 `EC2_Windows` 的访问条目，则创建访问条目的 IAM 主体必须拥有 `iam:PassRole` 权限。有关更多信息，请参阅 *IAM 用户指南*中的[向用户授予将角色传递给 AWS 服务的权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)。
+ 与标准 [IAM 行为](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)类似，访问条目创建和更新最终是一致的，并且在初始 API 调用成功返回后可能需要几秒钟才能生效。您在设计应用程序时，必须考虑到这些可能的延迟。在应用程序的关键、高可用性代码路径中，我们不建议创建或更新访问条目。而应在不常运行的、单独的初始化或设置例程中进行 更改。另外，在生产工作流程依赖这些更改之前，请务必验证更改已传播。
+ 访问条目不支持[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)。如果主体 ARN 是服务相关角色，则无法创建访问条目。您可以通过服务相关角色的 ARN（格式为 ` arn:aws:iam::*:role/aws-service-role/*`）来识别它们。
您可以使用 AWS 管理控制台或 AWS CLI 创建访问条目。
## AWS 管理控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择要在其中创建访问条目的集群的名称。
1. 选择**访问**选项卡。
1. 选择**创建访问条目**。
1. 对于 **IAM 主体**，请选择现有的 IAM 角色或用户。IAM 最佳实践建议使用具有短期凭证的 IAM *角色*而不是具有长期凭证的 IAM *用户*访问您的集群。有关更多信息，请参阅《IAM 用户指南》中的[要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)**。
1. 对于**类型**，如果访问条目是用于自行管理的 Amazon EC2 节点的节点角色，请选择 **EC2 Linux** 或 **EC2 Windows**。否则，请接受默认值（**标准**）。
1. 如果您选择的**类型**是**标准**，并且想要指定**用户名**，请输入用户名。
1. 如果您选择的**类型**是**标准**，并且您想对 IAM 主体使用 Kubernetes RBAC 授权，请为**组**指定一个或多个名称。如果您未指定任何组名并想使用 Amazon EKS 授权，则可以在后续步骤中或创建访问条目之后关联访问策略。
1. （可选）对于**标签**，为访问条目分配标签。例如，为了更轻松地查找所有具有相同标签的资源。
1. 选择**下一步**。
1. 在**添加访问策略**页面上，如果您选择的类型是**标准**，并且希望 Amazon EKS 授权 IAM 主体拥有对集群上 Kubernetes 对象的权限，请完成以下步骤。否则，请选择**下一步**。
1. 对于**策略名称**，选择访问策略。您无法查看访问策略的权限，但这些策略包含的权限与 Kubernetes 面向用户的 `ClusterRole` 对象中的权限类似。有关更多信息，请参阅 Kubernetes 文档中的[面向用户的角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)。
1. 请选择以下选项之一：
+ **集群** – 如果您希望 Amazon EKS 授权 IAM 主体拥有集群上所有 Kubernetes 对象的访问策略的权限，请选择此选项。
+ **Kubernetes 命名空间** – 如果您希望 Amazon EKS 授权 IAM 主体拥有集群上特定 Kubernetes 命名空间内所有 Kubernetes 对象的访问策略权限，请选择此选项。对于**命名空间**，输入集群上 Kubernetes 命名空间的名称。如果要添加其他命名空间，请选择**添加新命名空间**并输入命名空间名称。
1. 如果要添加其他策略，请选择**添加策略**。您可以对每个策略设定不同的范围，但每个策略只能添加一次。
1. 选择**下一步**。
1. 查看访问条目的配置。如果有任何内容看起来不正确，请选择**上一步**以返回步骤并更正错误。如果配置正确，请选择**创建**。
## AWS CLI
1. 按照《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)中所述安装 AWS CLI。
1. 创建访问条目 您可以使用以下任意示例来创建访问条目：
+ 为自行管理的 Amazon EC2 Linux 节点组创建访问条目。请将 *my-cluster* 替换为您的集群名称，将 *111122223333* 替换为您的 AWS 账户 ID，将 *EKS-my-cluster-self-managed-ng-1* 替换为您的[节点 IAM 角色](create-node-role.md)的名称。如果节点组是 Windows 节点组，则将 *EC2\$1LINUX* 替换为 `EC2_Windows`。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
当您指定除 `STANDARD` 之外的类型时，不能使用 `--kubernetes-groups` 选项。您无法将访问策略与该访问条目相关联，因为其类型的值不是 `STANDARD`。
+ 创建一个允许 IAM 角色的访问条目，该角色不用于 Amazon EC2 自主管理型节点组，您想要 Kubernetes 通过该角色授权访问您的集群。将 *my-cluster* 替换为您的集群的名称，将 *111122223333* 替换为您的 AWS 账户 ID，将 *my-role* 替换为您的 IAM 角色的名称。将 *Viewers* 替换为您在集群上的 Kubernetes `RoleBinding` 或 `ClusterRoleBinding` 对象中指定的组的名称。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ 创建允许 IAM 用户对集群进行身份验证的访问条目。之所以提供此示例，是因为尽管 IAM 最佳实践建议使用具有短期凭证的 IAM *角色*而不是具有长期凭证的 IAM *用户*访问集群，但这仍是可行的。有关更多信息，请参阅《IAM 用户指南》中的[要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)**。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
如果您希望此用户对您的集群拥有的访问权限超过 Kubernetes API 发现角色中的权限，则需要将访问策略与访问条目相关联，因为未使用 `--kubernetes-groups` 选项。有关更多信息，请参阅[将访问策略与访问条目关联起来](access-policies.md)，以及 Kubernetes 文档中的 [API 发现角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles)。
# 更新访问条目
您可以使用 AWS 管理控制台 或 AWS CLI 更新访问条目。
## AWS 管理控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择要在其中创建访问条目的集群的名称。
1. 选择**访问**选项卡。
1. 选择要更新的访问条目。
1. 选择**编辑**。
1. 对于**用户名**，您可以更改现有值。
1. 对于**组**，您可以移除现有的组名称或添加新的组名称。如果存在以下组名称，请不要将其移除：**system:nodes** 或 **system:bootstrappers**。移除这些组可能会导致集群无法正常运行。如果您未指定任何组名称并想使用 Amazon EKS 授权，请在后续步骤中关联[访问策略](access-policies.md)。
1. 对于**标签**，您可以为访问条目分配标签。例如，为了更轻松地查找所有具有相同标签的资源。您也可以移除现有标签。
1. 选择 **Save changes（保存更改）**。
1. 如果要将访问策略与条目关联，请参阅 [将访问策略与访问条目关联起来](access-policies.md)。
## AWS CLI
1. 按照《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)中所述安装 AWS CLI。
1. 更新访问条目 将 *my-cluster* 替换为您的集群的名称，将 *111122223333* 替换为您的 AWS 账户 ID，将 *EKS-my-cluster-my-namespace-Viewers* 替换为 IAM 角色的名称。
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
如果访问条目的类型值不是 `STANDARD`，则不能使用 `--kubernetes-groups` 选项。您也不能将访问策略与访问条目关联到 `STANDARD` 类型之外的访问条目。
# 删除访问条目
如果您发现自己误删了访问条目，则可以随时重新创建。如果您要删除的访问条目与任何访问策略相关联，则关联会自动删除。在删除访问条目之前，您不必取消访问策略与访问条目的关联。
您可以使用 AWS 管理控制台 或 AWS CLI 删除访问条目。
## AWS 管理控制台
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择要从中删除访问条目的集群的名称。
1. 选择**访问**选项卡。
1. 在**访问条目**列表中，选择要删除的访问条目。
1. 选择 Delete。
1. 在确认对话框中，选择**删除**。
## AWS CLI
1. 按照《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)中所述安装 AWS CLI。
1. 要删除访问条目，将 *my-cluster* 替换为您的集群名称，将 *111122223333* 替换为您的 AWS 账户 ID，将 *my-role* 替换为您不想再访问集群的 IAM 角色的名称。
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# 为 EKS 访问条目设置自定义用户名
在为 Amazon EKS 创建访问条目时，可以使用自动生成的用户名，也可以指定自定义用户名。本页介绍这两个选项，并将指导您设置自定义用户名。
## 概述
访问条目中的用户名用于识别 Kubernetes 日志和审计跟踪记录中的 IAM 主体。默认情况下，Amazon EKS 会根据 IAM 身份的 ARN 生成用户名，但您可以根据需要指定自定义用户名。
## 默认用户名生成
如果不指定用户名的值，Amazon EKS 会根据 IAM 身份自动生成用户名：
+ **对于 IAM 用户**：
+ EKS 会将 Kubernetes 用户名设置为 IAM 用户的 ARN
+ 示例：
```
{arn-aws}iam::<111122223333>:user/
```
+ **对于 IAM 角色**：
+ EKS 会根据 IAM 角色的 ARN 设置 Kubernetes 用户名
+ 分派角色时此角色的 STS ARN。Amazon EKS 会将 `{{SessionName}}` 附加到该角色中。如果您指定的角色的 ARN 包含路径，Amazon EKS 会在生成的用户名中将其移除。
+ 示例：
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
除非您出于特定原因要指定自己的用户名，否则我们建议您不要指定用户名，而是让 Amazon EKS 为您自动生成用户名。
## 设置自定义用户名
创建访问条目时，可以使用 `--username` 参数指定自定义用户名：
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### 自定义用户名的要求
如果指定自定义用户名：
+ 用户名不能以 `system:`、`eks:`、`aws:`、`amazon:` 或 `iam:` 开头。
+ 如果该用户名用于 IAM 角色，我们建议您在用户名的末尾添加 `{{SessionName}}` 或 `{{SessionNameRaw}}`。
+ 如果您在用户名中添加 `{{SessionName}}` 或 `{{SessionNameRaw}}`，则该用户名必须在 \$1\$1SessionName\$1\$1 *之前*加一个冒号。
# 使用访问策略和 AWS CLI 为 IAM 角色或用户创建访问条目
创建使用 AWS 托管的 EKS 访问策略的 Amazon EKS 访问条目，以向 IAM 身份授予访问和管理 Kubernetes 集群的标准化权限。
## 概览
Amazon EKS 中的访问条目定义了 IAM 身份（用户和角色）如何访问 Kubernetes 集群并与之交互。通过创建使用 EKS 访问策略的访问条目，您可以执行以下操作：
+ 向特定的 IAM 用户或角色授予访问 EKS 集群的权限
+ 使用 AWS 托管的 EKS 访问策略控制权限，这种策略提供标准化的预定义权限集
+ 将权限范围限定为特定的命名空间或集群范围
+ 无需修改 `aws-auth` ConfigMap 或创建 Kubernetes RBAC 资源即可简化访问管理
+ 使用 AWS 集成的 Kubernetes 访问控制方法，该方法涵盖常见使用案例，同时保持安全最佳实践
建议在大多数使用案例中使用此方法，因为其无需手动配置 Kubernetes RBAC 即可提供 AWS 托管的标准化权限。EKS 访问策略无需手动配置 Kubernetes RBAC 资源，并提供涵盖常见使用案例的预定义权限集。
## 先决条件
+ 必须将集群的*身份验证模式*配置为启用*访问条目*。有关更多信息，请参阅 [更改身份验证模式以使用访问条目](setting-up-access-entries.md)。
+ 按照《AWS 命令行界面用户指南》的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)中所述，安装和配置 AWS CLI。
## 步骤 1：定义访问条目
1. 找到要向其授予权限的 IAM 身份（例如用户或角色）的 ARN。
+ 每个 IAM 身份只能有一个 EKS 访问条目。
1. 确定您希望 Amazon EKS 访问策略权限仅应用于特定的 Kubernetes 命名空间，还是应用于整个集群。
+ 如果要将权限限制为特定的命名空间，请记下命名空间名称。
1. 为 IAM 身份选择所需的 EKS 访问策略。此策略会授予集群内权限。记下策略的 ARN。
+ 有关策略列表，请参阅[可用的访问策略](access-policy-permissions.md)。
1. 确定自动生成的用户名是否适用于访问条目，或者是否需要手动指定用户名。
+ AWS 会根据 IAM 身份自动生成此值。您可以设置自定义用户名。这会显示在 Kubernetes 日志中。
+ 有关更多信息，请参阅 [为 EKS 访问条目设置自定义用户名](set-custom-username.md)。
## 步骤 2：创建访问条目
规划好访问条目后，使用 AWS CLI 进行创建。
以下示例涵盖了大多数使用案例。[查看 CLI 参考以了解所有配置选项](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html)。
您将在下一步中附加访问策略。
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## 步骤 3：关联访问策略
根据您是否希望将策略限制为指定的 Kubernetes 命名空间，命令会有所不同。
您需要访问策略的 ARN。查看[可用的访问策略](access-policy-permissions.md)。
### 创建没有命名空间作用域的策略
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### 创建具有命名空间作用域的策略
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## 后续步骤
+ [创建 kubeconfig，以便将 kubectl 与 IAM 身份结合使用](create-kubeconfig.md)
# 使用 AWS CLI 通过 Kubernetes 组创建访问条目
创建 Amazon EKS 访问条目，这些条目使用 Kubernetes 组进行授权且需要手动配置 RBAC。
**注意**
对于大多数使用案例，建议使用 EKS 访问策略，而不是本页介绍的 Kubernetes 组方法。EKS 访问策略提供了一种更简单、与 AWS 更集成的方式来管理访问权限，无需手动配置 RBAC。仅当您需要比 EKS 访问策略所提供之控制更精细的控制时，才可使用 Kubernetes 组方法。
## 概览
访问条目定义了 IAM 身份（用户和角色）如何访问 Kubernetes 集群。Kubernetes 组方法通过标准的 Kubernetes RBAC 组，向 IAM 用户或角色授予访问 EKS 集群的权限。此方法需要创建和管理 Kubernetes RBAC 资源（Roles、RoleBindings、ClusterRoles 和 ClusterRoleBindings），如果您需要高度自定义的权限集、复杂的授权要求或想要在混合 Kubernetes 环境中保持一致的访问控制模式，建议使用此方法。
本主题不介绍为用于 Amazon EC2 实例加入 EKS 集群的 IAM 身份创建访问条目。
## 先决条件
+ 必须将集群的*身份验证模式*配置为启用*访问条目*。有关更多信息，请参阅 [更改身份验证模式以使用访问条目](setting-up-access-entries.md)。
+ 按照《AWS 命令行界面用户指南》的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)中所述，安装和配置 AWS CLI。
+ 建议熟悉 Kubernetes RBAC。有关更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
## 步骤 1：定义访问条目
1. 找到要向其授予权限的 IAM 身份（例如用户或角色）的 ARN。
+ 每个 IAM 身份只能有一个 EKS 访问条目。
1. 确定要与此 IAM 身份关联的 Kubernetes 组。
+ 您需要创建或使用引用了这些组的现有 Kubernetes `Role`/`ClusterRole` 和 `RoleBinding`/`ClusterRoleBinding` 资源。
1. 确定自动生成的用户名是否适用于访问条目，或者是否需要手动指定用户名。
+ AWS 会根据 IAM 身份自动生成此值。您可以设置自定义用户名。这会显示在 Kubernetes 日志中。
+ 有关更多信息，请参阅 [为 EKS 访问条目设置自定义用户名](set-custom-username.md)。
## 步骤 2：通过 Kubernetes 组创建访问条目
规划好访问条目后，使用 AWS CLI 通过相应的 Kubernetes 组创建该条目。
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
进行如下替换：
+ 将 `` 替换为 EKS 集群名称
+ 将 `` 替换为 IAM 用户或角色的 ARN
+ 将 `` 替换为以逗号分隔的 Kubernetes 组列表（例如“system:developers,system:readers”）
[查看 CLI 参考以了解所有配置选项](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html)。
## 步骤 3：配置 Kubernetes RBAC
要让 IAM 主体能够访问集群上的 Kubernetes 对象，必须创建和管理 Kubernetes 基于角色的访问控制（RBAC）对象：
1. 创建定义权限的 Kubernetes `Role` 或 `ClusterRole` 对象。
1. 在集群上创建 Kubernetes `RoleBinding` 或 `ClusterRoleBinding` 对象，将组名称指定为 `kind: Group` 的 `subject`。
有关在 Kubernetes 中配置组和权限的详细信息，请参阅 Kubernetes 文档中的[使用 RBAC 鉴权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
## 后续步骤
+ [创建 kubeconfig，以便将 kubectl 与 IAM 身份结合使用](create-kubeconfig.md)
# 向 IAM 用户授予使用 ConfigMap 访问 Kubernetes 的权限
**重要**
`aws-auth ConfigMap` 已弃用。有关管理 Kubernetes API 访问权限的推荐方法，请参阅[使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。
在 Amazon EKS 控制面板上运行的 [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) 支持使用 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)访问集群。身份验证程序从 `aws-auth` `ConfigMap` 获取配置信息。对于所有 `aws-auth` `ConfigMap` 设置，请参阅 GitHub 上的[完整配置格式](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format)。
## 将 IAM 主体添加到 Amazon EKS 集群
创建 Amazon EKS 集群时，将为创建集群的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)自动授予 Amazon EKS 控制面板中基于集群角色的访问控制（RBAC）配置中的 `system:masters` 权限。该主体不会显示在任何可见配置中，因此请确保跟踪最初创建集群的主体。要授予其他 IAM 主体与集群进行交互的能力，请编辑 Kubernetes 中的 `aws-auth ConfigMap`，创建 Kubernetes `rolebinding` 或 `clusterrolebinding`，名为 `aws-auth ConfigMap` 中指定的 `group`。
**注意**
有关 Kubernetes 基于角色的访问控制（RBAC）配置的更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 鉴权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
1. 确定 `kubectl` 用来访问集群的凭据。可以在计算机上使用下面的命令查看 `kubectl` 使用的凭据。如果不使用默认路径，请将 *\$1/.kube/config* 替换为 `kubeconfig` 文件的路径。
```
cat ~/.kube/config
```
示例输出如下。
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
在上一个示例输出中，为 *my-cluster* 集群配置名为 *admin* 的用户凭证。如果这是创建了集群的用户，那么该用户有权访问您的集群。如果它不是创建集群的用户，则需要完成剩余步骤才能让其它 IAM 主体有权访问集群。[IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)建议您向角色而不是用户授予权限。您可以使用以下命令查看哪些其他主体当前有权访问您的集群：
```
kubectl describe -n kube-system configmap/aws-auth
```
示例输出如下。
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
上一个示例是默认的 `aws-auth` `ConfigMap`。只有节点实例角色才有权访问集群。
1. 请确保拥有现有的 Kubernetes `roles` 和 `rolebindings`，或者可将 IAM 主体映射到其中的 `clusterroles` 和 `clusterrolebindings`。有关这些资源的更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
1. 查看您现有的 Kubernetes `roles` 或 `clusterroles`。`Roles` 范围限定为 `namespace`，但 `clusterroles` 范围则限定为集群。
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. 查看之前的输出中返回的任何 `role` 或 `clusterrole` 的详细信息，并确认它具有您希望 IAM 主体在集群中拥有的权限（`rules`）。
将 *role-name* 替换为在上一个命令的输出中返回的 `role` 名称。将 *kube-system* 替换为 `role` 的命名空间。
```
kubectl describe role role-name -n kube-system
```
将 *cluster-role-name* 替换为在上一个命令的输出中返回的 `clusterrole` 名称。
```
kubectl describe clusterrole cluster-role-name
```
1. 查看您现有的 Kubernetes `rolebindings` 或 `clusterrolebindings`。`Rolebindings` 范围限定为 `namespace`，但 `clusterrolebindings` 范围则限定为集群。
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. 查看任何 `rolebinding` 或 `clusterrolebinding` 的详细信息，并确认它具有在上一步中列为 `roleRef` 的 `role` 或 `clusterrole`，以及为 `subjects` 列出的组名称。
将 *role-binding-name* 替换为在上一个命令的输出中返回的 `rolebinding` 名称。将 *kube-system* 替换为 `rolebinding` 的 `namespace`。
```
kubectl describe rolebinding role-binding-name -n kube-system
```
示例输出如下。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
将 *cluster-role-binding-name* 替换为在上一个命令的输出中返回的 `clusterrolebinding` 名称。
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
示例输出如下。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. 编辑 `aws-auth` `ConfigMap`。您可以使用 `eksctl` 之类的工具更新 `ConfigMap`，或者可以通过编辑它来进行手动更新。
**重要**
我们建议使用 `eksctl` 或者其他工具来编辑 `ConfigMap`。有关您可以使用的其它工具的信息，请参阅《Amazon EKS 最佳实践指南》中的[使用工具对 aws-authConfigMap 进行更改](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap)。格式不正确的 `aws-auth` `ConfigMap` 可能会导致您失去对集群的访问权限。
+ 查看[使用 eksctl 编辑 configmap](#configmap-eksctl) 的步骤。
+ 查看[手动编辑 configmap](#configmap-manual) 的步骤。
### 使用 Eksctl 编辑 Configmap
1. 您需要在设备或 AWS CloudShell 上安装 `0.215.0` 版或更高版本的 `eksctl` 命令行工具。要安装或更新 `eksctl`，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
1. 查看 `ConfigMap` 中的当前映射。将 *my-cluster* 替换为您的集群的名称。将 *region-code* 替换为您的集群所在的 AWS 区域。
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
示例输出如下。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. 为角色添加映射。将 *my-role* 替换为您的角色名称。将 *eks-console-dashboard-full-access-group* 替换为在 Kubernetes `RoleBinding` 或 `ClusterRoleBinding` 对象中指定的组名称。请将 *111122223333* 替换为您的账户 ID。您可以将 *admin* 替换为您选择的任何名称。
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**重要**
角色 ARN 不能包含 `role/my-team/developers/my-role` 等路径。ARN 的格式必须为 ` arn:aws:iam::111122223333:role/my-role `。在此示例中，`my-team/developers/` 需要删除。
示例输出如下。
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. 为用户添加映射。[IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)建议您向角色而不是用户授予权限。将 *my-user* 替换为您的用户名。将 *eks-console-dashboard-restricted-access-group* 替换为在 Kubernetes `RoleBinding` 或 `ClusterRoleBinding` 对象中指定的组名称。请将 *111122223333* 替换为您的账户 ID。您可以将 *my-user* 替换为您选择的任何名称。
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
示例输出如下。
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws:iam::111122223333:user/my-user" to auth ConfigMap
```
1. 再次查看 `ConfigMap` 中的映射。
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
示例输出如下。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws:iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### 手动编辑 Configmap
1. 打开 `ConfigMap` 文件进行编辑。
```
kubectl edit -n kube-system configmap/aws-auth
```
**注意**
如果您收到错误指示“`Error from server (NotFound): configmaps "aws-auth" not found`”，请使用[将 aws-auth ConfigMap 应用于您的集群](#aws-auth-configmap)中的过程来应用库存 `ConfigMap`。
1. 将您的 IAM 主体添加到 `ConfigMap`。IAM 组不是 IAM 主体，因此无法将其添加到 `ConfigMap`。
+ **添加 IAM 角色（例如，对于[联合身份用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)）：**将角色详细信息添加到 `data` 下 `ConfigMap` 的 `mapRoles` 部分。如果此部分在文件中尚不存在，请添加它。每个条目支持以下参数：
+ **rolearn**：要添加的 IAM 角色的 ARN。此值不能包含路径。例如，您无法指定 ARN，例如 ` arn:aws:iam::111122223333:role/my-team/developers/role-name `。ARN 需要为 ` arn:aws:iam::111122223333:role/role-name `。
+ **username**：Kubernetes 内要映射到 IAM 角色的用户名。
+ **组**：要将角色映射到的组或 Kubernetes 组列表。该组可以是默认组，也可以是 `clusterrolebinding` 或 `rolebinding` 中指定的组。有关更多信息，请参阅 Kubernetes 文档中的[默认角色和角色绑定](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)。
+ **要添加 IAM 用户：**[IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)建议您向角色而不是用户授予权限。将用户详细信息添加到 `data` 下 `ConfigMap` 的 `mapUsers` 部分。如果此部分在文件中尚不存在，请添加它。每个条目支持以下参数：
+ **userarn**：要添加的 IAM 用户的 ARN。
+ **username**：Kubernetes 内要映射到 IAM 用户的用户名。
+ **组**：要将用户映射到的组或 Kubernetes 组列表。该组可以是默认组，也可以是 `clusterrolebinding` 或 `rolebinding` 中指定的组。有关更多信息，请参阅 Kubernetes 文档中的[默认角色和角色绑定](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)。
1. 例如，下面的 YAML 块包含：
+ 一个 `mapRoles` 部分，此部分将 IAM 节点实例映射到 Kubernetes 组，以便节点可以自行注册到集群，和映射到可以查看所有集群的所有 Kubernetes 资源的 Kubernetes 组的 `my-console-viewer-role` IAM 角色。有关 `my-console-viewer-role` IAM 角色所需的 IAM 和 Kubernetes 组权限的列表，请参阅 [所需的权限](view-kubernetes-resources.md#view-kubernetes-resources-permissions)。
+ 一个 `mapUsers` 部分，此部分将默认 AWS 账户中的 `admin` IAM 用户映射到 `system:masters` Kubernetes 组，以及映射到可以查看特定命名空间的 Kubernetes 资源的 Kubernetes 组的另一个 AWS 账户的 `my-user` 用户。有关 `my-user` IAM 用户所需的 IAM 和 Kubernetes 组权限的列表，请参阅 [所需的权限](view-kubernetes-resources.md#view-kubernetes-resources-permissions)。
根据需要添加或删除行并将所有 example values 替换为您自己的值。
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws:iam::444455556666:user/my-user
username: my-user
```
1. 保存文件并退出文本编辑器。
## 将 `aws-auth` `ConfigMap` 应用到集群
使用 `eksctl` 创建托管节点组时或创建节点组时自动创建 `aws-auth``ConfigMap` 并应用于集群。最初创建它的目的是允许节点加入您的集群，也可以使用 `ConfigMap` 为 IAM 主体添加基于角色的访问控制（RBAC）。如果您尚未启动自行管理的节点并且未将 `aws-auth` `ConfigMap` 应用到集群，则可以按照下面的过程执行此操作。
1. 检查您是否已经应用了 `aws-auth` `ConfigMap`。
```
kubectl describe configmap -n kube-system aws-auth
```
如果您收到错误指示“`Error from server (NotFound): configmaps "aws-auth" not found`”，则继续以下步骤应用库存 `ConfigMap`。
1. 下载、编辑和应用 AWS 身份验证器配置映射。
1. 下载配置映射。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. 在 `aws-auth-cm.yaml` 文件中，将 `rolearn` 设置为与您的节点关联的 IAM 角色的 Amazon 资源名称（ARN）。您可以使用文本编辑器或者通过替换 *my-node-instance-role* 和运行以下命令来执行此操作：
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
请勿修改此文件中的任何其它行。
**重要**
角色 ARN 不能包含 `role/my-team/developers/my-role` 等路径。ARN 的格式必须为 ` arn:aws:iam::111122223333:role/my-role `。在此示例中，`my-team/developers/` 需要删除。
您可以检查节点组的 AWS CloudFormation 堆栈输出，并查找以下值：
+ **InstanceRoleARN** – 对于使用 `eksctl` 创建的节点组
+ **NodeInstanceRole** – 对于在 AWS 管理控制台 中使用 Amazon EKS 提供的 AWS CloudFormation 模板创建的节点组
1. 应用配置。此命令可能需要几分钟才能完成。
```
kubectl apply -f aws-auth-cm.yaml
```
**注意**
如果您收到任何授权或资源类型错误，请参阅故障排除主题中的 [未经授权或访问被拒绝 (`kubectl`)](troubleshooting.md#unauthorized)。
1. 查看节点的状态并等待它们达到 `Ready` 状态。
```
kubectl get nodes --watch
```
输入 `Ctrl`\$1`C` 以返回到 Shell 提示符。
# 通过外部 OIDC 提供者向用户授予 Kubernetes 访问权限
Amazon EKS 支持使用 OpenID Connect (OIDC) 身份提供商作为对您的集群的用户进行身份验证的方法。OIDC 身份提供者可与 AWS Identity and Access Management（IAM）结合使用或作为其替代方法。有关使用 IAM 的更多信息，请参阅[向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)。配置集群身份验证后，您可以创建 Kubernetes `roles` 和 `clusterroles` 以将权限分配给角色，然后使用 Kubernetes `rolebindings` 和 `clusterrolebindings` 将角色绑定到身份。有关更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
+ 您可以将一个 OIDC 身份提供商与您的集群关联。
+ Kubernetes 不提供 OIDC 身份提供者。您可以使用现有的公共 OIDC 身份提供商，也可以运行您自己的身份提供商。有关经认证提供商的列表，请参阅 OpenID 网站上的 [OpenID 认证](https://openid.net/certification/)。
+ OIDC 身份提供商的发布者 URL 必须可公开访问，以便 Amazon EKS 能够发现签名密钥。Amazon EKS 不支持拥有自签名证书的 OIDC 身份提供者。
+ 您不能禁用向集群进行 IAM 身份验证，因为在将节点加入集群时仍需要使用。
+ Amazon EKS 集群仍必须由 AWS [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)创建，而不是由 OIDC 身份提供商用户创建。这是因为集群创建者与 Amazon EKS API 进行交互，而不是与 Kubernetes API 进行交互。
+ 如果为控制面板启用了 CloudWatch 日志，则将在集群的审核日志中列出经 OIDC 身份提供者验证的用户。有关更多信息，请参阅 [启用或禁用控制面板日志](control-plane-logs.md#enabling-control-plane-log-export)。
+ 您无法使用来自 OIDC 提供者的账户登录 AWS 管理控制台。您只能通过使用 AWS Identity and Access Management 账户登录 AWS 管理控制台，从而[在 AWS 管理控制台中查看 Kubernetes 资源](view-kubernetes-resources.md)。
## 关联 OIDC 身份提供商
您需要提供商提供以下信息，然后才能将 OIDC 身份提供商与集群关联：
**发布者 URL**
OIDC 身份提供者的 URL，该 URL 允许 API 服务器发现用于验证令牌的公共签名密钥。该 URL 必须以 `https://` 开头，并应与提供者的 OIDC ID 令牌中的 `iss` 声明相对应。根据 OIDC 标准，允许使用路径组件，但不允许使用查询参数。通常，URL 只包含一个主机名称，如 `https://server.example.org` 或 `https://example.com`。该 URL 应指向 `.well-known/openid-configuration` 以下的级别，并且必须可通过 Internet 网公开访问。
**客户端 ID（也称为*受众*）**
向 OIDC 身份提供商发出身份验证请求的客户端应用程序的 ID。
您可以使用 `eksctl` 或 AWS 管理控制台 关联身份提供商。
### 使用 eksctl 关联身份提供者
1. 使用以下内容创建名为 `associate-identity-provider.yaml` 的文件。将 example values 替换为您自己的值。`identityProviders` 部分中的值是从 OIDC 身份提供商处获取的。仅 `identityProviders` 下的 `name`、`type`、`issuerUrl` 和 `clientId` 设置需要相应值。
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**重要**
不要为 `groupsPrefix` 或 `usernamePrefix` 指定 `system:` 或该字符串的任何部分。
1. 创建提供商。
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. 要使用 `kubectl` 以与集群和 OIDC 身份提供者结合使用，请参阅 Kubernetes 文档中的[使用 kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)。
### 您可以使用 AWS 控制台关联身份提供者。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 选择您的集群，然后选择**访问**选项卡。
1. 在 **OIDC 身份提供者**部分中，选择“关联身份提供者”。
1. 在 **Associate OIDC Identity Provider（关联 OIDC 身份提供商）**页面上，输入或选择以下选项，然后选择 **Associate（关联）**。
+ 对于 **Name（名称）**，为提供商输入一个唯一的名称。
+ 对于 **Issuer URL（发布者 URL）**，输入您的提供商的 URL。此 URL 必须可通过 Internet 进行访问。
+ 在**客户端 ID** 中，输入 OIDC 身份提供者的客户端 ID（也称为**受众**）。
+ 对于 **Username claim（用户名声明）**，输入要用作用户名的声明。
+ 对于**组声明**，输入要用作用户的组的声明。
+ （可选）选择 **Advanced options（高级选项）**，输入或选择以下信息。
+ **Username prefix（用户名前缀）**– 输入要加在用户名声明前面的前缀。该前缀加在用户名声明前面，以防止与现有名称发生冲突。如果您未提供值，并且用户名为 `email` 之外的值，则前缀默认为 **Issuer URL（发布者 URL）**的值。您可以使用值 ` -` 来禁用所有前缀。不要指定 `system:` 或该字符串的任何部分。
+ **组前缀** – 输入要加在组声明前面的前缀。该前缀加在组声明前面，以防止与现有名称（如 ` system: groups`）发生冲突。例如，值 `oidc:` 会创建组名称，如 `oidc:engineering` 和 `oidc:infra`。不要指定 `system:` 或该字符串的任何部分。
+ **Required claims（所需声明）**– 选择 **Add claim（添加声明）**，然后在客户端 ID 令牌中输入描述所需声明的一个或多个键值对。这些键值对描述了 ID 令牌中所需的声明。如果设置，则验证每个声明是否存在于具有匹配值的 ID 令牌中。
1. 要使用 `kubectl` 以与集群和 OIDC 身份提供者结合使用，请参阅 Kubernetes 文档中的[使用 kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)。
## 示例 IAM policy
如果要阻止 OIDC 身份提供商与集群关联，请创建以下 IAM policy 并将其与 Amazon EKS 管理员的 IAM 账户关联。有关更多信息，请参阅《IAM 用户指南》中的[创建 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)和[添加 IAM 身份权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)**以及《服务授权参考》中的 [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html)。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
如果 `clientID` 为 `kubernetes` 而 `issuerUrl` 为 `https://cognito-idp.us-west-2amazonaws.com/*`，则以下示例策略允许进行 OIDC 身份提供商关联。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# 解除 OIDC 身份提供商与集群的关联
如果您解除 OIDC 身份提供商与集群的关联，则提供商中包含的用户将无法再访问该集群。但是，您仍然可以使用 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)访问该集群。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在 **OIDC Identity Providers（OIDC 身份提供商）**部分中，选择 **Disassociate（解除关联）**，输入身份提供商名称，然后选择 `Disassociate`。
# 在 AWS 管理控制台中查看 Kubernetes 资源
您可以使用 AWS 管理控制台 查看部署到您的集群的 Kubernetes 资源。您无法使用 AWS CLI 或 [eksctl](https://eksctl.io/) 查看 Kubernetes 资源。要使用命令行工具查看 Kubernetes 资源，请使用 [kubectl](install-kubectl.md)。
**注意**
要在 AWS 管理控制台中查看**资源**选项卡和**计算**选项卡上的**节点**部分，您使用的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必须具有特定的 IAM 和 Kubernetes 权限。有关更多信息，请参阅 [所需的权限](#view-kubernetes-resources-permissions)。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在 **Clusters**（集群）列表中，选择包含要查看的 Kubernetes 资源的集群。
1. 选择**资源**选项卡。
1. 选择您要查看其资源的 **Resource type**（资源类型）组，例如 **Workloads**（工作负载）。您可以看到该组中的资源类型列表。
1. 选择资源类型，例如 **Workloads**（工作负载）组中的 **Deployments**（部署）。您可以看到资源类型的描述、Kubernetes 文档的链接以获取有关资源类型的更多信息，以及在集群上部署的该类型资源的列表。如果列表为空，则表示您的集群中没有部署此类型的资源。
1. 选择一种资源以查看关于该资源的更多信息。请尝试以下示例：
+ 依次选择 **Workloads**（工作负载）组、**Deployments**（部署）资源类型和 **coredns** 资源。当您选择资源时，您默认情况下处于 **Structured view**（结构化视图）中。对于某些资源类型，您会在 **Structured view**（结构化视图）中看到 **Pods**（容器组（pod））部分。本节列出了由工作负载管理的容器组（pod）。您可以选择列出的任何容器组（pod），查看有关容器组（pod）的信息。并非所有资源类型都在**结构化视图**中显示信息。如果您在该资源的页面的右上角选择 **Raw view**（原始视图），您可以看到来自 Kubernetes API 对该资源的完整 JSON 响应。
+ 选择 **Cluster**（集群）组，然后选择 **Nodes**（节点）资源类型。您可以看到集群中所有节点的列表。节点可以是任意 [Amazon EKS 节点类型](eks-compute.md)。这与您在为集群选择 **Compute**（计算）选项时在 **Nodes**（节点）部分中看到的列表相同。从列表中选择节点资源。在**结构化视图**中，您还会看到 **Pods**（容器组（pod））部分。此部分会显示在节点上运行的所有容器组（pod）。
## 所需的权限
要在 AWS 管理控制台中查看**资源**选项卡和**计算**选项卡上的**节点**部分，您使用的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必须具有特定的最低 IAM 和 Kubernetes 权限。您必须确保已正确配置 IAM 和 Kubernetes RBAC 权限。完成以下步骤以将所需的权限分配给您的 IAM 主体。
1. 确保向您正在使用的 IAM 主体分配 `eks:AccessKubernetesApi` 以及查看 Kubernetes 资源所需的其他 IAM 权限。有关如何为 IAM 主体编辑权限的更多信息，请参阅《IAM 用户指南》中的[控制主体的访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals)。有关如何编辑角色权限策略的信息，请参阅《IAM 用户指南》中的[修改角色权限策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy)。
以下示例策略包含主体查看账户中所有集群的 Kubernetes 资源所需的权限。将 *111122223333* 替换为您的 AWS 账户 ID。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
要查看[已连接集群](eks-connector.md)中的节点，[Amazon EKS 连接器 IAM 角色](connector-iam-role.md)应能够模拟集群中的主体。这让 [Amazon EKS Connector](eks-connector.md) 将主体映射到 Kubernetes 用户。
1. 使用 EKS 访问条目配置 Kubernetes RBAC 权限。
**什么是 EKS 访问条目？**
EKS 访问条目是授予 IAM 主体（用户和角色）访问您的 Kubernetes 集群的简化方法。无需手动管理 Kubernetes RBAC 资源和 `aws-auth` ConfigMap，访问条目会自动利用 AWS 提供的管理策略来处理 IAM 和 Kubernetes 权限之间的映射关系。有关访问条目的详细信息，请参阅 [使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。有关可用访问策略及其权限的信息，请参阅[访问策略权限](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html)。
您可以通过两种方式将 Kubernetes 权限附加到访问条目：
+ **使用访问策略：**访问策略是由 AWS 维护的预定义 Kubernetes 权限模板。它们为常见使用案例提供了标准化权限集。
+ **参考 Kubernetes 组：**如果您将某个 IAM 身份与某个 Kubernetes 组关联，则可以创建向该组授予权限的 Kubernetes 资源。有关更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。
1. 使用 AWS CLI 为您的 IAM 主体创建访问条目。将 *my-cluster* 替换为您的集群的名称。请将 *111122223333* 替换为您的账户 ID。
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
示例输出如下。
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws:eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. 将策略与访问条目关联。要查看 Kubernetes 资源，请使用 `AmazonEKSViewPolicy`：
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
示例输出如下。
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
对于特定于命名空间的访问权限，您可以将策略范围限定为特定命名空间：
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. 验证是否已成功创建访问条目：
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
1. 列出关联的策略以确认策略关联：
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
示例输出如下。
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail 可见性
查看 Kubernetes 资源时，您将在 CloudTrail 日志中看到以下操作名称：
+ `AccessKubernetesApi`：读取或查看资源时
此 CloudTrail 事件提供了对您的 Kubernetes 资源的读取访问权限的审计跟踪记录。
**注意**
此操作名称将显示在 CloudTrail 日志中，仅用于审计目的。它不是 IAM 操作，不能在 IAM 策略声明中使用。要通过 IAM 策略控制对 Kubernetes 资源的读取权限，请使用 [所需的权限](#view-kubernetes-resources-permissions) 部分中所示的 `eks:AccessKubernetesApi` 权限。
# 向 AWS 服务授予对 Kubernetes API 的写入权限
## 所需的权限
要使 AWS 服务能够对您的 Amazon EKS 集群中的 Kubernetes 资源执行写入操作，您必须同时授予 `eks:AccessKubernetesApi` 和 `eks:MutateViaKubernetesApi` IAM 权限。
例如，Amazon SageMaker HyperPod 使用这些权限来启用 SageMaker AI Studio 的模型部署。有关更多信息，请参阅《Amazon SageMaker AI 开发人员指南》中的[设置可选的 JavaScript SDK 权限](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js)。
**重要**
创建、更新和删除之类的写入操作需要这两种权限，如果缺少任一权限，则写入操作将失败。
## CloudTrail 可见性
在对 Kubernetes 资源执行写入操作时，您会在 CloudTrail 日志中看到特定的操作名称：
+ `createKubernetesObject`：在创建新资源时
+ `updateKubernetesObject`：在修改现有资源时
+ `deleteKubernetesObject`：在移除资源时
这些 CloudTrail 事件会提供有关您对 Kubernetes 资源所做的所有修改的审计跟踪记录。
**注意**
这些操作名称将显示在 CloudTrail 日志中，仅用于审计目的。它们不是 IAM 操作，不能在 IAM 策略声明中使用。要通过 IAM 策略控制对 Kubernetes 资源的写入权限，请使用 [所需的权限](#mutate-kubernetes-resources-permissions) 部分中所示的 `eks:MutateViaKubernetesApi` 权限。
# 通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群
**提示**
[注册参加](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)即将举办的 Amazon EKS 讲习会。
在本主题中，您将为您的集群创建 `kubeconfig` 文件（或更新现有文件）。
`kubectl` 命令行工具使用 `kubeconfig` 文件中的配置信息与集群的 API 服务器通信。有关更多信息，请参阅 Kubernetes 文档中的[使用 kubeconfig 文件组织集群访问](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
Amazon EKS 使用带 `kubectl` 的 `aws eks get-token` 命令进行集群身份验证。默认情况下，AWS CLI 使用以下命令返回的相同凭证：
```
aws sts get-caller-identity
```
+ 现有 Amazon EKS 集群。要部署一个角色，请参阅[开始使用 Amazon EKS](getting-started.md)。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 有权将 `eks:DescribeCluster` API 操作用于您指定的集群的 IAM 用户或角色。有关更多信息，请参阅 [Amazon EKS 基于身份的策略示例](security-iam-id-based-policy-examples.md)。如果您使用自己的 OpenID Connect 提供者提供的身份来访问集群，请参阅 Kubernetes 文档中的[使用 kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) 来创建或更新 `kube config` 文件。
## 自动创建 `kubeconfig` 文件
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 将 `eks:DescribeCluster` API 操作用于您指定的集群的权限。有关更多信息，请参阅 [Amazon EKS 基于身份的策略示例](security-iam-id-based-policy-examples.md)。
1. 为集群创建或更新 `kubeconfig` 文件。将 *region-code* 替换为您的集群所在的 AWS 区域，并将 *my-cluster* 替换为您的集群的名称。
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
预设情况下，在主目录的原定设置 `kubeconfig` 路径 (`.kube`) 中创建得到的配置文件，或者或与该位置的现有 `config` 合并。您可以使用 `--kubeconfig` 选项指定其他路径。
发出 `kubectl` 命令时，可以使用 `--role-arn` 选项指定 IAM 角色 ARN 供身份验证使用。否则，将使用默认 AWS CLI 或 SDK 凭证链中的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)。通过运行 `aws sts get-caller-identity` 命令可以查看默认 AWS CLI 或 SDK 标识。
对于所有可用选项，运行 `aws eks update-kubeconfig help` 命令，或请参阅《AWS CLI 命令参考》**中的 [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html)。
1. 测试配置。
```
kubectl get svc
```
示例输出如下。
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
如果您收到任何授权或资源类型错误，请参阅故障排除主题中的 [未经授权或访问被拒绝 (`kubectl`)](troubleshooting.md#unauthorized)。
# 使用 Kubernetes 服务账户授予 Kubernetes 工作负载访问 AWS 的权限
[管理服务账户](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)[了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)
## 服务账户令牌
在 Kubernetes 版本中默认启用 [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) 功能。此功能通过允许在 Kubernetes 上运行工作负载来提高服务账户令牌的安全性，以请求与受众、时间和密钥绑定的 JSON Web 令牌。服务账户令牌有效期为 1 小时。在较低的 Kubernetes 版本中，令牌并无到期限制。这意味着依赖这些令牌的客户端必须在一小时内刷新令牌。以下 [Kubernetes 客户端 SDK](https://kubernetes.io/docs/reference/using-api/client-libraries/) 会在所需的时间范围内自动刷新令牌：
+ Go 版本 `0.15.7` 和更高版本
+ Python 版本 `12.0.0` 和更高版本
+ Java 版本 `9.0.0` 和更高版本
+ JavaScript 版本 `0.10.3` 和更高版本
+ Ruby `master` 分支
+ Haskell 版本 `0.3.0.0`
+ C\$1 版本 `7.0.5` 和更高版本
如果您的工作负载使用的是早期客户端，则必须予以更新。为了使客户顺利迁移到更新的有时限的服务账户令牌，Kubernetes 在默认一小时内向服务账户令牌添加延长的到期期限。对于 Amazon EKS 集群，延长到期期限为 90 天。Amazon EKS 集群的 Kubernetes API 服务器会拒绝令牌超过 90 天的请求。我们建议您检查应用程序及其依赖项，以确保 Kubernetes 客户端开发工具包版本等于或高于之前列出的版本。
当 API 服务器收到令牌超过一小时的请求时，它会使用 `annotations.authentication.k8s.io/stale-token` 注释 API 审核日志事件。注释的值与以下示例类似：
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
如果您的集群启用了[控制面板日志记录](control-plane-logs.md)，则注释在审计日志内。您可以使用以下 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 查询，识别 Amazon EKS 集群中使用过时令牌的所有容器组（pod）：
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
`subject` 指的是容器组（pod）使用的服务账户。`elapsedtime` 表示读取最新令牌后的时间（以秒为单位）。对 API 服务器的请求在 `elapsedtime` 超过 90 天（7,776,000 秒）时被拒绝。您应该主动更新应用程序的 Kubernetes 客户端开发工具包，以使用前面列出的其中一个自动刷新令牌的版本。如果使用的服务账户令牌接近 90 天，并且您没有足够的时间在令牌到期之前更新客户端开发工具包版本，您可以终止现有容器组（pod）并创建新的容器组（pod）。这将导致重新获取服务账户令牌，从而为您提供额外 90 天的时间来更新客户端版本开发工具包。
如果容器组（pod）是部署的一部分，在保持高可用性的同时终止容器组（pod）的建议方法是使用以下命令执行部署。将 *my-deployment* 替换为您的部署的名称。
```
kubectl rollout restart deployment/my-deployment
```
## 集群附加组件
已更新以下集群附加组件，以使用自动重新获取服务账户令牌的 Kubernetes 客户端开发工具包。我们建议确保已在集群上安装列出的版本或更高版本。
+ 适用于 Kubernetes 的 Amazon VPC CNI 插件和指标帮助程序插件版本 `1.8.0` 和更高版本。要查看当前版本或进行更新，请参阅 [使用 Amazon VPC CNI 将 IP 分配给容器组（pod）](managing-vpc-cni.md) 和 [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md)。
+ CoreDNS `1.8.4` 及更高版本。要查看当前版本或更新它，请参阅 [在 Amazon EKS 集群中管理 DNS 的 CoreDNS](managing-coredns.md)。
+ AWS 负载均衡器控制器版本 `2.0.0` 和更高版本。要查看当前版本或更新它，请参阅 [使用 AWS 负载均衡器控制器路由互联网流量](aws-load-balancer-controller.md)。
+ 当前 `kube-proxy` 版本。要查看当前版本或更新它，请参阅 [在 Amazon EKS 集群中管理 `kube-proxy`](managing-kube-proxy.md)。
+ AWS for Fluent Bit 版本 `2.25.0` 或更高版本。要更新当前版本，请参阅 GitHub 上的[发布](https://github.com/aws/aws-for-fluent-bit/releases)。
+ Fluentd 镜像版本 [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) 或更高版本以及适用于 Kubernetes 元数据的 Fluentd 筛选器插件版本 [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) 或更高版本。
## 向 Amazon Elastic Kubernetes Service 集群上的工作负载授予 AWS Identity and Access Management 权限
对于向 Amazon EKS 集群中运行的工作负载授予 AWS Identity and Access Management 权限，Amazon EKS 提供了两种方法：*服务账户的 IAM 角色*和 *EKS 容器组身份*。
**服务账户的 IAM 角色**
*服务账户的 IAM 角色（IRSA）*可为 AWS 上运行的 Kubernetes 应用程序配置细粒度 IAM 权限，使其能够访问 Amazon S3 存储桶、Amazon DynamoDB 表等各种其他 AWS 资源。您可以在同一 Amazon EKS 集群中同时运行多个应用程序，并确保每个应用程序仅拥有所需的最低权限集。IRSA 旨在支持 AWS 支持的各种 Kubernetes 部署选项，例如 Amazon EKS、Amazon EKS Anywhere、AWS 上的 Red Hat OpenShift 服务，以及 Amazon EC2 实例上的自主管理型 Kubernetes 集群。因此，IRSA 是使用基础 AWS 服务（如 IAM）构建的，不直接依赖 Amazon EKS 服务和 EKS API。有关更多信息，请参阅 [服务账户的 IAM 角色](iam-roles-for-service-accounts.md)。
**EKS 容器组身份**
EKS 容器组身份为集群管理员提供了一个简化的工作流，用于对应用程序进行身份验证，以访问各种其他 AWS 资源，例如 Amazon S3 存储桶、Amazon DynamoDB 表等。EKS 容器组身份仅适用于 EKS，因此简化了集群管理员配置 Kubernetes 应用程序以获取 IAM 权限的方式。现在可以直接通过 AWS 管理控制台、EKS API 和 AWS CLI，用更少的步骤轻松配置这些权限，无需对集群内的任何 Kubernetes 对象执行任何操作。集群管理员无需在 EKS 和 IAM 服务之间切换，也无需使用特权 IAM 操作来配置应用程序所需的权限。现在可以跨多个集群使用 IAM 角色，无需在创建新集群时更新角色信任策略。EKS 容器组身份提供的 IAM 凭证包括角色会话标签，以及集群名称、命名空间、服务账户名称等属性。角色会话标签允许管理员根据匹配的标签访问 AWS 资源，从而使管理员能够创建可跨服务账户使用的单一角色。有关更多信息，请参阅 [了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)。
### 比较 EKS 容器组身份和 IRSA
总的来说，EKS 容器组身份和 IRSA 都允许您向在 Kubernetes 集群上运行的应用程序授予 IAM 权限。但是，二者在配置方式、支持的限制和启用的功能方面有根本不同。下面，我们将比较这两种解决方案的一些关键方面。
**注意**
AWS 建议尽可能使用 EKS 容器组（pod）身份授予您的容器组（pod）访问 AWS 资源的权限。有关更多信息，请参阅 [了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)。
| 属性 | EKS 容器组身份 | IRSA |
| --- | --- | --- |
| 角色可扩展性 | 您必须对每个角色设置一次，才能与新引入的 Amazon EKS 服务主体 `pods.eks.amazonaws.com` 建立信任。完成此一次性步骤后，每次在新集群中使用角色时，都无需更新该角色的信任策略。 | 每次要在新集群中使用 IAM 角色时，都必须使用新的 EKS 集群 OIDC 提供者端点，来更新该角色的信任策略。 |
| 集群可扩展性 | EKS 容器组身份不需要用户设置 IAM OIDC 提供者，因此这一限制并不适用。 | 每个 EKS 集群都具有与其关联的 OpenID Connect（OIDC）发布者 URL。要使用 IRSA，需要在 IAM 中为每个 EKS 集群创建一个唯一的 OpenID Connect 提供者。IAM 对每个 AWS 账户的默认全局限制为 100 个 OIDC 提供者。如果计划为每个使用 IRSA 的 AWS 账户设置超过 100 个 EKS 集群，则会达到 IAM OIDC 提供者限制。 |
| 角色可扩展性 | EKS 容器组身份不要求用户在信任策略中定义 IAM 角色和服务账户之间的信任关系，因此这一限制并不适用。 | 在 IRSA 中，您可以在角色的信任策略中定义 IAM 角色和服务账户之间的信任关系。默认情况下，信任策略大小的长度为 `2048`。这意味着您通常可以在单个信任策略中定义 4 个信任关系。虽然您可以增加信任策略长度限制，但单个信任策略中通常最多只能有 8 个信任关系。 |
| STS API 配额使用 | EKS 容器组身份简化了向容器组（pod）交付 AWS 凭证的过程，无需您的代码使用 AWS Security Token Service（STS）直接调用。EKS 服务会处理角色代入，并向在容器组（pod）中使用 AWS SDK 编写的应用程序提供凭证，而无需您的容器组（pod）与 AWS STS 通信或使用 STS API 配额。 | 在 IRSA 中，容器组（pod）中使用 AWS SDK 编写的应用程序会使用令牌在 AWS Security Token Service（STS）上调用 `AssumeRoleWithWebIdentity` API。根据您在 AWS SDK 上的代码逻辑，您的代码可能会对 AWS STS 进行不必要的调用并收到节流错误。 |
| 角色可重用性 | EKS 容器组身份提供的 AWS STS 临时凭证包括角色会话标签，例如集群名称、命名空间、服务账户名称。角色会话标签使管理员能够创建单个 IAM 角色，该角色可用于具有不同有效权限的多个服务账户，方法是允许根据附加到资源的 AWS 标签来访问资源，也称为基于属性的访问权限控制（ABAC）。有关更多信息，请参阅 [基于标签授予容器组（pod）对 AWS 资源的访问权限](pod-id-abac.md)。 | 不支持 AWS STS 会话标签。您可以在集群之间重用角色，但每个容器组都会获得该角色的所有权限。 |
| 支持的环境 | EKS 容器组身份仅在 Amazon EKS 上可用。 | IRSA 可用于 Amazon EKS、Amazon EKS Anywhere、AWS 上的 Red Hat OpenShift 服务，以及 Amazon EC2 实例上的自主管理型 Kubernetes 集群。 |
| 支持的 EKS 版本 | 所有受支持的 EKS 集群版本。有关特定平台版本，请参阅 [EKS 容器组身份集群版本](pod-identities.md#pod-id-cluster-versions)。 | 所有受支持的 EKS 集群版本。 |
# 服务账户的 IAM 角色
**提示**
[注册参加](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)即将举办的 Amazon EKS 讲习会。
容器组（pod）的容器中的应用程序可以使用 AWS SDK 或 AWS CLI 以向使用 AWS Identity and Access Management（IAM）权限的 AWS 服务 发出 API 请求。应用程序必须通过 AWS 凭证签署 AWS API 请求。**服务账户的 IAM 角色（IRSA）**可用于管理供应用程序使用的凭证，这与 Amazon EC2 实例配置文件为 Amazon EC2 实例提供凭证的方式类似。您可以将 IAM 角色与 Kubernetes 服务账户关联并配置容器组（pod）来使用服务账户，而不是创建 AWS 凭证并将其分配到容器或使用 Amazon EC2 实例的角色。您不能将服务账户的 IAM 角色用于 [AWS Outposts 上的 Amazon EKS 本地集群](eks-outposts-local-cluster-overview.md)。
服务账户的 IAM 角色提供下列优势：
+ **最低权限** – 您可以将 IAM 权限范围限定到服务账户，并且只有使用该服务账户的容器组（pod）可以访问这些权限。此功能还消除了对 `kiam` 或 `kube2iam` 等第三方解决方案的需求。
+ **凭证隔离**：当对 [Amazon EC2 实例元数据服务（IMDS）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)的访问受到限制时，容器组的容器只能检索与该容器所使用服务账户关联的 IAM 角色的凭证。容器永远无法访问其他容器组（pod）中其他容器所使用的凭证。如果 IMDS 不受限制，则容器组的容器还可以访问 [Amazon EKS 节点 IAM 角色](create-node-role.md)，并且容器可能能够访问同一节点上其他容器组 IAM 角色的凭证。有关更多信息，请参阅[限制对分配给 Worker 节点的实例配置文件的访问](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations)。
**注意**
配置为 `hostNetwork: true` 的容器组将始终具有 IMDS 访问权限，但 AWS SDK 和 CLI 在启用后将使用 IRSA 凭证。
+ **可审核性** – 可通过 AWS CloudTrail 进行访问和事件日志记录以帮助确保可追溯性审核。
**重要**
容器并非安全边界，使用服务账户的 IAM 角色也不会改变这一点。分配给同一个节点的容器组将共享一个内核，并可能共享其他资源，具体视您的容器组配置而定。虽然在不同节点上运行的容器组将在计算层被隔离，但有些节点应用程序在 Kubernetes API 中拥有超出单个实例范围的额外权限。一些示例包括 `kubelet`、`kube-proxy`、CSI 存储驱动程序或您自己的 Kubernetes 应用程序。
通过完成下列步骤为服务账户启用 IAM 角色：
1. [为集群创建 IAM OIDC 提供者](enable-iam-roles-for-service-accounts.md) – 您只需为集群完成一次此操作。
**注意**
如果启用了 EKS VPC 端点，则无法从该 VPC 内部访问 EKS OIDC 服务端点。因此，您在 VPC 中使用 `eksctl` 创建 OIDC 提供者等操作将不起作用，并且在尝试请求 `https://oidc.eks.region.amazonaws.com` 时将导致超时。错误消息示例如下：
```
server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
```
要完成此步骤，您可以在 VPC 外部运行该命令，例如在 AWS CloudShell 中或在连接到互联网的计算机上。您也可在 VPC 中创建水平分割条件解析器（例如 Route 53 Resolver），以便为 OIDC 发布者 URL 使用不同的解析器，而不对其使用 VPC DNS。有关 CoreDNS 中条件转发的示例，请参阅 GitHub 上的 [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)。
1. [将 IAM 角色分配给 Kubernetes 服务账户](associate-service-account-role.md) – 针对您希望应用程序拥有的每组唯一权限完成此步骤。
1. [将容器组（pod）配置为使用 Kubernetes 服务账户](pod-configuration.md) – 为需要访问 AWS 服务的每个 容器组（pod）完成此过程。
1. [将 IRSA 与 AWS SDK 结合使用](iam-roles-for-service-accounts-minimum-sdk.md) – 确认工作负载使用支持版本的 AWS SDK，并且工作负载使用默认凭证链。
## IAM、Kubernetes 和 OpenID Connect（OIDC）背景信息
2014 年，AWS Identity and Access Management 使用 OpenID Connect（OIDC）增加了对联合身份验证的支持。此功能允许您通过支持的身份提供商对 AWS API 调用进行身份验证，并获得有效的 OIDC JSON Web 令牌 (JWT)。您可以将此令牌传递到 AWS STS `AssumeRoleWithWebIdentity` API 操作并接收 IAM 临时角色凭证。您可以使用这些凭证与任意 AWS 服务交互，包括 Amazon S3 和 DynamoDB。
每个 JWT 令牌均由签名密钥对签名。密钥由 Amazon EKS 管理的 OIDC 提供者提供，私钥每 7 天轮换一次。Amazon EKS 会保留公钥直至其过期。如果您连接外部 OIDC 客户端，请注意您需要在公钥过期之前刷新签名密钥。了解如何[获取签名密钥以验证 OIDC 令牌](irsa-fetch-keys.md)。
Kubernetes 长期以来将服务账户用作其内部身份系统。Pod 可以使用自动装载的令牌（这是非 OIDC JWT，只有 Kubernetes API 服务器可以验证）进行 Kubernetes API 服务器的身份验证。这些旧服务账户令牌不会过期，轮换签名密钥是一个困难的过程。在 Kubernetes `1.12` 版本中，添加了对新 `ProjectedServiceAccountToken` 功能的支持。此功能是 OIDC JSON Web 令牌，包含了服务账户身份，且支持可配置的受众。
Amazon EKS 为包含 `ProjectedServiceAccountToken` JSON Web 令牌的签名密钥的每个集群托管公有 OIDC 发现端点，这样 IAM 等外部系统就可以验证和接收 Kubernetes 颁发的 OIDC 令牌。
# 为集群创建 IAM OIDC 提供商
您的集群具有与其关联的 [OpenID Connect](https://openid.net/connect/)（OIDC）发布者 URL。要将 AWS Identity and Access Management（IAM）角色用于服务账户，您集群的 OIDC 发布者 URL 必须存在 IAM OIDC 提供者。
## 先决条件
+ 现有 Amazon EKS 集群。要部署一个角色，请参阅[开始使用 Amazon EKS](getting-started.md)。
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 包含集群配置的现有 `kubectl` `config` 文件。要创建 `kubectl` `config` 文件，请参阅 [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)。
您可以使用 `eksctl` 或 AWS 管理控制台为集群创建 IAM OIDC 提供者。
## 创建 OIDC 提供者（eksctl）
1. 您的设备或 AWS CloudShell 上安装 `0.215.0` 版或更高版本的 `eksctl` 命令行工具。要安装或更新 `eksctl`，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
1. 确定集群的 OIDC 发布者 ID。
检索集群的 OIDC 发布者 ID 并将其存储在变量中。将 `` 替换为您自己的值。
```
cluster_name=
oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
echo $oidc_id
```
1. 确定账户中是否已存在具有集群发布者 ID 的 IAM OIDC 提供者。
```
aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
```
如果返回了输出，则表示集群已经有 IAM OIDC 提供者，您可以跳过下一步。如果没有返回输出，则您必须为集群创建 IAM OIDC 提供者。
1. 使用以下命令为您的集群创建 IAM OIDC 身份提供商。
```
eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
```
**注意**
如果启用了 EKS VPC 端点，则无法从该 VPC 内部访问 EKS OIDC 服务端点。因此，您在 VPC 中使用 `eksctl` 创建 OIDC 提供者等操作将不起作用，并将导致超时。错误消息示例如下：
```
** server cant find oidc.eks..amazonaws.com: NXDOMAIN
```
要完成此步骤，您可以在 VPC 外部运行该命令，例如在 AWS CloudShell 中或在连接到互联网的计算机上。您也可在 VPC 中创建水平分割条件解析器（例如 Route 53 Resolver），以便为 OIDC 发布者 URL 使用不同的解析器，而不对其使用 VPC DNS。有关 CoreDNS 中条件转发的示例，请参阅 GitHub 上的 [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)。
## 创建 OIDC 提供者（AWS 控制台）
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧窗格中，选择 **Clusters**（集群），然后在 **Clusters**（集群）页面上选择集群的名称。
1. 在 **Overview**（概述）选项卡上的 **Details**（详细信息）部分中，记下 **OpenID Connect provider URL**（OpenID Connect 提供商 URL）的值。
1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。
1. 请在左侧导航窗格中，选择 **Access management**（访问管理）下方的 **Identity Providers**（标识提供程序）。如果列出的 **Provider（提供商）**与集群的 URL 匹配，那么您的集群已经有了提供商。如果未列出与集群 URL 匹配的提供者，则必须创建一个提提供者。
1. 要创建提供商，请选择 **Add Provider**（添加提供商）。
1. 对于**提供者类型**，选择 **OpenID Connect**。
1. 对于**提供者 URL**，输入集群的 OIDC 提供者 URL。
1. 对于**受众**,，输入 `sts.amazonaws.com`。
1. （可选）添加任何标签，例如用于标识哪个集群用于该提供商的标签。
1. 选择**添加提供程序**。
下一步: [为 Kubernetes 服务账户分配 IAM 角色](associate-service-account-role.md)
# 为 Kubernetes 服务账户分配 IAM 角色
本主题介绍如何配置 Kubernetes 服务账户，以担任 AWS Identity and Access Management（IAM）角色。然后，配置为使用服务账户的任何容器组（pod）都可以访问该角色有权访问的任何 AWS 服务。
## 先决条件
+ 现有集群。如果您没有，可以按照[开始使用 Amazon EKS](getting-started.md) 中的指南之一创建一个。
+ 您的集群的现有 IAM OpenID Connect (OIDC) 提供商。要了解您是否已拥有一个（IAM）角色或如何创建一个（IAM）角色，请参阅 [为集群创建 IAM OIDC 提供商](enable-iam-roles-for-service-accounts.md)。
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 包含集群配置的现有 `kubectl` `config` 文件。要创建 `kubectl` `config` 文件，请参阅 [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)。
## 步骤 1：创建 IAM 策略
要将现有 IAM 策略关联到您的 IAM 角色，请跳至下一步。
1. 创建一个 IAM 策略。您可以创建自己的策略，也可以复制已授予您部分所需权限的 AWS 托管策略，并根据您的特定要求对其进行自定义。有关更多信息，请参阅《IAM 用户指南》**中的[创建 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
1. 创建一个文件，其中包含您希望容器组（pod）访问的 AWS 服务所需的权限。有关所有 AWS 服务的所有操作的列表，请参阅[服务授权参考](https://docs.aws.amazon.com/service-authorization/latest/reference/)。
您可以运行以下命令创建一个示例策略文件，以实现对 Amazon S3 存储桶的只读访问权限。您可以选择将配置信息或引导脚本存储在此存储桶中，并且容器组（pod）中的容器可以从存储桶读取文件并将其加载到应用程序中。如果您要创建此示例策略，请将以下内容复制到您的设备。将 *my-pod-secrets-bucket* 替换为您的存储桶名称并运行该命令。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. 创建 IAM 策略。
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
## 步骤 2：创建和关联 IAM 角色
创建 IAM 角色并将其与 Kubernetes 服务账户关联。您可以使用 `eksctl` 或 AWS CLI。
### 创建和关联角色（eksctl）
此 `eksctl` 命令会在指定的命名空间中创建一个 Kubernetes 服务账户，创建具有指定名称的 IAM 角色（如果其不存在），将现有的 IAM 策略 ARN 附加到该角色，并使用 IAM 角色 ARN 为该服务账户添加注释。请务必使用您的具体值替换此命令中的示例占位符值。要安装或更新 `eksctl`，请参阅 `eksctl` 文档中的 [Installation](https://eksctl.io/installation)。
```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
--attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
```
**重要**
如果角色或服务账户已经存在，则之前的命令可能会失败。在这些情况下，`eksctl` 提供不同的选项供您使用。有关更多信息，请运行 `eksctl create iamserviceaccount --help`。
### 创建和关联角色（AWS CLI）
如果您有要担任 IAM 角色的现有 Kubernetes 服务账户，则可跳过此步骤。
1. 创建一个 Kubernetes 服务账户。将以下内容复制到您的设备。将 *my-service-account* 替换为所需的名称，如有必要，将 *default* 替换为其他命名空间。如更改 *default*，则命名空间必须已经存在。
```
cat >my-service-account.yaml <
1. 确认 IAM 角色的信任策略配置正确。
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
示例输出如下。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. 确认您在上一步中附加到角色的策略已附加到该角色。
```
aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
```
示例输出如下。
```
arn:aws:iam::111122223333:policy/my-policy
```
1. 设置一个变量以存储要使用策略的 Amazon 资源名称（ARN）。将 *my-policy* 替换为要确认其权限的策略的名称。
```
export policy_arn=arn:aws:iam::111122223333:policy/my-policy
```
1. 查看该策略的默认版本。
```
aws iam get-policy --policy-arn $policy_arn
```
示例输出如下。
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws:iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. 查看策略内容以确保该策略包含容器组（pod）所需的所有权限。如有必要，将以下命令中的 *1* 替换为上一个输出中返回的版本。
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
示例输出如下。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
如果您在上一步中创建了示例策略，则您的输出与示例相同。如果您创建了其他策略，则与*示例*内容不同。
1. 确认已使用角色为 Kubernetes 服务账户添加注释。
```
kubectl describe serviceaccount my-service-account -n default
```
示例输出如下。
```
Name: my-service-account
Namespace: default
Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
Image pull secrets:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## 后续步骤
+ [配置容器组（pod）使用 Kubernetes 服务账户](pod-configuration.md)
# 配置容器组（pod）使用 Kubernetes 服务账户
如果容器组（pod）需要访问 AWS 服务，则必须配置它来使用 Kubernetes 服务账户。服务账户必须关联到有权访问 AWS 服务的 AWS Identity and Access Management（IAM）角色。
+ 现有集群。如果还没有，可以使用[开始使用 Amazon EKS](getting-started.md) 中的指南之一创建一个。
+ 您的集群的现有 IAM OpenID Connect (OIDC) 提供商。要了解您是否已拥有一个（IAM）角色或如何创建一个（IAM）角色，请参阅 [为集群创建 IAM OIDC 提供商](enable-iam-roles-for-service-accounts.md)。
+ 与 IAM 角色关联的现有 Kubernetes 服务账户。必须使用 IAM 角色的 Amazon 资源名称（ARN）注释服务账户。该角色必须具有关联的 IAM 策略，其中包含您希望容器组（pod）必须具有的权限，以便使用 AWS 服务。有关如何创建和配置服务账户和角色的更多信息，请参阅 [为 Kubernetes 服务账户分配 IAM 角色](associate-service-account-role.md)。
+ 在您的设备或 AWS CloudShell 上安装和配置 AWS 命令行界面（AWS CLI）的版本 `2.12.3` 或更高版本，或版本 `1.27.160` 或更高版本。要查看当前版本，请使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1`。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》**中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》**中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 包含集群配置的现有 `kubectl` `config` 文件。要创建 `kubectl` `config` 文件，请参阅 [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)。
1. 使用以下命令创建部署清单，您可以使用该部署清单部署容器组（pod）来确认配置。将示例值替换为您自己的值。
```
cat >my-deployment.yaml <
如果将 Kubernetes 服务账户与[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)结合使用，则可配置服务账户使用的 AWS Security Token Service 端点类型。
AWS 建议使用区域 AWS STS 端点而不是全局端点。这可以减少延迟，提供内置冗余并提高会话令牌的有效性。AWS Security Token Service 必须在容器组（pod）运行的 AWS 区域处于活动状态。此外，您的应用程序必须内置冗余功能，以便在该 AWS 区域的服务出现故障时选择其它 AWS 区域。有关更多信息，请参阅《IAM 用户指南》中的[在 AWS 区域中管理 AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)。
+ 现有集群。如果还没有，可以使用 [开始使用 Amazon EKS](getting-started.md) 中的指南之一创建一个。
+ 集群的现有 IAM OIDC 提供商。有关更多信息，请参阅 [为集群创建 IAM OIDC 提供商](enable-iam-roles-for-service-accounts.md)。
+ 现有的 Kubernetes 服务账户配置为与[适用于服务账户的 Amazon EKS IAM](iam-roles-for-service-accounts.md) 功能结合使用。
以下示例全部使用 [Amazon VPC CNI 插件](cni-iam-role.md)所使用的 aws-node Kubernetes 服务账户。可将*示例值*替换为您自己的服务账户、容器组（pod）、命名空间和其他资源。
1. 选择一个使用要更改其端点的服务账户的容器组（pod）。确定容器组（pod）在其中运行的 AWS 区域。将 *aws-node-6mfgv* 替换为容器组（pod）的名称，并将 *kube-system* 替换为容器组（pod）的命名空间。
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
```
示例输出如下。
```
ip-192-168-79-166.us-west-2/192.168.79.166
```
在之前的输出中，容器组（pod）在 us-west-2 AWS 区域中的节点上运行。
1. 确定容器组（pod）的服务账户使用的端点类型。
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
示例输出如下。
```
AWS_STS_REGIONAL_ENDPOINTS: regional
```
如果当前端点是全局端点，则输出中将返回 `global`。如果没有返回输出，则默认端点类型正在使用中且尚未被覆盖。
1. 如果您的集群或平台版本与表中列出的版本相同或晚于该版本，则可以使用以下命令之一将服务账户使用的端点类型从默认类型更改为其他类型。将 *aws-node* 替换为您的服务账户的名称，并将 *kube-system* 替换为您的服务账户的命名空间。
+ 如果您的默认或当前端点类型为全局端点类型，并且您想将其更改为区域性端点：
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
```
如果您使用[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)，在容器组（pod）的容器中运行的应用程序中生成预签名 S3 URL，则区域端点的 URL 格式与以下示例类似：
```
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
+ 如果您的默认或当前端点类型为区域性端点类型，并且您想将其更改为全局性端点：
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
```
如果您的应用程序明确向 AWS STS 全局端点提出请求，且您不会覆盖在 Amazon EKS 集群中使用区域端点的默认行为，则请求将失败，并出现错误。有关更多信息，请参阅 [容器组（pod）容器收到以下错误：`An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint)。
如果您使用[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)，在容器组（pod）的容器中运行的应用程序中生成预签名 S3 URL，则全局端点的 URL 格式与以下示例类似：
```
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
如果您的自动化需要特定格式的预签名 URL，或者如果您的应用程序或使用预签名 URL 的下游依赖关系对目标 AWS 区域有期望，则进行必要的更改以使用适当的 AWS STS 端点。
1. 删除并重新创建任何与服务账户关联的现有容器组（pod），以应用凭证环境变量。变更 Webhook 不会将其应用到已经在运行的容器组（pod）。您可以将 *Pods*、*kube-system* 和 *-l k8s-app=aws-node* 替换为设置注释的容器组（pod）信息。
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. 确认容器组（pod）已全部重新启动。
```
kubectl get Pods -n kube-system -l k8s-app=aws-node
```
1. 查看其中一个容器组（pod）的环境变量。验证 `AWS_STS_REGIONAL_ENDPOINTS` 值是您在上一步中将其设置的值。
```
kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
示例输出如下。
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
# 使用 IRSA 对另一个账户进行身份验证
您可以通过从其它账户的集群创建身份提供者或者使用链接的 `AssumeRole` 操作，配置跨账户 IAM 权限。在以下示例中，*账户 A* 拥有一个支持服务账户的 IAM 角色的 Amazon EKS 集群。在该集群上运行的容器组（pod）需要承担来自*账户 B* 的 IAM 权限。
+ **选项 1** 更简单，但需要账户 B 为账户 A 的集群创建和管理 OIDC 身份提供程序。
+ **选项 2 将** OIDC 管理保留在账户 A 中，但需要通过两次 `AssumeRole` 调用进行角色链式操作。
## 从其它账户的集群创建身份提供程序
在此示例中，账户 A 从其集群向账户 B 提供 OpenID Connect（OIDC）颁发者 URL。账户 B 遵循[为集群创建 IAM OIDC 提供者](enable-iam-roles-for-service-accounts.md)和[为 Kubernetes 服务账户分配 IAM 角色](associate-service-account-role.md)中的说明，使用来自账户 A 集群的 OIDC 发布者 URL。然后，集群管理员注释账户 A 的集群中的服务账户以使用来自账户 B 的角色（*444455556666*）。
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```
## 选项 2：使用链式 `AssumeRole` 操作
在此方案中，每个账户创建一个 IAM 角色。账户 B 的角色信任账户 A，账户 A 的角色使用 OIDC 联合身份验证从集群获取凭证。然后，容器组（pod）使用 AWS CLI 配置文件将这两个角色链接在一起。
### 步骤 1：在账户 B 中创建目标角色
账户 B（*444455556666*）创建一个 IAM 角色，该角色具有账户 A 集群中容器组（pod）所需的权限。账户 B 将所需权限策略附加到此角色，然后添加以下信任策略。
**账户 B 角色的信任策略**–该策略允许账户 A 的特定 IRSA 角色承担此角色。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**重要**
为遵循最低权限原则，请将 `Principal` ARN 替换为账户 A 中的特定角色 ARN，而不是使用账户根（`arn:aws:iam::111122223333:root`）。使用账户根将允许账户 A 中的*任何* IAM 主体承担此角色。
### 步骤 2：在账户 A 中创建 IRSA 角色
账户 A （*111122223333*）创建具有信任策略的角色，该策略从使用集群的 OIDC 颁发者地址创建的身份提供者处获取凭证。
**账户 A 角色的信任策略（OIDC 联合联合身份验证）**–该策略允许 EKS 集群的 OIDC 提供程序为此角色颁发凭证。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**重要**
为遵循最低权限原则，请为 `sub` 声明添加 `StringEquals` 条件，以将此角色限定给特定的 Kubernetes 服务账户。在没有 `sub` 条件的情况下，集群中的任何服务账号都可以担任此角色。`sub` 值的格式为 `system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `。例如，要将范围限定为 `default` 命名空间中名为 `my-service-account` 的服务账户：
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### 步骤 3：将 AssumeRole 权限附加到账户 A 的角色
账户 A 将为步骤 2 中创建的角色附加一个权限策略。该策略允许该角色承担账户 B 的角色。
**账户 A 角色的权限策略**–该策略授予对账户 B 目标角色的 `sts:AssumeRole` 权限。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### 步骤 4：配置容器组（pod）以链式使用角色
容器组（pod）的应用程序代码使用两个配置文件担任账户 B 的角色：`account_b_role` 和 `account_a_role`。`account_b_role` 配置文件使用 `account_a_role` 配置文件作为其源。对于 AWS CLI，`~/.aws/config` 文件类似于以下内容。
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam::111122223333:role/account-a-role
```
要为其它 AWS SDK 指定链接的配置文件，请参考所使用 SDK 的文档。有关更多信息，请参阅[用于在 AWS 上进行构建的工具](https://aws.amazon.com/developer/tools/)。
# 将 IRSA 与 AWS SDK 结合使用
**使用凭证**
要使用服务账户的 IAM 角色（IRSA）凭证，代码可以使用任何 AWS SDK 为具有 SDK 的 AWS 服务创建客户端。默认情况下，SDK 会在一系列位置中搜索要使用的 AWS Identity and Access Management 凭证。如果您在创建客户端或者初始化 SDK 时未指定凭证提供程序，则将使用服务账户凭证的 IAM 角色。
由于服务账户的 IAM 角色已添加为默认凭证链中的一个步骤，因此该操作可行。如果您的工作负载当前使用凭证链中较早的证书，则即使您为同一工作负载的服务账户配置了 IAM 角色，这些凭证也将继续使用。
SDK 使用 `AssumeRoleWithWebIdentity` 操作自动将服务账户 OIDC 令牌交换为 AWS Security Token Service 中的临时凭证。Amazon EKS 和此 SDK 操作会在临时凭证到期前进行续订，从而继续轮换临时凭证。
在使用[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)时，容器组（pod）中的容器必须使用支持通过 OpenID Connect Web 身份令牌文件担任 IAM 角色的 AWS SDK 版本。请确保为您的 AWS SDK 使用以下版本或更高版本：
+ Java（版本 2）– [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11)
+ Java – [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782)
+ AWS SDK for Go v1 – [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13)
+ AWS SDK for Go v2 – 所有版本均支持
+ Python (Boto3) – [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220)
+ Python (botocore) – [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200)
+ AWS CLI – [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232)
+ 节点：[2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) 和 [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0)
+ Ruby – [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01)
+ C\$1\$1 – [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174)
+ .NET：[3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1)，您必须还包括 `AWSSDK.SecurityToken`。
+ PHP – [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7)
许多流行的 Kubernetes 附加组件（例如 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)、[使用 AWS 负载均衡器控制器的路由互联网流量](aws-load-balancer-controller.md)和[适用于 Kubernetes 的 Amazon VPC CNI 插件](cni-iam-role.md)）支持服务账户的 IAM 角色。
为了确保您使用的是受支持的 SDK，请在构建容器时按照[用于在 AWS 上进行构建的工具](https://aws.amazon.com/tools/)中针对您的首选 SDK 的安装说明操作。
## 注意事项
### Java
使用 Java 时，*必须*在类路径中包括 `sts` 模块。有关更多信息，请参阅 Java SDK 文档中的 [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html)。
# 获取签名密钥以验证 OIDC 令牌
Kubernetes 向每个 Kubernetes 服务账户发放一个 `ProjectedServiceAccountToken`。此令牌是一个 OIDC 令牌，更是一种 JSON Web 令牌（JWT）。Amazon EKS 为包含令牌的签名密钥的每个集群托管公有 OIDC 端点，这样外部系统就可以验证。
您需要获取 OIDC 公有签名密钥 [又称 JSON Web 密钥集（简称 JWKS）] 才能验证 `ProjectedServiceAccountToken`。在应用程序中使用这些密钥来验证令牌。例如，您可以使用 [PyJWT Python 库](https://pyjwt.readthedocs.io/en/latest/)来验证使用这些密钥的令牌。有关 `ProjectedServiceAccountToken` 的更多信息，请参阅 [IAM、Kubernetes 和 OpenID Connect（OIDC）背景信息](iam-roles-for-service-accounts.md#irsa-oidc-background)。
## 先决条件
+ 适用于集群的现有 AWS Identity and Access Management（IAM）OpenID Connect（OIDC）提供者。要确定您是否已经拥有一个或是否要创建一个，请参阅[为集群创建 IAM OIDC 提供商](enable-iam-roles-for-service-accounts.md)。
+ **AWS CLI** – 与 AWS 服务（包括 Amazon EKS）结合使用的命令行工具。有关更多信息，请参阅《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。在安装 AWS CLI 后，建议您还要对其进行配置。有关更多信息，请参阅《AWS 命令行界面用户指南》中的[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。
## 过程
1. 使用 AWS CLI 检索适用于 Amazon EKS 集群的 OIDC URL。
```
$ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
"https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
```
1. 使用 curl 或类似工具检索公有签名密钥。结果是 [JSON Web 密钥集（JWKS）](https://www.rfc-editor.org/rfc/rfc7517#section-5)。
**重要**
Amazon EKS 会限制对 OIDC 端点的调用。您应该缓存公共签名密钥。请遵守响应中包含的 `cache-control` 标题。
**重要**
Amazon EKS 每七天轮换一次 OIDC 签名密钥。
```
$ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
{"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
```
# 了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限
容器组（pod）的容器中的应用程序可以使用 AWS SDK 或 AWS CLI 以向使用 AWS Identity and Access Management（IAM）权限的 AWS 服务 发出 API 请求。应用程序必须通过 AWS 凭证签署 AWS API 请求。
*Amazon EKS 容器组身份*提供管理应用程序凭证的功能，类似于 Amazon EC2 实例配置文件为 Amazon EC2 实例提供凭证的方式。您可以将 IAM 角色与 Kubernetes 服务账户关联并配置容器组（pod）来使用服务账户，而不是创建 AWS 凭证并将其分配到容器或使用 Amazon EC2 实例的角色。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
每个 EKS 容器组身份关联都将角色映射到指定集群命名空间中的服务账户。如果您在多个集群中使用相同的应用程序，则可以在每个集群中进行相同的关联，而无需修改角色的信任策略。
如果某个容器组使用具有关联的服务账户，Amazon EKS 会在容器组的容器中设置环境变量。环境变量配置 AWS SDK（包括 AWS CLI）使用 EKS 容器组身份凭证。
## EKS 容器组身份的优势
EKS 容器组身份具有以下优势：
+ **最低权限** – 您可以将 IAM 权限范围限定到服务账户，并且只有使用该服务账户的容器组（pod）可以访问这些权限。此功能还消除了对 `kiam` 或 `kube2iam` 等第三方解决方案的需求。
+ **凭证隔离**：当对 [Amazon EC2 实例元数据服务（IMDS）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)的访问受到限制时，容器组的容器只能检索与该容器所使用服务账户关联的 IAM 角色的凭证。容器永远无法访问其他容器组（pod）中其他容器所使用的凭证。如果 IMDS 不受限制，则容器组的容器还可以访问 [Amazon EKS 节点 IAM 角色](create-node-role.md)，并且容器可能能够访问同一节点上其他容器组 IAM 角色的凭证。有关更多信息，请参阅[限制对分配给 Worker 节点的实例配置文件的访问](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations)。
**注意**
配置为 `hostNetwork: true` 的容器组将始终具有 IMDS 访问权限，但 AWS SDK 和 CLI 在启用后将使用容器组身份凭证。
+ **可审计性** – 可通过 AWS CloudTrail 进行访问和事件日志记录，帮助确保追溯性审计。
**重要**
容器并非安全边界，使用任务容器组身份也不能改变这一点。分配给同一个节点的容器组将共享一个内核，并可能共享其他资源，具体视您的容器组配置而定。虽然在不同节点上运行的容器组将在计算层被隔离，但有些节点应用程序在 Kubernetes API 中拥有超出单个实例范围的额外权限。一些示例包括 `kubelet`、`kube-proxy`、CSI 存储驱动程序或您自己的 Kubernetes 应用程序。
EKS 容器组身份是一种比 [服务账户的 IAM 角色](iam-roles-for-service-accounts.md) 更简单的方法，因为此方法不使用 OIDC 身份提供者。EKS 容器组身份具有以下增强功能：
+ **独立操作**：在许多组织中，不同的团队负责创建 OIDC 身份提供者，而不是管理 Kubernetes 集群。EKS 容器组身份有明确的职责分工，EKS 容器组身份关联的所有配置都在 Amazon EKS 中完成，而 IAM 权限的所有配置都在 IAM 中完成。
+ **可重用性**：EKS 容器组身份使用单个 IAM 主体，而不是服务账户 IAM 角色使用的每个集群的单独主体。IAM 管理员将以下主体添加到任何角色的信任策略中，使其可供 EKS 容器组身份使用。
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **可扩展性**：每组临时凭证均由 EKS 容器组身份中的 EKS Auth 服务使用，而不是由每个容器组（pod）中运行的每个 AWS SDK 使用。然后，在每个节点上运行的 Amazon EKS 容器组身份代理向 SDK 发放凭证。因此，每个节点的负载减少至一次，而且不会在每个容器组中重复。有关该过程的更多详细信息，请参阅 [了解 EKS 容器组身份的工作原理](pod-id-how-it-works.md)。
有关比较两种替代方案的更多信息，请参阅 [使用 Kubernetes 服务账户授予 Kubernetes 工作负载访问 AWS 的权限](service-accounts.md)。
## EKS 容器组身份设置概述
完成以下过程，打开 EKS 容器组身份：
1. [设置 Amazon EKS 容器组身份代理](pod-id-agent-setup.md) – 对于每个集群，您只需完成一次此步骤。如果您的集群启用了 EKS 自动模式，则无需完成此步骤。
1. [向 Kubernetes 服务账户分配 IAM 角色](pod-id-association.md) – 针对您希望应用程序拥有的每组唯一权限完成此步骤。
1. [配置容器组（pod）使用服务账户访问 AWS 服务](pod-id-configure-pods.md)：为需要访问 AWS 服务的每个容器组（pod）完成此步骤。
1. [将容器组身份与 AWS SDK 结合使用](pod-id-minimum-sdk.md) – 确认工作负载使用支持版本的 AWS SDK，并且工作负载使用默认凭证链。
## 限制
+ 每个集群最多支持 5000 个 EKS 容器组身份关联，用于将 IAM 角色映射到 Kubernetes 服务账户。
## 注意事项
+ **IAM 角色关联**：集群中的每个 Kubernetes 服务账户都可以与集群相同的 AWS 账户中的一个 IAM 角色相关联。要更改该角色，请编辑 EKS 容器组身份关联。要进行跨账户访问，请使用 IAM 角色向该角色委派访问权限。要了解更多信息，请参阅《IAM 用户指南》**中的[使用 IAM 角色委托跨 AWS 账户的访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)。
+ **EKS 容器组身份代理**：使用 EKS 容器组身份需要 EKS 容器组身份代理。该代理作为 Kubernetes `DaemonSet` 在集群节点上运行，仅向同一节点上的容器组提供凭证。其使用节点的 `hostNetwork`，占用链路本地地址上的端口 `80` 和 `2703`（IPv4 为 `169.254.170.23`，IPv6 为 `[fd00:ec2::23]`）。如果您的集群中禁用 IPv6，则请为容器组身份代理禁用 IPv6。要了解更多信息，请参阅[在 EKS 容器组身份代理中禁用 IPv6](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html)。
+ **最终一致性**：EKS 容器组身份关联最终保持一致，API 调用后可能会有几秒钟的延迟。避免在关键的高可用性代码路径中创建或更新关联。相反，应在单独的、不太频繁的初始化或设置例程中执行这些操作。要了解更多信息，请参阅《EKS Best Practices Guide》**中的 [Security Groups Per Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html)。
+ **代理和安全组注意事项**：对于使用代理的容器组，请将 `169.254.170.23`（IPv4）和 `[fd00:ec2::23]`（IPv6）添加到 `no_proxy/NO_PROXY` 环境变量，以防止对 EKS 容器组身份代理的请求失败。如果容器组的安全组与 AWS VPC CNI 一起使用，则请将 `ENABLE_POD_ENI` 标志设置为“true”，`POD_SECURITY_GROUP_ENFORCING_MODE` 标志设置为“standard”。要了解更多信息，请参阅[将安全组分配给各个容器组](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html)。
### EKS 容器组身份集群版本
要使用 EKS 容器组身份，集群的平台版本必须与下表中所列的版本相同或更高，或者 Kubernetes 版本必须比下表中所列的版本更高。要查找适用于 Kubernetes 版本的建议 Amazon EKS 容器组身份代理版本，请参阅[验证 Amazon EKS 附加组件版本与集群的兼容性](addon-compat.md)。
| Kubernetes 版本 | 平台版本 |
| --- | --- |
| 未列出 Kubernetes 版本 | 支持所有平台版本 |
| `1.28` | `eks.4` |
### EKS 容器组身份限制
EKS 容器组身份适用于：
+ 上一个主题 [EKS 容器组身份集群版本](#pod-id-cluster-versions) 中列出的 Amazon EKS 集群版本。
+ 集群中属于 Linux Amazon EC2 实例的 Worker 节点。
EKS 容器组身份不适用于：
+ AWS Outposts。
+ Amazon EKS Anywhere。
+ 您在 Amazon EC2 上创建和运行的 Kubernetes 集群。EKS 容器组身份组件仅在 Amazon EKS 上可用。
您不能将 EKS 容器组身份用于：
+ 在 Linux Amazon EC2 实例之外的任何位置运行的容器组。不支持在 AWS Fargate（Fargate）上运行的 Linux 和 Windows 容器组。不支持 Windows Amazon EC2 实例上运行的容器组。
# 了解 EKS 容器组身份的工作原理
Amazon EKS 容器组身份关联提供管理应用程序凭证的功能，类似于 Amazon EC2 实例配置文件为 Amazon EC2 实例提供凭证的方式。
Amazon EKS 容器组身份通过额外的 *EKS Auth* API，以及在每个节点上运行的代理容器组为您的工作负载提供凭证。
在您的插件中，例如，*Amazon EKS 插件*和自我管理控制器、运算符和其他插件，创建者需要更新软件才能使用最新的 AWS SDK。有关 EKS 容器组身份与 Amazon EKS 插件之间的兼容性列表，请参阅上一节 [EKS 容器组身份限制](pod-identities.md#pod-id-restrictions)。
## 在代码中使用 EKS 容器组身份
在您的代码中，您可以使用 AWS SDK 访问 AWS 服务。您可以编写代码，为使用 SDK 的 AWS 服务创建客户端，默认情况下，SDK 会在一系列位置中搜索要使用的 AWS Identity and Access Management 凭证。找到有效凭证后，搜索停止。有关使用的默认位置的更多信息，请参阅《AWS SDK 和工具参考指南》中的[凭证提供程序链](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)。
EKS 容器组身份已添加到*容器凭证提供程序*，可在默认凭证链的一个步骤中搜索。如果您的工作负载当前使用凭证链中较早的证书，则即使您为同一工作负载配置了 EKS 容器组身份关联，这些凭证也将继续使用。这样，在删除旧凭证之前，您可以先创建关联，从而安全地从其他类型的凭证迁移。
容器凭证提供程序从每个节点上运行的代理处提供临时凭证。在 Amazon EKS 中，代理是 Amazon EKS 容器组身份，而在 Amazon Elastic Container Service 中，代理则是 `amazon-ecs-agent`。SDK 使用环境变量来定位要连接的代理。
相比之下，*服务账户的 IAM 角色*提供了一个 *Web 身份*令牌，AWS SDK 必须使用 `AssumeRoleWithWebIdentity` 与 AWS Security Token Service 进行交换。
## EKS 容器组身份代理如何使用容器组（pod）
1. 当 Amazon EKS 启动一个新的容器组（pod），而该容器组使用与 EKS 容器组身份关联的服务账户时，集群将添加以下内容到容器组清单中：
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. Kubernetes 选择要在哪个节点上运行容器组（pod）。然后，节点上的 Amazon EKS 容器组身份代理使用 [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) 操作从 EKS Auth API 检索临时凭证。
1. EKS 容器组身份代理可为在容器中运行的 AWS SDK 提供这些凭证。
1. 在应用程序中使用 SDK 时，无需指定凭证提供程序使用默认凭证链。或者，您可以指定容器凭证提供程序。有关使用的默认位置的更多信息，请参阅《AWS SDK 和工具参考指南》中的[凭证提供程序链](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)。
1. SDK 使用环境变量连接到 EKS 容器组身份代理并检索凭证。
**注意**
如果您的工作负载当前使用凭证链中较早的证书，则即使您为同一工作负载配置了 EKS 容器组身份关联，这些凭证也将继续使用。
# 设置 Amazon EKS 容器组身份代理
Amazon EKS 容器组身份关联提供管理应用程序凭证的功能，类似于 Amazon EC2 实例配置文件为 Amazon EC2 实例提供凭证的方式。
Amazon EKS 容器组身份通过额外的 *EKS Auth* API，以及在每个节点上运行的代理容器组为您的工作负载提供凭证。
**提示**
您无需在 EKS 自动模式集群上安装 EKS 容器组身份代理。此功能已内置在 EKS 自动模式中。
## 注意事项
+ 默认情况下，EKS 容器组身份代理预安装在 EKS 自动模式集群上。要了解更多信息，请参阅[使用 EKS 自动模式实现集群基础设施自动化](automode.md)。
+ 默认情况下，EKS 容器组身份代理会侦听 `IPv4` 和 `IPv6` 地址，以便为容器组请求凭证。对于 `IPv4`，代理会使用环回（本地主机）IP 地址 `169.254.170.23`，对于 `IPv6`，则会使用本地主机 IP 地址 `[fd00:ec2::23]`。
+ 如果禁用 `IPv6` 地址或以其它方式阻止本地主机 `IPv6` IP 地址，代理将无法启动。要在无法使用 `IPv6` 的节点上启动代理，请按照 [在 EKS 容器组身份代理中禁用 `IPv6`](pod-id-agent-config-ipv6.md) 中的步骤禁用 `IPv6` 配置。
## 创建 Amazon EKS 容器组身份代理
### 代理先决条件
+ 现有 Amazon EKS 集群。要部署一个角色，请参阅[开始使用 Amazon EKS](getting-started.md)。集群版本和平台版本必须与 [EKS 容器组身份集群版本](pod-identities.md#pod-id-cluster-versions)中列出的版本相同或更高。
+ 节点角色有权让代理在 EKS Auth API 中执行 `AssumeRoleForPodIdentity` 操作。您可以使用 [AWS 托管式策略：AmazonEKSWorkerNodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy)，或添加类似如下的自定义策略：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
可通过标签来限制此操作，以限制使用代理的容器组可以分派哪些角色。
+ 节点可以访问 Amazon ECR 并从中下载映像。该附加组件的容器映像位于[查看 Amazon EKS 附加组件的 Amazon 容器映像注册表](add-ons-images.md)中列出的注册表中。
请注意，您可以在 AWS 管理控制台 中的**可选配置设置**，以及 AWS CLI 中的 `--configuration-values` 更改映像位置并为 EKS 附加组件提供 `imagePullSecrets`。
+ 节点可以访问 Amazon EKS Auth API。对于私有集群，AWS PrivateLink 中的 `eks-auth` 端点是必需的。
### 使用 AWS 控制台设置代理
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧导航窗格中，选择**集群**，然后为您要配置 EKS 容器组身份代理插件的集群选择集群名称。
1. 选择**附加组件**选项卡。
1. 选择**获取更多附加组件**。
1. 选择 EKS 容器组身份代理插件框右上角的框，然后选择**下一步**。
1. 在**配置选定插件设置**页面上，从**版本**下拉列表中选择任意版本。
1. （可选）展开**可选配置设置**以输入其他配置。例如，您可以提供备用容器映像位置和 `ImagePullSecrets`。带有已接受键的 JSON 架构显示在**附加组件配置架构**中。
在**配置值**中输入配置键和值。
1. 选择**下一步**。
1. 确认 EKS 容器组身份代理容器组正在您的集群上运行。
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
示例输出如下。
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
现在，您可以在集群中使用 EKS 容器组身份关联。有关更多信息，请参阅 [向 Kubernetes 服务账户分配 IAM 角色](pod-id-association.md)。
### 使用 AWS CLI 设置代理
1. 运行以下 AWS CLI 命令。将 `my-cluster` 替换为您的集群名称。
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**注意**
EKS 容器组身份代理不将 `service-account-role-arn` 用于*服务账户的 IAM 角色*。您必须为 EKS 容器组身份代理提供节点角色的权限。
1. 确认 EKS 容器组身份代理容器组正在您的集群上运行。
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
示例输出如下。
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
现在，您可以在集群中使用 EKS 容器组身份关联。有关更多信息，请参阅 [向 Kubernetes 服务账户分配 IAM 角色](pod-id-association.md)。
# 向 Kubernetes 服务账户分配 IAM 角色
本主题介绍如何配置 Kubernetes 服务账户，以便使用 EKS 容器组身份担任 AWS Identity and Access Management（IAM）角色。然后，配置为使用服务账户的任何容器组（pod）都可以访问该角色有权访问的任何 AWS 服务。
要创建 EKS 容器组身份关联，只需一步；您可以通过 AWS 管理控制台、AWS CLI、AWS SDK、AWS CloudFormation，以及其它工具在 EKS 中创建关联。任何 Kubernetes 对象中都没有关于集群内关联的任何数据或元数据，也不需要向服务账户添加任何注释。
**先决条件**
+ 现有集群。如果您没有，可以按照[开始使用 Amazon EKS](getting-started.md) 中的指南之一创建一个。
+ 创建关联的 IAM 主体必须具有 `iam:PassRole`。
+ 在您的设备或 AWS CLI 上安装和配置的最新版本 AWS CloudShell。您可以使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1` 检查您的当前版本。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 包含集群配置的现有 `kubectl` `config` 文件。要创建 `kubectl` `config` 文件，请参阅 [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)。
## 创建容器组身份关联（AWS 控制台）
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧导航窗格中，选择**集群**，然后为您要配置 EKS 容器组身份代理插件的集群选择集群名称。
1. 选择**访问**选项卡。
1. 在**容器组身份关联**中，选择**创建**。
1. 对于 **IAM 角色**，选择具有工作负载所需权限的 IAM 角色。
**注意**
该列表仅包含具有以下信任策略的角色，该策略允许 EKS 容器组身份使用这些角色。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole` – 在将临时凭证传递给您的容器组之前，EKS 容器组身份使用 `AssumeRole` 分派 IAM 角色。
`sts:TagSession` – EKS 容器组身份使用 `TagSession` 在对 AWS STS 的请求中包含*会话标签*。
您可以在信任策略的*条件键*中使用这些标签，来限制哪些服务账户、命名空间和集群可以使用此角色。
有关 Amazon EKS 条件键的列表，请参阅《Service Authorization Reference》**中的 [Conditions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)。要了解您可以对哪些操作和资源使用条件键，请参阅 [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。
1. 对于 **Kubernetes 命名空间**，选择包含服务账户和工作负载的 Kubernetes 命名空间。或者，您可以按名称指定集群中不存在的命名空间。
1. 对于 **Kubernetes 服务账户**，选择要使用的 Kubernetes 服务账户。Kubernetes 工作负载清单必须指定此服务账户。或者，您可以按名称指定集群中不存在的服务账户。
1. （可选）选择**禁用会话标签**以禁用容器组身份在担任角色时自动添加的默认会话标签。
1. （可选）切换**配置会话策略**，以配置 IAM 策略，以便对这个容器组身份关联施加超出附加到 IAM 角色的 IAM 策略所定义权限的额外限制。
**注意**
只有在**禁用会话标签**设置被选中的情况下，才能应用会话策略。
1. （可选）对于**标签**，选择**添加标签**以在键值对中添加元数据。这些标签将应用于关联，并可在 IAM 策略中使用。
您可以重复此步骤以添加多个标签。
1. 选择**创建**。
## 创建容器组身份关联（AWS CLI）
1. 要将现有 IAM 策略关联到您的 IAM 角色，请跳至下一步。
创建一个 IAM 策略。您可以创建自己的策略，也可以复制已授予您部分所需权限的 AWS 托管策略，并根据您的特定要求对其进行自定义。有关更多信息，请参阅《IAM 用户指南》**中的[创建 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
1. 创建一个文件，其中包含您希望容器组（pod）访问的 AWS 服务所需的权限。有关所有 AWS 服务的所有操作的列表，请参阅[服务授权参考](https://docs.aws.amazon.com/service-authorization/latest/reference/)。
您可以运行以下命令创建一个示例策略文件，以实现对 Amazon S3 存储桶的只读访问权限。您可以选择将配置信息或引导脚本存储在此存储桶中，并且容器组（pod）中的容器可以从存储桶读取文件并将其加载到应用程序中。如果您要创建此示例策略，请将以下内容复制到您的设备。将 *my-pod-secrets-bucket* 替换为您的存储桶名称并运行该命令。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. 创建 IAM 策略。
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
1. 创建 IAM 角色并将其与 Kubernetes 服务账户关联。
1. 如果您有要担任 IAM 角色的现有 Kubernetes 服务账户，则可跳过此步骤。
创建一个 Kubernetes 服务账户。将以下内容复制到您的设备。将 *my-service-account* 替换为所需的名称，如有必要，将 *default* 替换为其他命名空间。如更改 *default*，则命名空间必须已经存在。
```
cat >my-service-account.yaml <
1. 确认 IAM 角色的信任策略配置正确。
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
示例输出如下。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. 确认您在上一步中附加到角色的策略已附加到该角色。
```
aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
```
示例输出如下。
```
arn:aws:iam::111122223333:policy/my-policy
```
1. 设置一个变量以存储要使用策略的 Amazon 资源名称（ARN）。将 *my-policy* 替换为要确认其权限的策略的名称。
```
export policy_arn=arn:aws:iam::111122223333:policy/my-policy
```
1. 查看该策略的默认版本。
```
aws iam get-policy --policy-arn $policy_arn
```
示例输出如下。
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws:iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. 查看策略内容以确保该策略包含容器组（pod）所需的所有权限。如有必要，将以下命令中的 *1* 替换为上一个输出中返回的版本。
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
示例输出如下。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
如果您在上一步中创建了示例策略，则您的输出与示例相同。如果您创建了其他策略，则与*示例*内容不同。
## 后续步骤
[配置容器组（pod）使用服务账户访问 AWS 服务](pod-id-configure-pods.md)
# 使用 EKS 容器组身份目标 IAM 角色访问 AWS 资源
在 Amazon Elastic Kubernetes Service（Amazon EKS）上运行应用程序时，您可能需要访问位于不同 AWS 账户中的 AWS 资源。本指南向您介绍如何使用 EKS 容器组身份设置跨账户访问，以便 Kubernetes 容器组（pod）能够使用目标角色访问其他 AWS 资源。
## 先决条件
在开始之前，请确保您已完成以下步骤：
+ [设置 Amazon EKS 容器组身份代理](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [创建 EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## 工作方式
容器组身份通过名为角色链的流程，使 EKS 集群中的应用程序能够跨账户访问 AWS 资源。
创建容器组身份关联时，可以提供两个 IAM 角色：一个是与 EKS 集群位于同一账户的 [EKS 容器组（pod）身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)，另一个是包含您希望访问的 AWS 资源（例如 S3 存储桶或 RDS 数据库）的账户中的目标 IAM 角色。因 [IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) 要求，[EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)必须位于 EKS 集群所在账户中，而目标 IAM 角色可以位于任何 AWS 账户中。PassRole 允许 AWS 实体将角色代入委派给其他服务。EKS 容器组身份通过 PassRole 将角色连接到 Kubernetes 服务账户，同时要求角色及传递该角色的身份都必须与 EKS 集群位于同一 AWS 账户中。如果应用程序容器组（pod）需要访问 AWS 资源，它会向容器组身份请求凭证。随后，容器组身份会按顺序自动执行两次角色代入：首先代入 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)，然后使用该凭证代入目标 IAM 角色。此过程可为容器组（pod）提供临时凭证（这些凭证具有目标角色中定义的权限），从而安全访问其他 AWS 账户中的资源。
## 缓存注意事项
由于缓存机制，对现有容器组身份关联中 IAM 角色的更新可能不会立即在 EKS 集群上运行的容器组（pod）中生效。容器组身份代理会根据获取凭证时的关联配置来缓存 IAM 凭证。如果关联仅包含 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)而不包含目标 IAM 角色，则缓存凭证有效期为 6 小时。如果关联同时包含 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN 和目标 IAM 角色，则缓存凭证有效期为 59 分钟。修改现有关联（例如更新 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN 或添加目标 IAM 角色）不会重置现有缓存。因此，只有在刷新缓存凭证后，代理才会识别更新。如需立即应用更改，可重新创建现有容器组（pod）；否则需等待缓存过期。
## 第 1 步：创建并关联目标 IAM 角色
在此步骤中，您将通过创建和配置目标 IAM 角色来建立安全的信任链。出于演示目的，我们将创建新的目标 IAM 角色，以在两个 AWS 账户间建立信任链：位于 EKS 集群 AWS 账户中的 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)（例如 `eks-pod-identity-primary-role`）将获得代入目标账户中目标 IAM 角色（例如 `eks-pod-identity-aws-resources`）的权限，从而实现对 Amazon S3 存储桶等 AWS 资源的访问。
### 创建目标 IAM 角色
1. 打开 [Amazon IAM 控制台](https://console.aws.amazon.com/iam/home)。
1. 在顶部导航栏中，确认您已登录包含目标 IAM 角色所需 AWS 资源（例如 S3 存储桶或 DynamoDB 表）的账户。
1. 在左侧导航窗格中，选择 **角色**。
1. 选择**创建角色**按钮，然后选择“可信实体类型”下的 **AWS 账户**。
1. 选择**其他 AWS 账户**，输入 AWS 账号（[EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)所在的账户账号），然后选择**下一步**。
1. 添加要与该角色关联的权限策略（例如 AmazonS3FullAccess），然后选择**下一步**。
1. 输入 `MyCustomIAMTargetRole` 等角色名称，然后选择**创建角色**。
### 更新目标 IAM 角色的信任策略
1. 创建角色后，您将返回到**角色**列表。查找并选择您在上一步中创建的新角色（例如 `MyCustomIAMTargetRole`）。
1. 选择**信任关系**选项卡。
1. 点击右侧的**编辑信任策略**。
1. 在策略编辑器中，将默认 JSON 替换为信任策略。将 IAM 角色 ARN 中角色名称和 `111122223333` 的占位符值替换为托管 EKS 集群的 AWS 账户 ID。您也可以选择在角色信任策略中使用 PrincipalTags，以仅授权来自给定集群和命名空间的特定服务账户来代入目标角色。例如：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
上述策略允许来自 AWS 账户 111122223333，并带有相关 [EKS 容器组身份会话标签](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html)的角色 `eks-pod-identeity-primary-role` 代入此角色。
如果您在 EKS 容器组身份中[禁用会话标签](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags)，则在代入目标角色时，EKS 容器组身份还会设置 `sts:ExternalId`，其中包含有关容器组（pod）集群、命名空间和服务账户的信息。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
上述策略有助于确保只有预期的集群、命名空间和服务账户才能代入目标角色。
### 更新 EKS 容器组身份角色的权限策略
在此步骤中，您将通过添加目标 IAM 角色 ARN 作为资源，来更新 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)（与 Amazon EKS 集群关联）的权限策略。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧导航窗格中，选择**集群**，然后选择 EKS 集群名称。
1. 选择**访问**选项卡。
1. 在**容器组身份关联**下，选择 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)。
1. 依次选择**权限**、**添加权限**，然后选择**创建内联策略**。
1. 选择右侧的 **JSON**。
1. 在策略编辑器中，将默认 JSON 替换为权限策略。将 IAM 角色 ARN 中角色名称和 `222233334444` 的占位符值替换为目标 IAM 角色。例如：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## 第 2 步：将 IAM 角色关联到 Kubernetes 服务账户
在此步骤中，您将在目标 IAM 角色与 EKS 集群中的 Kubernetes 服务账户之间创建关联。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧导航窗格中，选择**集群**，然后选择要向其添加关联的集群名称。
1. 选择**访问**选项卡。
1. 在**容器组身份关联**中，选择**创建**。
1. 在 **IAM 角色**中选择供工作负载代入的 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)。
1. 在**目标 IAM 角色**中选择将由 [EKS 容器组身份角色](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)代入的目标 IAM 角色。
1. 在 **Kubernetes 命名空间**字段中，输入要在其中创建关联的命名空间名称（例如 `my-app-namespace`），这将定义服务账户所在的位置。
1. 在 **Kubernetes 服务账户**字段中，输入将使用 IAM 凭证的服务账户名称（例如 `my-service-account`）。这会将 IAM 角色链接到服务账号。
1. （可选）选择**禁用会话标签**以禁用容器组身份在担任角色时自动添加的默认会话标签。
1. （可选）切换**配置会话策略**，以配置 IAM 策略，以便对这个容器组身份关联施加超出附加到**目标 IAM 角色**的 IAM 策略所定义权限的额外限制。
**注意**
1. 只有在**禁用会话标签**设置被选中的情况下，才能应用会话策略。2. 如果您指定会话策略，则策略限制适用于**目标 IAM 角色**的权限，而不是与此容器组身份关联相关联的 **IAM 角色**。
1. 选择**创建**以创建关联。
# 配置容器组（pod）使用服务账户访问 AWS 服务
如果容器组（pod）需要访问 AWS 服务，则必须配置它来使用 Kubernetes 服务账户。服务账户必须关联到有权访问 AWS 服务的 AWS Identity and Access Management（IAM）角色。
+ 现有集群。如果还没有，可以使用[开始使用 Amazon EKS](getting-started.md) 中的指南之一创建一个。
+ 现有 Kubernetes 服务账户和 EKS 容器组身份关联（将服务账户与 IAM 角色关联）。该角色必须具有关联的 IAM 策略，其中包含您希望容器组（pod）必须具有的权限，以便使用 AWS 服务。有关如何创建和配置服务账户和角色的更多信息，请参阅 [向 Kubernetes 服务账户分配 IAM 角色](pod-id-association.md)。
+ 在您的设备或 AWS CLI 上安装和配置的最新版本 AWS CloudShell。您可以使用 `aws --version | cut -d / -f2 | cut -d ' ' -f1` 检查您的当前版本。`yum`、`apt-get` 或适用于 macOS 的 Homebrew 等软件包管理器通常比 AWS CLI 的最新版本落后几个版本。要安装最新版本，请参阅《AWS 命令行界面用户指南》中的[安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)和[使用 aws configure 快速配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)。AWS CloudShell 中安装的 AWS CLI 版本也可能比最新版本落后几个版本。要对其进行更新，请参阅《AWS CloudShell 用户指南》中的[将 AWS CLI 安装到您的主目录](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)。
+ 您的设备或 AWS CloudShell 上安装了 `kubectl` 命令行工具。该版本可以与集群的 Kubernetes 版本相同，或者最多早于或晚于该版本一个次要版本。例如，如果您的集群版本为 `1.29`，则可以将 `kubectl` 的 `1.28`、`1.29` 或 `1.30` 版本与之配合使用。要安装或升级 `kubectl`，请参阅 [设置 `kubectl` 和 `eksctl`](install-kubectl.md)。
+ 包含集群配置的现有 `kubectl` `config` 文件。要创建 `kubectl` `config` 文件，请参阅 [通过创建 kubeconfig 文件将 kubectl 连接到 EKS 集群](create-kubeconfig.md)。
1. 使用以下命令创建部署清单，您可以使用该部署清单部署容器组（pod）来确认配置。将示例值替换为您自己的值。
```
cat >my-deployment.yaml <
基于属性的访问权限控制（ABAC）通过将各种属性组合在一起的策略向用户授予权限。EKS 容器组身份将标签附加到每个容器组（pod）的临时凭证上，其中包含集群名称、命名空间、服务账户名称等属性。这些角色会话标签允许管理员根据匹配的标签访问 AWS 资源，从而使管理员能够创建可跨服务账户使用的单一角色。通过添加对角色会话标签的支持，您可以在集群之间和集群内的工作负载之间实施更严格的安全边界，同时重复使用相同的 IAM 角色和 IAM 策略。
## 带标签的示例策略
以下是一个 IAM 策略示例，该策略会在相应对象标有 EKS 集群名称时授予 `s3:GetObject` 权限。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## 启用或禁用会话标签
EKS 容器组身份会在代入角色时添加一组预定义的会话标签。这些会话标签允许管理员根据匹配的标签访问 AWS 资源，从而使管理员能够创建可跨资源使用的单一角色。
### 启用会话标签
会话标签将通过 EKS 容器组身份自动启用，您无需执行任何操作。默认情况下，EKS 容器组身份会将一组预定义标签附加到会话。要在策略中引用这些标签，请使用语法 `${aws:PrincipalTag/`，后跟标签键。例如 `${aws:PrincipalTag/kubernetes-namespace}`。
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### 禁用会话标签
AWS 会将内联会话策略、托管策略 ARN 和会话标签压缩为具有单独限制的打包二进制格式。如果您收到 `PackedPolicyTooLarge` 错误消息，表明打包二进制格式超出了大小限制，则可通过禁用由 EKS 容器组身份添加的会话标签来减小大小。要禁用这些会话标签，请执行以下步骤：
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧导航窗格中，选择**集群**，然后选择要修改的集群名称。
1. 选择**访问**选项卡。
1. 在**容器组身份关联**中，在**关联 ID** 中选择要修改的关联 ID，然后选择**编辑**。
1. 在**会话标签**下，选择**禁用会话标签**。
1. 选择**保存更改**。
## 跨账户标签
EKS 容器组身份添加的所有会话标签都是*可传递*的；将标签键和值传递到任何 `AssumeRole` 操作，以便您的工作负载用于将角色切换到其他账户。您可以在其他账户的策略中使用这些标签，来限制跨账户场景中的访问。有关更多信息，请参阅《IAM 用户指南》**中的[使用会话标签链接角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining)。
## 自定义标签
EKS 容器组身份无法在其执行的 `AssumeRole` 操作中添加其它自定义标签。但是，应用于 IAM 角色的标签始终可通过相同格式引用：`${aws:PrincipalTag/` 后跟键，例如 `${aws:PrincipalTag/MyCustomTag}`。
**注意**
如果发生冲突，通过 `sts:AssumeRole` 请求添加到会话中的标签优先。例如，假设：
EKS 代入客户角色时，Amazon EKS 向会话添加键 `eks-cluster-name` 和值 `my-cluster`
您向 IAM 角色添加了一个值为 `my-own-cluster` 的 `eks-cluster-name` 标签。
在这种情况下，前者优先，`eks-cluster-name` 标签的值为 `my-cluster`。
# 将容器组身份与 AWS SDK 结合使用
## 使用 EKS 容器组身份凭证
要使用来自 EKS 容器组身份关联的凭证，您的代码可以使用任何 AWS SDK 为具有 SDK 的 AWS 服务创建客户端，默认情况下，SDK 会在一系列位置中搜索要使用的 AWS Identity and Access Management 凭证。如果您在创建客户端或者初始化 SDK 时未指定凭证提供程序，则将使用 EKS 容器组身份凭证。
由于 EKS 容器组身份已添加到*容器凭证提供程序*，可在默认凭证链的一个步骤中搜索，因此该操作可行。如果您的工作负载当前使用凭证链中较早的证书，则即使您为同一工作负载配置了 EKS 容器组身份关联，这些凭证也将继续使用。
有关 EKS 容器组身份如何工作的更多信息，请参阅 [了解 EKS 容器组身份的工作原理](pod-id-how-it-works.md)。
在使用[了解 EKS 容器组身份如何向容器组（pod）授予对 AWS 服务的访问权限](pod-identities.md)时，容器组中的容器必须使用支持从 EKS 容器组身份代理担任 IAM 角色的 AWS SDK 版本。请确保为您的 AWS SDK 使用以下版本或更高版本：
+ Java（版本 2）：[2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ Go v1：[v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ Go v2：[release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ Python（Boto3）– [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ Python (botocore) – [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript v3 – [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ Kotlin – [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ Ruby：[3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ Rust – [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ C\$1\$1 – [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET – [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell – [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP：[3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
为了确保您使用的是受支持的 SDK，请在构建容器时按照[用于在 AWS 上进行构建的工具](https://aws.amazon.com/tools/)中针对您的首选 SDK 的安装说明操作。
有关支持 EKS 容器组身份的附加组件列表，请参阅 [容器组身份支持参考](retreive-iam-info.md#pod-id-add-on-versions)。
# 在 EKS 容器组身份代理中禁用 `IPv6`
## AWS 管理控制台
1. 要在 EKS 容器组身份代理中禁用 `IPv6`，请将以下配置添加到 EKS 附加组件的**可选配置设置**中。
1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。
1. 在左侧导航窗格中，选择 **Clusters**（集群），然后选择要为其配置附加组件的集群的名称。
1. 选择**附加组件**选项卡。
1. 选择 EKS 容器组身份代理附加组件框右上角的框，然后选择**编辑**。
1. 在**配置 EKS 容器组身份代理**页面上：
1. 选择您想使用的**版本**。我们建议您保留与上一步相同的版本，并通过单独的操作更新版本和配置。
1. 展开**可选配置设置**。
1. 在**配置值**中输入 JSON 键 `"agent":`，以及键为 `"additionalArgs":` 的嵌套 JSON 对象的值。生成的文本必须是有效的 JSON 对象。如果此键和值是文本框中的唯一数据，请用大括号 `{ }` 将键和值括起来。以下示例显示网络策略已启用：
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
此配置会将 `IPv4` 地址设置为代理所使用的唯一地址。
1. 要通过替换 EKS 容器组身份代理容器组来应用新配置，请选择**保存更改**。
Amazon EKS 通过*推出*适用于 EKS 容器组身份代理的 Kubernetes `DaemonSet`，将更改应用到 EKS 附加组件。可在 AWS 管理控制台 中的附加组件**更新历史记录**中跟踪推出状态和 `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`。
`kubectl rollout` 具有以下命令：
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
如果推出时间过长，Amazon EKS 将撤销推出，并且会将类型为**附加组件更新**且状态为**失败**的消息添加到附加组件的**更新历史记录**中。要调查任何问题，请先查看推出历史记录，然后在 EKS 容器组身份代理容器组上运行 `kubectl logs`，进而查看 EKS 容器组身份代理的日志。
1. 如果**更新历史记录**中的新条目状态为**成功**，则表示推出已完成，并且附加组件正在所有 EKS 容器组身份代理容器组中使用新配置。
## AWS CLI
1. 要在 EKS 容器组身份代理中禁用 `IPv6`，请将以下配置添加到 EKS 附加组件的**配置值**中。
运行以下 AWS CLI 命令。将 `my-cluster` 替换为集群的名称，并将 IAM 角色 ARN 替换为您正在使用的角色。
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
此配置会将 `IPv4` 地址设置为代理所使用的唯一地址。
Amazon EKS 通过*推出*适用于 EKS 容器组身份代理的 Kubernetes DaemonSet，将更改应用到 EKS 附加组件。可在 AWS 管理控制台 中的附加组件**更新历史记录**中跟踪推出状态和 `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`。
`kubectl rollout` 具有以下命令：
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
如果推出时间过长，Amazon EKS 将撤销推出，并且会将类型为**附加组件更新**且状态为**失败**的消息添加到附加组件的**更新历史记录**中。要调查任何问题，请先查看推出历史记录，然后在 EKS 容器组身份代理容器组上运行 `kubectl logs`，进而查看 EKS 容器组身份代理的日志。
# 创建具有 EKS 容器组身份所需信任策略的 IAM 角色
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
在将临时凭证传递给您的容器组之前，EKS 容器组身份使用 `AssumeRole` 分派 IAM 角色。
** `sts:TagSession` **
EKS 容器组身份使用 `TagSession` 在对 AWS STS 的请求中包含*会话标签*。
**设置条件**
您可以在信任策略的*条件键*中使用这些标签，来限制哪些服务账户、命名空间和集群可以使用此角色。有关容器组身份添加的请求标签列表，请参阅[启用或禁用会话标签](pod-id-abac.md#pod-id-abac-tags)。
例如，您可以通过在以下信任策略中添加 `Condition`，将可以担任某个容器组身份 IAM 角色的容器组（pod）限制为特定的 `ServiceAccount` 和 `Namespace`：
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
有关 Amazon EKS 条件键的列表，请参阅《Service Authorization Reference》**中的 [Conditions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)。要了解您可以对哪些操作和资源使用条件键，请参阅 [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。