**帮助改进此页面** 要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。 # Amazon EKS 中的安全性 AWS 十分重视云安全性。作为 AWS 客户，您将从专为满足大多数安全敏感型企业的要求而打造的数据中心和网络架构中受益。 安全性是 AWS 和您的共同责任。[责任共担模型](https://aws.amazon.com/compliance/shared-responsibility-model/)将其描述为云*的*安全性和云*中*的安全性： + **云的安全性** – AWS 负责保护在 AWS 云中运行 AWS 服务的基础设施。对于 Amazon EKS，AWS 负责 Kubernetes 控制层面，其中包括控制层面节点和 `etcd` 数据库。作为 [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)的一部分，第三方审核人员将定期测试和验证安全性的有效性。要了解适用于 Amazon EKS 的合规性计划，请参阅[合规性计划范围内的AWS服务](https://aws.amazon.com/compliance/services-in-scope/)。 + **云中的安全性** – 您的责任包括以下各个方面。 + 数据层面的安全配置，包括配置安全组以允许流量从 Amazon EKS 控制层面传入客户 VPC + 节点和容器本身的配置 + 节点操作系统（包括更新和安全补丁） + 其他关联的应用程序软件： + 设置和管理网络控制功能，例如防火墙规则 + 使用 IAM 或其他服务管理平台级身份和访问管理 + 您的数据的敏感性、您公司的要求以及适用的法律法规 Amazon EKS 已通过有关受监管和敏感应用程序的多个合规计划认证。Amazon EKS 符合 [SOC](https://aws.amazon.com/compliance/soc-faqs/)、[PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)、[ISO](https://aws.amazon.com/compliance/iso-certified/)、[FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/)、[IRAP](https://aws.amazon.com/compliance/irap/)、[C5](https://aws.amazon.com/compliance/bsi-c5/)、[K-ISMS](https://aws.amazon.com/compliance/k-isms/)、[ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/)、[OSPAR](https://aws.amazon.com/compliance/OSPAR/)、[HITRUST CSF](https://aws.amazon.com/compliance/hitrust/) 标准，并且是一项符合 [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/) 要求的服务。有关更多信息，请参阅 [了解 Amazon EKS 中的访问控制工作原理](cluster-auth.md)。 此文档将帮助您了解如何在使用 Amazon EKS 时应用责任共担模式。以下主题说明如何配置 Amazon EKS 以实现您的安全性和合规性目标。您还会了解如何使用其他AWS服务以帮助您监控和保护 Amazon EKS 资源。 **注意** Linux 容器由控制组 (cgroup) 和命名空间组成，这些控制组和命名空间有助于限制容器可以访问的内容，但所有容器都与主机 Amazon EC2 实例共享相同的 Linux 内核。非常不建议以根用户 (UID 0) 身份运行容器或授予容器对主机资源或命名空间（如主机网络或主机 PID 命名空间）的访问权限，因为这样做会降低容器提供的隔离的有效性。 **Topics** + [使用最佳实践保护 Amazon EKS 集群](security-best-practices.md) + [分析 Amazon EKS 中的漏洞](configuration-vulnerability-analysis.md) + [Amazon EKS 集群的合规性验证](compliance.md) + [Amazon Elastic Kubernetes Service 的安全注意事项](security-eks.md) + [Kubernetes 的安全注意事项](security-k8s.md) + [Amazon EKS 自动模式的安全注意事项](auto-security.md) + [EKS 功能的安全注意事项](capabilities-security.md) + [适用于 Amazon EKS 的身份和访问管理](security-iam.md) # 使用最佳实践保护 Amazon EKS 集群 Amazon EKS 安全最佳实践在《Amazon EKS 最佳实践指南》**中的[安全最佳实践](https://docs.aws.amazon.com/eks/latest/best-practices/security.html)中。 # 分析 Amazon EKS 中的漏洞 安全性是配置和维护 Kubernetes 集群和应用程序的重要注意事项。下方列出了供您分析 EKS 集群安全配置的资源、用于检查漏洞的资源，以及可为您执行该分析的 AWS 服务的集成。 ## 适用于 Amazon EKS 的互联网安全中心（CIS）基准 [Center for Internet Security（CIS）Kubernetes 基准](https://www.cisecurity.org/benchmark/kubernetes/)提供了关于 Amazon EKS 安全配置的指导。该基准： + 适用于 Amazon EC2 节点（托管和自我管理），您在其中负责 Kubernetes 组件的安全配置。 + 提供了一种社区批准的标准方法，以确保您在使用 Amazon EKS 时已安全地配置了 Kubernetes 集群和节点。 + 由四个部分组成：控制层面日志记录配置、节点安全配置、策略和托管服务。 + 支持 Amazon EKS 中当前提供的所有 Kubernetes 版本，并且可以使用 [kube-bench](https://github.com/aquasecurity/kube-bench)（一个用于在 Kubernetes 集群上使用 CIS 基准检查配置的标准开源工具）运行。 要了解更多信息，请参阅 [CIS Amazon EKS 基准简介](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark)。 有关使用 CIS 基准 AMI 更新节点组的自动 `aws-sample` 管道，请参阅 [EKS-Optimized AMI Hardening Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates)。 ## Amazon EKS 平台版本 Amazon EKS *平台版本*表示集群控制面板的功能，包括启用哪些 Kubernetes API 服务器标志和当前的 Kubernetes 补丁版本。使用最新平台版本部署新集群。有关详细信息，请参阅 [EKS platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)。 您可以[将 Amazon EKS 集群更新到](update-cluster.md)更新的 Kubernetes 版本。随着新 Kubernetes 版本在 Amazon EKS 中提供，我们建议您主动将集群更新为使用最新的可用版本。要了解有关 EKS 中 Kubernetes 版本的更多信息，请参阅 [Amazon EKS 支持的版本](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)。 ## 操作系统漏洞列表 ### AL2023 漏洞列表 在 [Amazon Linux 安全中心](https://alas.aws.amazon.com/alas2023.html)跟踪 Amazon Linux 2023 的安全和隐私事件，或订阅关联的 [RSS 源](https://alas.aws.amazon.com/AL2023/alas.rss)。安全和隐私事件包括受影响问题的概述、程序包以及更新实例以解决问题的说明。 ### Amazon Linux 2 漏洞列表 在 [Amazon Linux 安全中心](https://alas.aws.amazon.com/alas2.html)跟踪 Amazon Linux 2 的安全和隐私事件，或订阅关联的 [RSS 源](https://alas.aws.amazon.com/AL2/alas.rss)。安全和隐私事件包括受影响问题的概述、程序包以及更新实例以解决问题的说明。 ## 使用 Amazon Inspector 进行节点检测 您可以使用 [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) 来检查节点的意外网络访问和这些 Amazon EC2 实例上的漏洞。 ## 使用 Amazon GuardDuty 进行集群和节点检测 Amazon GuardDuty 是一项威胁检测服务，有助于保护您的账户、容器、工作负载和 AWS 环境中的数据。除其他功能外，GuardDuty 还提供以下两项功能，用于检测 EKS 集群面临的潜在威胁：*EKS 保护*和*运行时监控*。 有关更多信息，请参阅 [使用 Amazon GuardDuty 检测威胁](integration-guardduty.md)。 # Amazon EKS 集群的合规性验证 要了解某个 AWS 服务是否在特定合规性计划范围内，请参阅[合规性计划范围内的 AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)，然后选择您感兴趣的合规性计划。有关一般信息，请参阅 [AWS合规性计划](https://aws.amazon.com/compliance/programs/)。 您可以使用 AWS Artifact 下载第三方审计报告。有关更多信息，请参阅[下载 AWS Artifact 中的报告](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。 您在使用 AWS 服务时的合规性责任由您数据的敏感性、贵公司的合规性目标以及适用的法律法规决定。AWS 提供以下资源来帮助满足合规性： + [Security Compliance & Governance](https://aws.amazon.com/solutions/security/security-compliance-governance/)：这些解决方案实施指南讨论了架构考虑因素，并提供了部署安全性和合规性功能的步骤。 + [符合 HIPAA 要求的服务参考](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/)：列出符合 HIPAA 要求的服务。并非所有 AWS 服务都符合 HIPAA 条件。 + [AWS 合规性资源](https://aws.amazon.com/compliance/resources/) – 此业务手册和指南集合可能适用于您的行业和位置。 + [AWS 客户合规指南](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)：从合规角度了解责任共担模式。这些指南总结了保护 AWS 服务的最佳实践，并将指南映射到跨多个框架的安全控制，包括美国国家标准与技术研究院（NIST）、支付卡行业安全标准委员会（PCI）和国际标准化组织（ISO）。 + 《AWS Config 开发人员指南》**中的[使用规则评估资源](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) – AWS Config 服务评估您的资源配置对内部实践、行业指南和法规的遵循情况。 + [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – 该 AWS 服务向您提供 AWS 中安全状态的全面视图。Security Hub 通过安全控制措施评估您的 AWS 资源并检查其是否符合安全行业标准和最佳实践。有关受支持服务及控制措施的列表，请参阅 [Security Hub 控制措施参考](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html)。 + [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) – 该 AWS 服务通过监控您的环境中是否存在可疑和恶意活动，来检测您的 AWS 账户、工作负载、容器和数据面临的潜在威胁。GuardDuty 可以通过满足某些合规性框架规定的入侵检测要求，来协助您满足各种合规性要求，如 PCI DSS。 + [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – 此 AWS服务帮助您持续审计您的AWS使用情况，以简化管理风险以及与相关法规与行业标准的合规性的方式。 # Amazon Elastic Kubernetes Service 的安全注意事项 以下是关于云安全的注意事项，这些注意事项会对 Amazon EKS 造成影响。 **Topics** + [Amazon EKS 中的基础设施安全性](infrastructure-security.md) + [了解 Amazon EKS 集群中的弹性](disaster-recovery-resiliency.md) + [防止在 Amazon EKS 中出现跨服务混淆代理](cross-service-confused-deputy-prevention.md) # Amazon EKS 中的基础设施安全性 作为一项托管式服务，Amazon Elastic Kubernetes Service 受 AWS 全球网络安全保护。有关 AWS 安全服务以及 AWS 如何保护基础设施的信息，请参阅 [AWS 云安全性](https://aws.amazon.com/security/)。要按照基础设施安全最佳实践设计您的 AWS 环境，请参阅《安全性支柱 AWS Well‐Architected Framework》**中的[基础设施保护](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。 您可以使用AWS发布的 API 调用通过网络访问 Amazon EKS。客户端必须支持以下内容： + 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。 + 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。 此外，必须使用访问密钥 ID 和与 IAM 主体关联的秘密访问密钥来对请求进行签名。或者，您可以使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)（AWS STS）生成临时安全凭证，对请求进行签名。 在创建 Amazon EKS 集群时，为要使用的集群指定 VPC 子网。Amazon EKS 需要至少位于两个可用区中的子网。我们建议使用同时带有公有子网和私有子网的 VPC，以便 Kubernetes 可以在公有子网中创建公有负载均衡器，进而将流量负载均衡到在私有子网中的节点上运行的负载均衡器。 有关 VPC 注意事项的更多信息，请参阅[查看 Amazon EKS 对 VPC 和子网的联网要求](network-reqs.md)。 如果使用[开始使用 Amazon EKS](getting-started.md) 演练中提供的 AWS CloudFormation 模板创建 VPC 和节点组，则将使用推荐设置来配置控制面板和节点安全组。 有关安全组注意事项的更多信息，请参阅[查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。 在创建新集群时，Amazon EKS 将为您用于与集群进行通信的托管 Kubernetes API 服务器（使用 Kubernetes 管理工具，如 `kubectl`）创建端点。默认情况下，此 API 服务器端点对于互联网是公有的，对 API 服务器的访问将使用 AWS Identity and Access Management（IAM）与本机 Kubernetes [基于角色的访问控制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)（RBAC）相结合的方式加以保护。 您可以启用对 Kubernetes API 服务器的私有访问，以便节点与 API 服务器之间的所有通信都在 VPC 内。您可以限制从 Internet 访问 API 服务器的 IP 地址，或完全禁用对 API 服务器的 Internet 访问。 有关修改集群终端节点访问的更多信息，请参阅[修改集群终端节点访问](cluster-endpoint.md#modify-endpoint-access)。 您可以使用 Amazon VPC CNI 或第三方工具（如 [Project Calico](https://docs.tigera.io/calico/latest/about/)）实施 Kubernetes *网络策略*。有关将 Amazon VPC CNI 用于网络策略的更多信息，请参阅 [通过 Kubernetes 网络策略限制容器组（pod）流量](cni-network-policy.md)。Project Calico 是一个第三方开源项目。有关更多信息，请参阅 [Project Calico 文档](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/)。 # 使用 AWS PrivateLink 访问 Amazon EKS 您可以使用 AWS PrivateLink 在您的 VPC 和 Amazon Elastic Kubernetes Service 之间创建私有连接。您可以像在 VPC 中一样访问 Amazon EKS，而无需使用互联网网关、NAT 设备、VPN 连接或 AWS Direct Connect 连接。VPC 中的实例不需要公有 IP 地址即可访问 Amazon EKS。 您可以通过创建由 AWS PrivateLink 提供支持的接口端点来建立此私有连接。我们将在您为接口端点启用的每个子网中创建一个端点网络接口。这些是请求者托管式网络接口，用作发往 Amazon EKS 的流量的入口点。 有关更多信息，请参阅《AWS PrivateLink 指南》**中的 [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)。 ## 开始前的准备工作 开始之前，请确保您已执行以下任务： + 查看《AWS PrivateLink Guide》**中的 [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) ## 注意事项 + **支持和限制**：Amazon EKS 接口端点允许从您的 VPC 安全访问所有 Amazon EKS API 操作，但有特定的限制：它们不支持访问 Kubernetes API，因为其有单独的私有端点，因此您无法将 Amazon EKS 配置为仅通过接口端点访问。 + **定价**：使用 Amazon EKS 的接口端点会产生标准 AWS PrivateLink 费用：每个可用区中预置的每个端点的小时费用，以及通过端点的流量的数据处理费用。要了解更多信息，请参阅 [AWS PrivateLink 定价](https://aws.amazon.com/privatelink/pricing/)。 + **安全和访问控制**：我们建议通过以下附加配置增强安全性和控制访问 – 使用 VPC 端点策略控制通过接口端点访问 Amazon EKS，将安全组与端点网络接口关联以管理流量，使用 VPC 流日志捕获和监控进出接口端点的 IP 流量，日志可发布到 Amazon CloudWatch 或 Amazon S3。要了解更多信息，请参阅 [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) 和[使用 VPC 流日志记录 IP 流量](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)。 + **连接选项**：接口端点提供灵活的连接选项，支持通过**本地访问**（使用 AWS Direct Connect 或 AWS Site-to-Site VPN 将本地数据中心连接到包含接口端点的 VPC）或通过 **VPC 间连接**（使用 AWS Transit Gateway 或 VPC 对等连接将其他 VPC 连接到包含接口端点的 VPC，从而将流量保持在 AWS 网络内）。 + **IP 版本支持**：在 2024 年 8 月之前创建的端点仅支持使用 eks.region.amazonaws.com 的 IPv4。2024 年 8 月之后创建的新端点支持双堆栈 IPv4 和 IPv6（例如，eks.region.amazonaws.com、eks.region.api.aws）。 + **区域可用性**：适用于 EKS API 的 AWS PrivateLink 在以下区域不可用：亚太地区（马来西亚）（ap-southeast-5）、亚太地区（泰国）（ap-southeast-7）、墨西哥（中部）（mx-central-1）和亚太地区（台北）（ap-east-2）区域。AWSPrivateLink 对 eks-auth（EKS 容器组身份）的支持已在亚太地区（马来西亚）(ap-southeast-5) 区域开放。 ## 为 Amazon EKS 创建接口端点 您可以使用 Amazon VPC 控制台或 AWS 命令行界面（AWS CLI）为 Amazon EKS 创建接口端点。有关更多信息，请参阅《AWS PrivateLink 指南》**中的[创建 VPC 端点](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)。 使用以下服务名称为 Amazon EKS 创建接口端点： ### EKS API + com.amazonaws.region-code.eks + com.amazonaws.region-code.eks-fips（适用于符合 FIPS 的端点） ### EKS Auth API（EKS 容器组身份） + com.amazonaws.region-code.eks-auth ## Amazon EKS 接口端点的私有 DNS 功能 Amazon EKS 和其他 AWS 服务的接口端点默认启用私有 DNS 功能，便于使用默认区域 DNS 名称进行安全和私有 API 请求。此功能可确保 API 调用通过接口端点经由私有 AWS 网络路由，从而增强安全性和性能。 当您为 Amazon EKS 或其他 AWS 服务创建接口端点时，将自动激活 DNS 功能。要启用该功能，您需要通过设置特定属性来正确配置您的 VPC： + **enableDnsHostnames**：允许 VPC 内的实例拥有 DNS 主机名。 + **enableDnsSupport**：在整个 VPC 中启用 DNS 解析。 有关检查或修改这些设置的分步说明，请参阅[查看和更新 VPC 的 DNS 属性](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)。 ### DNS 名称和 IP 地址类型 启用私有 DNS 功能后，您可以使用特定的 DNS 名称连接到 Amazon EKS，这些选项会随着时间的推移而不断演进： + **eks.region.amazonaws.com**：传统的 DNS 名称，在 2024 年 8 月之前仅解析为 IPv4 地址。对于更新为双堆栈的现有端点，此名称将同时解析为 IPv4 和 IPv6 地址。 + **eks.region.api.aws**：适用于 2024 年 8 月之后创建的新端点，此双堆栈 DNS 名称可同时解析为 IPv4 和 IPv6 地址。 2024 年 8 月之后，新的接口端点将包含两个 DNS 名称，您可以选择双堆栈 IP 地址类型。对于现有端点，更新为双堆栈将修改 **eks.region.amazonaws.com** 以同时支持 IPv4 和 IPv6。 ### 使用私有 DNS 功能 配置完成后，可以将私有 DNS 功能集成到您的工作流程中，提供以下功能： + **API 请求**：根据端点的设置，使用默认区域 DNS 名称（`eks.region.amazonaws.com` 或 `eks.region.api.aws`）向 Amazon EKS 发出 API 请求。 + **应用程序兼容性**：调用 EKS API 的现有应用程序无需进行任何更改即可利用此功能。 + **具有双堆栈的 AWS CLI**：要将双堆栈端点与 AWS CLI 结合使用，请参阅《AWS SDKs and Tools Reference Guide》**中的 [Dual-stack and FIPS endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) 配置。 + **自动路由**：对 Amazon EKS 默认服务端点的任何调用都会通过接口端点自动定向，从而确保连接私有和安全。 # 了解 Amazon EKS 集群中的弹性 AWS全球基础架构围绕AWS区域和可用区构建。AWS区域提供多个在物理上独立且隔离的可用区，这些可用区通过延迟低、吞吐量高且冗余性高的网络连接在一起。利用可用区，您可以设计和操作在可用区之间无中断地自动实现故障转移的应用程序和数据库。与传统的单个或多个数据中心基础架构相比，可用区具有更高的可用性、容错性和可扩展性。 Amazon EKS 跨多个AWS可用区运行和扩展 Kubernetes 控制层面以确保高可用性。Amazon EKS 可以根据负载自动缩放控制层面实例，检测并替换运行状况不佳的控制层面实例，并自动修补控制层面。启动版本更新后，Amazon EKS 会为您更新控制面板，从而在更新期间保持控制面板的高可用性。 此控制面板包含至少两个 API 服务器实例和三个 `etcd` 实例，这些实例在一个 AWS 区域内的三个可用区之间运行。Amazon EKS： + 主动监控控制面板实例上的负载，并自动扩展以确保高性能。 + 自动检测和替换运行状况不佳的控制面板实例，并根据需要跨 AWS 区域内的可用区重新启动它们。 + 利用AWS区域的架构以保持高可用性。因此，Amazon EKS 能够提供[确保 API 服务器端点可用性的 SLA](https://aws.amazon.com/eks/sla)。 有关 AWS 区域和可用区的更多信息，请参阅 [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)。 # 防止在 Amazon EKS 中出现跨服务混淆代理 混淆代理问题是一个安全问题，即没有执行操作权限的实体可能会迫使更具权限的实体执行该操作。在 AWS 中，跨服务模拟可能会导致混淆代理问题。一个服务（*呼叫服务*）调用另一项服务（*所谓的服务*）时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为防止这种情况，AWS 提供可帮助您保护所有服务的数据的工具，而这些服务中的服务主体有权限访问账户中的资源。 我们建议在资源策略中使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) 和 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) 全局条件上下文键，以限制 Amazon Elastic Kubernetes Service（Amazon EKS）为其他服务提供的资源访问权限。 `aws:SourceArn` 使用 `aws:SourceArn` 来仅将一个资源与跨服务访问相关联。 `aws:SourceAccount` 使用 `aws:SourceAccount` 来让该账户中的任何资源与跨服务使用相关联。 防范混淆代理问题最有效的方法是使用 `aws:SourceArn` 全局条件上下文键和资源的完整 ARN。如果不知道资源的完整 ARN，或者正在指定多个资源，请针对 ARN 未知部分使用带有通配符字符（\$1）的 `aws:SourceArn` 全局上下文条件键。例如 ` arn:aws::*:<123456789012>:*`。 如果 `aws:SourceArn` 值不包含账户 ID，例如 Amazon S3 桶 ARN，您必须使用 `aws:SourceAccount` 和 `aws:SourceArn` 来限制权限。 ## 防止 Amazon EKS 集群角色出现跨服务混淆代理 每个集群都需要一个 Amazon EKS 集群 IAM 角色。由 Amazon EKS 管理的 Kubernetes 集群会使用此角色来管理节点，而[传统云提供商](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)会使用此角色为服务创建带有 Elastic Load Balancing 的负载均衡器。这些集群操作只能影响同一账户，因此建议您将每个集群角色限制为该集群和账户。这是 AWS 建议的具体应用，即在您的账户中遵循*最低权限原则*。 **资源 ARN 格式** `aws:SourceArn` 的值必须是 EKS 集群的 ARN，格式为 ` arn:aws:eks:region:account:cluster/cluster-name `。例如，` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster`。 **EKS 集群角色的信任策略格式** 以下示例演示如何使用 Amazon EKS 中的 `aws:SourceArn` 和 `aws:SourceAccount` 全局条件上下文键来防止混淆代理问题。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } ] } ``` # Kubernetes 的安全注意事项 以下是云安全的注意事项，这些注意事项会对 Amazon EKS 集群中的 Kubernetes 造成影响。要深入了解 Kubernetes 中的安全控制措施和实践，请参阅 Kubernetes 文档中的[云原生安全和 Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/)。 **Topics** + [使用 Kubernetes 证书保护工作负载](cert-signing.md) + [了解 Amazon EKS 如何创建 RBAC 角色和用户](default-roles-users.md) + [在现有集群上使用 KMS 加密 Kubernetes 密钥](enable-kms.md) + [将 AWS Secrets Manager 密钥与 Amazon EKS 容器组（pod）结合使用](manage-secrets.md) + [所有 Kubernetes API 数据默认启用信封加密](envelope-encryption.md) # 使用 Kubernetes 证书保护工作负载 Kubernetes 证书 API 可自动执行 [X.509](https://www.itu.int/rec/T-REC-X.509) 凭证预置。该 API 具有一个命令行界面，供 Kubernetes API 客户端从证书颁发机构（CA）请求和获取 [X.509 证书](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)。您可以使用 `CertificateSigningRequest`（CSR）资源请求指示签署人对证书进行签名。您的请求在签署前获得批准或被拒绝。Kubernetes 支持内置签署人和具有明确定义行为的自定义签署人。这样，客户端就可以预测 CSR 会发生什么。要了解有关证书签名的更多信息，请参阅[签名请求](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/)。 内置签署人之一是 `kubernetes.io/legacy-unknown`。CSR 资源的 `v1beta1` API 遵循这个旧版未知的签署人。但是，CSR 的稳定 `v1` API 不允许将 `signerName` 设置为 `kubernetes.io/legacy-unknown`。 如果想使用 Amazon EKS CA 在集群上生成证书，则您必须使用自定义签署人。要使用 CSR `v1` API 版本并生成新证书，必须迁移任何现有清单和 API 客户端。使用现有 `v1beta1` API 创建的现有证书在证书到期之前有效且正常运行。这包括以下这些： + 信任分配：无。在 Kubernetes 集群中，此签署人没有标准的信任或分配。 + 允许的主题：任何 + 允许的 x509 扩展：遵循 subjectAltName 和密钥使用扩展，并丢弃其他扩展 + 允许的密钥用法：不得包括 [“密钥加密”、“数字签名”、“服务器身份验证”] 以外的用法 **注意** 不支持客户端证书签名。 + 到期/证书使用寿命：1 年（默认值和最大值） + 允许/不允许 CA 位：不允许 ## 使用 signerName 生成 CSR 示例 这些步骤介绍如何使用 `signerName: beta.eks.amazonaws.com/app-serving` 为 DNS 名称 `myserver.default.svc` 生成服务证书。将此用作您自己环境的指南。 1. 运行 `openssl genrsa -out myserver.key 2048` 命令以生成 RSA 私有密钥。 ``` openssl genrsa -out myserver.key 2048 ``` 1. 运行以下命令以生成证书请求。 ``` openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc" ``` 1. 为 CSR 请求生成 `base64` 值，并将其存储在变量中，以便在后续步骤中使用。 ``` base_64=$(cat myserver.csr | base64 -w 0 | tr -d " ") ``` 1. 要创建名为 `mycsr.yaml` 的文件，请运行以下命令。在以下示例中，`beta.eks.amazonaws.com/app-serving` 是 `signerName`。 ``` cat >mycsr.yaml < myserver.crt ``` # 了解 Amazon EKS 如何创建 RBAC 角色和用户 创建 Kubernetes 集群时，会在该集群上创建多个默认 Kubernetes 身份，以便 Kubernetes 正常运行。Amazon EKS 会为其每个默认组件创建 Kubernetes 身份。这些身份为集群组件提供 Kubernetes 基于角色的授权控制（RBAC）。有关更多信息，请参阅 Kubernetes 文档中的[使用 RBAC 授权](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。 在向集群安装可选[附加组件](eks-add-ons.md)时，可能会向集群添加其他 Kubernetes 身份。有关本主题未涉及身份的更多信息，请参阅附加组件文档。 您可以使用 AWS 管理控制台或 `kubectl` 命令行工具，查看 Amazon EKS 在集群上创建的 Kubernetes 身份列表。所有用户身份都会出现在 `kube` 审计日志中，可通过 Amazon CloudWatch 向你提供。 ## AWS 管理控制台 ### 先决条件 您使用的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必须拥有[所需权限](view-kubernetes-resources.md#view-kubernetes-resources-permissions)中描述的权限。 ### 要使用AWS 管理控制台查看 Amazon EKS 创建的身份 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 在 **Clusters**（集群）列表中，选择包含要查看的身份的集群。 1. 选择**资源**选项卡。 1. 在 **Resource types**（资源类型）下，选择 **Authorization**（授权）。 1. 选择 **ClusterRoles**、**ClusterRoleBindings**、**Roles** 或 **RoleBindings**。所有以 **eks** 为前缀的资源均由 Amazon EKS 创建。Amazon EKS 创建的其他身份资源包括： + **ClusterRole** 和名为 **aws-node** 的 **ClusterRoleBinding**。**aws-node** 资源支持[适用于 Kubernetes 的 Amazon VPC CNI 插件](managing-vpc-cni.md)，Amazon EKS 会将其安装在所有集群上。 + 名为 **vpc-resource-controller-role** 的 **ClusterRole** 和名为 **vpc-resource-controller-rolebinding** 的 **ClusterRoleBinding**。这些资源支持 [Amazon VPC 资源控制器](https://github.com/aws/amazon-vpc-resource-controller-k8s)，Amazon EKS 会将其安装在所有集群上。 除了控制台中的资源外，即使以下特殊用户身份在集群配置中不可见，但它们仍存在于您的集群上： + **`eks:cluster-bootstrap`** – 在集群引导期间用于 `kubectl` 操作。 + **`eks:support-engineer`** – 用于集群管理操作。 1. 选择特定资源以查看有关该资源的详细信息。默认情况下，信息在**结构化视图**中显示。在详细信息页面的右上角，您可以选择 **Raw view**（原始视图）以查看该资源的所有信息。 ## Kubectl ### 先决条件 用来列出集群上的 Kubernetes 资源的实体 [AWS Identity and Access Management（IAM）或 OpenID Connect（OIDC）]，必须由 IAM 或您的 OIDC 身份提供者进行身份验证。必须向实体授予权限，才能为您希望该实体使用的集群上的 `Role`、`ClusterRole`、`RoleBinding` 和 `ClusterRoleBinding` 资源使用 Kubernetes `get` 和 `list` 动词。有关向 IAM 实体授予集群访问权限的更多信息，请参阅[向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)。有关向经过您自己的 OIDC 提供者身份验证的实体授予集群访问权限的更多信息，请参阅[通过外部 OIDC 提供者向用户授予 Kubernetes 访问权限](authenticate-oidc-identity-provider.md)。 ### 要使用 `kubectl` 查看 Amazon EKS 创建的身份 为要查看的资源类型运行命令。所有以 **eks** 为前缀的返回资源均由 Amazon EKS 创建。除命令输出中返回的资源，即使以下特殊用户身份在集群配置中不可见，但它们仍存在于您的集群上： + **`eks:cluster-bootstrap`** – 在集群引导期间用于 `kubectl` 操作。 + **`eks:support-engineer`** – 用于集群管理操作。 **ClusterRoles** – `ClusterRoles` 范围限定为您的集群，因此授予角色的任何权限都适用于集群上任何 Kubernetes 命名空间中的资源。 以下命令返回 Amazon EKS 在您的集群上创建的所有 Kubernetes `ClusterRoles`。 ``` kubectl get clusterroles | grep eks ``` 除了输出中返回的 `ClusterRoles`（具有前缀）外，还存在以下 `ClusterRoles`。 + **`aws-node`** – 此 `ClusterRole` 支持[适用于 Kubernetes 的 Amazon VPC CNI 插件](managing-vpc-cni.md)，Amazon EKS 会将其安装在所有集群上。 + **`vpc-resource-controller-role`** – 该 `ClusterRole` 支持 [Amazon VPC 资源控制器](https://github.com/aws/amazon-vpc-resource-controller-k8s)，Amazon EKS 会将其安装在所有集群上。 要查看 `ClusterRole` 的规范，请将以下命令中的 *eks:k8s-metrics* 替换为上一条命令输出中返回的 `ClusterRole`。以下示例返回 *eks:k8s-metrics* `ClusterRole` 的规范。 ``` kubectl describe clusterrole eks:k8s-metrics ``` 示例输出如下。 ``` Name: eks:k8s-metrics Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- [/metrics] [] [get] endpoints [] [] [list] nodes [] [] [list] pods [] [] [list] deployments.apps [] [] [list] ``` **ClusterRoleBindings**：`ClusterRoleBindings` 范围限定为您的集群。 以下命令返回 Amazon EKS 在您的集群上创建的所有 Kubernetes `ClusterRoleBindings`。 ``` kubectl get clusterrolebindings | grep eks ``` 除了输出中返回的 `ClusterRoleBindings` 外，还存在以下 `ClusterRoleBindings`。 + **`aws-node`** – 此 `ClusterRoleBinding` 支持[适用于 Kubernetes 的 Amazon VPC CNI 插件](managing-vpc-cni.md)，Amazon EKS 会将其安装在所有集群上。 + **`vpc-resource-controller-rolebinding`** – 该 `ClusterRoleBinding` 支持 [Amazon VPC 资源控制器](https://github.com/aws/amazon-vpc-resource-controller-k8s)，Amazon EKS 会将其安装在所有集群上。 要查看 `ClusterRoleBinding` 的规范，请将以下命令中的 *eks:k8s-metrics* 替换为上一条命令输出中返回的 `ClusterRoleBinding`。以下示例返回 *eks:k8s-metrics* `ClusterRoleBinding` 的规范。 ``` kubectl describe clusterrolebinding eks:k8s-metrics ``` 示例输出如下。 ``` Name: eks:k8s-metrics Labels: Annotations: Role: Kind: ClusterRole Name: eks:k8s-metrics Subjects: Kind Name Namespace ---- ---- --------- User eks:k8s-metrics ``` **Roles** – `Roles` 范围限定为 Kubernetes 命名空间。Amazon EKS 创建的所有 `Roles` 范围限定为 `kube-system` 命名空间。 以下命令返回 Amazon EKS 在您的集群上创建的所有 Kubernetes `Roles`。 ``` kubectl get roles -n kube-system | grep eks ``` 要查看 `Role` 的规范，请将以下命令中的 *eks:k8s-metrics* 替换为上一条命令输出中返回的 `Role` 名称。以下示例返回 *eks:k8s-metrics* `Role` 的规范。 ``` kubectl describe role eks:k8s-metrics -n kube-system ``` 示例输出如下。 ``` Name: eks:k8s-metrics Labels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- daemonsets.apps [] [aws-node] [get] deployments.apps [] [vpc-resource-controller] [get] ``` **RoleBindings** – `RoleBindings` 范围限定为 Kubernetes 命名空间。Amazon EKS 创建的所有 `RoleBindings` 范围限定为 `kube-system` 命名空间。 以下命令返回 Amazon EKS 在您的集群上创建的所有 Kubernetes `RoleBindings`。 ``` kubectl get rolebindings -n kube-system | grep eks ``` 要查看 `RoleBinding` 的规范，请将以下命令中的 *eks:k8s-metrics* 替换为上一条命令输出中返回的 `RoleBinding`。以下示例返回 *eks:k8s-metrics* `RoleBinding` 的规范。 ``` kubectl describe rolebinding eks:k8s-metrics -n kube-system ``` 示例输出如下。 ``` Name: eks:k8s-metrics Labels: Annotations: Role: Kind: Role Name: eks:k8s-metrics Subjects: Kind Name Namespace ---- ---- --------- User eks:k8s-metrics ``` # 在现有集群上使用 KMS 加密 Kubernetes 密钥 **重要** 此过程仅适用于运行 Kubernetes 版本 1.27 或更低版本的 EKS 集群。如果运行的是 Kubernetes 1.28 或更高版本，则 Kubernetes 密钥将默认启用信封加密保护。有关更多信息，请参阅 [所有 Kubernetes API 数据默认启用信封加密](envelope-encryption.md)。 如果启用[密钥加密](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)，则会使用您选择的 AWS KMS 密钥对 Kubernetes 密钥加密。KMS 密钥必须符合以下条件： + 对称 + 可以加密和解密数据 + 在与集群相同的 AWS 区域中创建 + 如果 KMS 密钥是在其他账户中创建的，则 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必须拥有对 KMS 密钥的访问权限。 有关更多信息，请参阅 [AWS Key Management Service 者指南](https://docs.aws.amazon.com/kms/latest/developerguide/)** 中的[允许其它账户中的 IAM 主体使用 KMS 密钥](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html)。 **警告** 密钥加密启用后将无法禁用。此操作不可逆。 eksctl 此过程仅适用于运行 Kubernetes 版本 1.27 或更低版本的 EKS 集群。有关更多信息，请参阅 [所有 Kubernetes API 数据默认启用信封加密](envelope-encryption.md)。 可以通过下列两种方式启用加密： + 使用单个命令将加密添加到您的集群。 要自动重新加密密钥，请运行以下命令。 ``` eksctl utils enable-secrets-encryption \ --cluster my-cluster \ --key-arn arn:aws:kms:region-code:account:key/key ``` 要选择退出自动重新加密密钥，请运行以下命令。 ``` eksctl utils enable-secrets-encryption --cluster my-cluster \ --key-arn arn:aws:kms:region-code:account:key/key \ --encrypt-existing-secrets=false ``` + 使用 `kms-cluster.yaml` 文件向集群添加加密。 ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code secretsEncryption: keyARN: arn:aws:kms:region-code:account:key/key ``` 要自动重新加密密钥，请运行以下命令。 ``` eksctl utils enable-secrets-encryption -f kms-cluster.yaml ``` 要选择退出自动重新加密密钥，请运行以下命令。 ``` eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false ``` AWS 管理控制台 1. 此过程仅适用于运行 Kubernetes 版本 1.27 或更低版本的 EKS 集群。有关更多信息，请参阅 [所有 Kubernetes API 数据默认启用信封加密](envelope-encryption.md)。 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 选择要向其添加 KMS 加密的集群。 1. 选择 **Overview**（概述）选项卡（默认处于选中状态）。 1. 向下滚动到 **Secrets encryption**（密钥加密）部分，然后选择 **Enable**（启用）按钮。 1. 从下拉列表中选择一个密钥，然后选择 **Enable**（启用）按钮。如果未列出任何密钥，则必须先创建一个密钥。有关更多信息，请参阅[创建密钥](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)。 1. 选择 **Confirm**（确认）按钮以使用选定的密钥。 AWS CLI 1. 此过程仅适用于运行 Kubernetes 版本 1.27 或更低版本的 EKS 集群。有关更多信息，请参阅 [所有 Kubernetes API 数据默认启用信封加密](envelope-encryption.md)。 1. 使用以下 AWS CLI 命令将[密钥加密](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)配置与您的集群相关联。将 example values 替换为您自己的值。 ``` aws eks associate-encryption-config \ --cluster-name my-cluster \ --encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]' ``` 示例输出如下。 ``` {   "update": {     "id": "3141b835-8103-423a-8e68-12c2521ffa4d",     "status": "InProgress",     "type": "AssociateEncryptionConfig",     "params": [       {         "type": "EncryptionConfig",         "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"       }     ],     "createdAt": 1613754188.734,     "errors": []   } } ``` 1. 您可以使用以下命令监控加密更新的状态。使用上一个输出中返回的特定 `cluster name` 和 `update ID`。当 `Successful` 状态显示时，更新完成。 ``` aws eks describe-update \ --region region-code \ --name my-cluster \ --update-id 3141b835-8103-423a-8e68-12c2521ffa4d ``` 示例输出如下。 ``` {   "update": {     "id": "3141b835-8103-423a-8e68-12c2521ffa4d",     "status": "Successful",     "type": "AssociateEncryptionConfig",     "params": [       {         "type": "EncryptionConfig",         "value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"       }     ],     "createdAt": 1613754188.734>,     "errors": []   } } ``` 1. 要验证集群已启用加密，请运行 `describe-cluster` 命令。响应包含 `EncryptionConfig` 字符串。 ``` aws eks describe-cluster --region region-code --name my-cluster ``` 在集群上启用加密后，您必须使用新密钥加密所有现有密钥： **注意** 如果您使用 `eksctl`，只有在选择不自动重新加密密钥时才需要运行以下命令。 ``` kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value" ``` **警告** 如果您为现有集群启用[密钥加密](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)，并且您使用的 KMS 密钥已被删除，那么将无法恢复集群。如果您删除 KMS 密钥，会将集群永久性置于降级状态。有关更多信息，请参阅[删除 AWS KMS 密钥](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).. **注意** 默认情况下，`create-key` 命令会创建一个具有密钥政策的[对称加密 KMS 密钥](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html)，该密钥政策向账户的根管理员授予对 AWS KMS 操作和资源的访问权限。如果要缩小权限的范围，请确保允许对将调用 `create-cluster` API 的主体的策略执行 `kms:DescribeKey` 和 `kms:CreateGrant` 操作。 对于使用 KMS 信封加密的集群，需要具有 `kms:CreateGrant` 权限。CreateCluster 操作不支持条件 `kms:GrantIsForAWSResource`，也不应在 KMS 策略中用于控制执行 CreateCluster 的用户的 `kms:CreateGrant` 权限。 # 将 AWS Secrets Manager 密钥与 Amazon EKS 容器组（pod）结合使用 要将 Secrets Manager 中的密钥和 Parameter Store 中的参数显示为挂载在 Amazon EKS 容器组（pod）中的文件，您可以使用 [Kubernetes Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/) 的 AWS Secrets and Configuration Provider（ASCP）插件。 使用 ASCP，您可以在 Secrets Manager 中存储并管理密钥，然后通过 Amazon EKS 上运行的工作负载检索。您可以使用 IAM 角色和策略限制集群中特定 Kubernetes 容器组（pod）的密钥访问权限。ASCP 检索容器组身份并交换 IAM 角色的身份。ASCP 担任容器组（pod）的 IAM 角色，然后可以从授权该角色的 Secrets Manager 中检索密码。 如果对密钥使用 Secrets Manager 自动轮换，还可以使用 Secrets Store CSI Driver 轮换协调程序功能，确保从 Secrets Manager 中检索最新的密码。 **注意** 不支持 AWS Fargate（Fargate）节点组。 有关更多信息，请参阅 AWS Secrets Manager 用户指南中的[在 Amazon EKS 中使用 Secrets Manager 密钥](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html)。 # 所有 Kubernetes API 数据默认启用信封加密 对于运行 Kubernetes 1.28 或更高版本的 EKS 集群，Amazon Elastic Kubernetes Service（Amazon EKS）为所有 Kubernetes API 数据提供了默认信封加密。 信封加密可以保护在 Kubernetes API 服务器上存储的数据。例如，信封加密会保护诸如 `ConfigMaps` 之类的 Kubernetes 集群配置。信封加密不适用于节点或 EBS 卷上的数据。EKS 以前支持加密 Kubernetes 密钥，这种信封加密现已扩展到所有 Kubernetes API 数据。 这提供了一种托管式的默认体验，可以为 Kubernetes 应用程序实现深度防御，并且不需要您执行任何操作。 Amazon EKS 将 AWS [Key Management Service（KMS）](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)和 [Kubernetes KMS provider v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) 结合使用，借助由[亚马逊云科技拥有的密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)来提供这一额外的安全防护层，此外还提供了让您从 AWS KMS 自带[客户自主管理型密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)（CMK）的选项。 ## 了解信封加密 信封加密是一种加密明文数据的方法，在将数据发送到数据存储（etcd）之前会首先使用数据加密密钥（DEK）将数据加密，然后再使用根 KMS 密钥对 DEK 进行加密，而后者存储在一个远程集中管理的 KMS 系统（AWS KMS）中。这是一种深度防御策略，首先使用加密密钥（DEK）来保护数据，然后使用安全存储的单独加密密钥 [称为密钥加密密钥（KEK）] 来保护 DEK，从而增加另一层安全防护。 ## Amazon EKS 如何使用 KMS v2 和 AWS KMS 实现默认信封加密 Amazon EKS 使用 [KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) 为托管式 KBernetes 控制面板中的所有 API 数据实施默认信封加密，然后才会将其持久保存在 [etcd](https://etcd.io/docs/v3.5/faq/) 数据库中。集群 API 服务器在启动时会根据密钥种子和随机生成的数据组合来生成数据加密密钥（DEK）。此外，API 服务器在启动时还会调用 KMS 插件，使用来自 AWS KMS 的远程密钥加密密钥（KEK）来加密 DEK 种子。这是在 API 服务器启动和 KEK 轮换时执行的一次性调用。然后，API 服务器会缓存加密的 DEK 种子。在此之后，API 服务器将根据密钥派生函数（KDF），使用缓存的 DEK 种子生成其他一次性的 DEK。在这些生成的 DEK 中，每个都只能使用一次来加密单个 Kubernetes 资源，然后才会将资源存储在 etcd 中。通过使用 KMS v2 中的加密缓存 DEK 种子，在 API 服务器中加密 Kubernetes 资源的过程不仅性能更高，而且成本效益更好。 **默认情况下，此 KEK 由 AWS 拥有，但您可以从 AWS KMS 自带密钥。** 下图展示了 API 服务器启动时生成和加密 DEK 的过程。 ![\[图中展示了 API 服务器启动时生成和加密 DEK 的过程\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/security-generate-dek.png) 下面的简要示意图展示了在将 Kubernetes 资源存储到 etcd 之前对其进行加密的过程。 ![\[此简要示意图展示了在将 Kubernetes 资源存储到 etcd 之前对其进行加密的过程。\]](http://docs.aws.amazon.com/zh_cn/eks/latest/userguide/images/security-encrypt-request.png) ## 常见问题 ### 默认信封加密是如何提升 EKS 集群安全状况的？ 此功能可减少未加密元数据和客户内容的暴露面并缩短暴露时间。启用默认信封加密时，元数据和客户内容在存储到 etcd 之前，只会在 kube-apiserver 的内存中处于短暂未加密状态。kube-apiserver 的内存是通过 [Nitro 系统](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html)保护的。Amazon EKS 的托管式 Kubernetes 控制面板仅使用[基于 Nitro 的 EC2 实例](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html)。此类实例采用安全控制设计，可防止任何系统或人员访问其内存。 ### 我需要运行哪个版本的 Kubernetes 才能启用此功能？ 要启用默认信封加密，Amazon EKS 集群必须运行 Kubernetes 版本 1.28 或更高版本。 ### 如果我运行的 Kubernetes 集群版本不支持此功能，我的数据还安全吗？ 可以。在 AWS，[安全性是我们的第一要务](https://aws.amazon.com/security/)。我们所有的数字化转型和创新都以最高的安全运营实践为基石，并矢志不断提升改进。 无论运行的是哪个 Kubernetes 版本，存储在 etcd 中的所有数据都会在每个 EKS 集群进行磁盘级别加密。EKS 使用根密钥生成卷加密密钥，这些密钥由 EKS 服务托管。此外，每个 Amazon EKS 集群都使用集群专用的虚拟机在隔离的 VPC 中运行。得益于这种架构以及我们在运营安全方面的实践，Amazon EKS [通过了多项合规评级和标准认证](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html)，包括 SOC 1,2,3、PCI-DSS、ISO 和 HIPAA 资格等。无论是否使用默认信封加密功能，所有 EKS 集群都将始终遵循这些合规评级和标准。 ### Amazon EKS 中信封加密的工作原理是什么？ 集群 API 服务器在启动时会根据密钥种子和随机生成的数据组合来生成数据加密密钥（DEK）。此外，API 服务器在启动时还会调用 KMS 插件，使用来自 AWS KMS 的远程密钥加密密钥（KEK）来加密 DEK。这是在 API 服务器启动和 KEK 轮换时执行的一次性调用。然后，API 服务器会缓存加密的 DEK 种子。在此之后，API 服务器将根据密钥派生函数（KDF），使用缓存的 DEK 种子生成其他一次性的 DEK。在这些生成的 DEK 中，每个都只能使用一次来加密单个 Kubernetes 资源，然后才会将资源存储在 etcd 中。 但请注意，API 服务器还会进行其他调用来验证 AWS KMS 集成的运行状况和正常功能。这些额外的运行状况检查在 AWS CloudTrail 中可见。 ### 我是否需要执行任何操作或更改任何权限才能在 EKS 集群中使用此功能？ 不需要，您不需要执行任何操作。信封加密现已是 Amazon EKS 中的一个默认配置，已在所有运行 Kubernetes 1.28 或更高版本的集群中启用。AWS KMS 集成是由 AWS 管理的 Kubernetes API 服务器建立的。这意味着您无需配置任何权限即可开始为集群使用 KMS 加密。 ### 如何才能知道集群是否启用了默认信封加密？ 如果迁移到使用自己的 CMK，则会看到与集群关联的 KMS 密钥的 ARN。此外，您还可以查看与集群使用 CMK 相关的 AWS CloudTrail 事件日志。 如果集群使用的密钥由 AWS 拥有，则会在 EKS 控制台中提供详细信息（不包括密钥的 ARN）。 ### 如果在 Amazon EKS 中用于默认信封加密的密钥由 AWS 拥有，AWS 是否可以访问该密钥？ 不能。AWS 在 Amazon EKS 中执行严格的安全控制，可防止任何人访问用于保护 etcd 数据库中数据的任何明文加密密钥。这些安全措施也适用于由 AWS 拥有的 KMS 密钥。 ### 我现有的 EKS 集群是否启用了默认信封加密？ 如果您运行的是 Kubernetes 版本 1.28 或更高版本的 Amazon EKS 集群，则会为所有 Kubernetes API 数据启用信封加密。对于现有集群，Amazon EKS 使用 `eks:kms-storage-migrator` RBAC 集群角色将以前未在 etcd 中进行信封加密的数据迁移到这一新加密状态。 ### 如果我已在 EKS 集群中为密钥启用了信封加密，这意味着什么？ 如果您使用 KMS 中现有的客户自主管理型密钥（CMK）来进行 Kubernetes 密钥的信封加密，则该密钥将用作 KEK，用于对集群中的所有 Kubernetes API 数据类型进行信封加密。 ### 运行启用了默认信封加密的 EKS 集群会是否会产生额外的成本？ 如果您使用[亚马逊云科技拥有的密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)进行默认信封加密，则托管式的 Kubernetes 控制面板不会产生任何额外的成本。默认情况下，每个运行 Kubernetes 1.28 或更高版本的 EKS 集群都使用[由亚马逊云科技拥有的密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)。但如果您使用自己的 AWS KMS 密钥，则将正常的 [KMS 定价](https://aws.amazon.com/kms/pricing/)收费。 ### 使用我自己的 AWS KMS 密钥对集群中的 Kubernetes API 数据进行加密，将如何收费？ 您每月需要支付 1 美元来存储您创建或导入到 KMS 的任何自定义密钥。KMS 会对加密和解密请求收费。每个账户的免费套餐为每月 2 万个请求，超过免费套餐后，每月每 1 万个请求需支付 0.03 美元。这适用于账户的所有 KMS 使用量，因此在集群上使用自己的 AWS KMS 密钥时，成本将取决于其他集群或账户中 AWS 资源使用该密钥的情况。 ### 现在我使用客户自主管理型密钥（CMK）来进行所有 Kubernetes API 数据的信封加密，而不仅限于密钥，我的 KMS 成本是否会增加？ 不会。我们使用 KMS v2 来实现加密，显著减少了对 AWS KMS 的调用量，从而降低了与 CMK 相关的成本，无论 EKS 集群中是否有额外的 Kubernetes 数据需要加密或解密。 如上所述，生成的用于加密 Kubernetes 资源的 DEK 种子在使用远程 KEK 加密后，会存储在 Kubernetes API 服务器的本地缓存中。如果加密的 DEK 种子不在 API 服务器的缓存中，API 服务器将调用 AWS KMS 来加密 DEK 种子。然后 API 服务器会缓存加密的 DEK 种子，以备将来在集群中使用，从而不再需要调用 KMS。同样，对于解密请求，API 服务器将针对第一个解密请求调用 AWS KMS，然后缓存解密后的 DEK 种子并用于未来的解密操作。 有关更多信息，请参阅 GitHub 上 Kubernetes 增强功能中的 [KEP-3299: KMS v2 Improvements](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements)。 ### 我能否将同一 CMK 密钥用于多个 Amazon EKS 集群？ 可以。要重复使用某个密钥，可以在创建集群时将该 ARN 关联到集群，从而将其关联到同一区域内的集群。但如果要将同一 CMK 用于多个 EKS 集群，则应采取必要的措施来防止对该 CMK 的随意禁用。否则，关联到多个 EKS 集群的 CMK 被禁用将对这些集群产生更广泛的影响，具体取决于该密钥。 ### 如果启用默认信封加密后我的 CMK 不再可用，我的 EKS 集群会发生什么？ 如果禁用了某个 KMS 密钥，则将不能用于任何[加密操作](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations)。如果无法访问现有的 CMK，API 服务器将无法加密并持久保存任何新创建的 Kubernetes 对象，也无法解密 etcd 中存储的任何先前加密的 Kubernetes 对象。如果 CMK 被禁用，集群将立即进入运行不正常/性能降级状态，并且在您重新启用关联的 CMK 之前，我们将无法履行我们的[服务承诺](https://aws.amazon.com/eks/sla/)。 禁用 CMK 后，您将收到通知，提示 EKS 集群运行性能降级，并且需要在禁用 CMK 后 30 天内重新启用，才能确保成功恢复 Kubernetes 控制面板资源。 ### 如何确保我的 EKS 集群不受已禁用/删除 CMK 的影响？ 为确保 EKS 集群不受此类情况的影响，密钥管理员应使用遵循最低权限原则的 IAM 策略来管理 KMS 密钥操作权限，减少随意禁用或删除与 EKS 集群关联的密钥的风险。此外，您可以设置 [CloudWatch 警报](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html)来接收有关 CMK 状态的通知。 ### 如果重新启用 CMK，我的 EKS 集群会恢复吗？ 为确保成功恢复 EKS 集群，我们强烈建议您在禁用 CMK 后 30 天内重新启用。但是，是否能够成功恢复 EKS 集群，还取决于是否因集群处于运行不正常/性能降级状态时的自动 Kubernetes 升级导致了任何 API 更改中断。 ### 禁用 CMK 后，为什么我的 EKS 集群处于运行不正常/性能降级状态？ EKS 控制面板的 API 服务器将一个 DEK 密钥加密后缓存在 API 服务器内存中，并在对象创建/更新操作期间使用该密钥对所有对象进行加密，然后才会将对象存储在 etcd 中。从 etcd 检索现有对象时，API 服务器会使用同一缓存的 DEK 密钥来解密 Kubernetes 资源对象。如果您禁用了 CMK，由于 API 服务器的内存中缓存了该 DEK 密钥，API 服务器将不会立即看到任何影响。但在 API 服务器实例重启时，将不会有缓存的 DEK，需要调用 AWS KMS 进行加密和解密操作。由于没有 CMK，此过程将会失败，并显示 KMS\$1KEY\$1DISABLED 错误代码，导致 API 服务器不能成功启动。 ### 如果我删除了 CMK，我的 EKS 集群会发生什么情况？ 删除与 EKS 集群关联的 CMK 密钥会使其运行状况降级，无法恢复。如果没有现有的 CMK，API 服务器将不再能够加密并持久保存任何新 Kubernetes 对象，也无法解密 etcd 数据库中存储的任何先前加密的 Kubernetes 对象。只有当您确信不再需要使用该 EKS 集群时，才应删除 EKS 集群的 CMK 密钥。 请注意，如果找不到 CMK（KMS\$1KEY\$1NOT\$1FOUND）或与集群关联的 CMK 授权被撤销（KMS\$1GRANT\$1REVOKED），则集群将无法恢复。有关集群运行状况和错误代码的更多信息，请参阅[集群运行状况常见问题解答和错误代码以及解析路径](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status)。 ### 对于因禁用或删除了 CMK 而性能降级/运行不正常的 EKS 集群，我是否仍需要付费？ 可以。尽管 EKS 控制面板在 CMK 被禁用时将无法使用，但在客户将 EKS 集群删除之前，AWS 仍将运行分配给该集群的专用基础设施资源。此外，发生这种情况时，我们的[服务承诺](https://aws.amazon.com/eks/sla/)将不适用，因为这是客户的自愿行为或不作为阻碍了 EKS 集群的正常运行和操作。 ### 当我的 EKS 集群因禁用 CMK 而处于运行不正常/性能降级状态时，能否自动升级？ 可以。但是，如果集群禁用了 CMK，您可在 30 天内将其重新启用。在此 30 天内，Kubernetes 集群不会自动升级。如果您未在此期限内重新启用 CMK，则集群将按照 EKS 中的 Kubernetes 版本生命周期，在此期限届满时自动升级到提供标准支持的下一版本（n\$11）。 我们强烈建议您在意识到集群受影响时尽快重新启用被禁用的 CMK。请注意，尽管 EKS 会自动升级这些受影响的集群，但不能保证能成功恢复集群，尤其是在集群经过多次自动升级的情况下，因为这可能包括 Kubernetes API 更改以及 API 服务器引导过程中的意外行为。 ### 是否可以使用 KMS 密钥别名？ 可以。Amazon EKS [支持使用 KMS 密钥别名](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents)。别名是一个易记的[亚马逊云科技 KMS 密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)名称。例如，您可以用别名将 KMS 密钥称为 **my-key**，而不是 ** `1234abcd-12ab-34cd-56ef-1234567890ab` **。 ### 是否仍可使用自己的 Kubernetes 备份解决方案备份和恢复集群资源？ 可以。您可以使用 Kubernetes 备份解决方案（例如 [Velero](https://velero.io/)）来进行 Kubernetes 集群的灾难恢复、数据迁移和数据保护。如果您运行的 Kubernetes 备份解决方案会通过 API 服务器访问集群资源，则应用程序检索到的任何数据都将在到达客户端之前进行解密，以便您将集群资源恢复到其他 Kubernetes 集群中。 # Amazon EKS 自动模式的安全注意事项 本主题介绍了 Amazon EKS 自动模式的安全架构、控制和最佳实践。随着组织大规模部署容器化应用程序，保持良好的安全态势变得越来越复杂。EKS 自动模式实施自动化的安全控制并与 AWS 安全服务集成，以帮助您保护集群基础设施、工作负载和数据。通过强制节点生命周期管理和自动补丁部署等内置安全功能，EKS 自动模式可帮助您在减少运营开销的同时保持遵循安全最佳实践。 在继续阅读本主题之前，请确保您熟悉 EKS 自动模式的基本概念，并已检查了在集群上启用 EKS 自动模式的先决条件。有关 Amazon EKS 安全性的一般信息，请参阅 [Amazon EKS 中的安全性](security.md)。 Amazon EKS 自动模式以 Amazon EKS 现有的安全性为基础，同时为 EC2 托管式实例引入了额外的自动安全控制措施。 ## API 安全性和身份验证 Amazon EKS 自动模式使用 AWS 平台安全机制来保护并对 Amazon EKS API 调用进行身份验证。 + 对 Kubernetes API 的访问通过与 AWS IAM 身份集成的 EKS 访问条目进行保护。 + 有关更多信息，请参阅 [使用 EKS 访问条目向 IAM 用户授予 Kubernetes 访问权限](access-entries.md)。 + 客户可以通过配置 EKS 访问条目来实施对 Kubernetes API 端点的精细访问控制。 ## 网络安全 Amazon EKS 自动模式支持多层网络安全性： + **VPC 集成** + 在 Amazon Virtual Private Cloud（VPC）中运行 + 支持自定义 VPC 配置和子网布局 + 支持集群组件之间的私有联网 + 有关更多信息，请参阅[管理 Amazon Virtual Private Cloud 的安全责任](https://docs.aws.amazon.com/vpc/latest/userguide/security.html) + **网络策略** + 对 Kubernetes 网络策略的原生支持 + 定义精细网络流量规则的功能 + 有关更多信息，请参阅 [通过 Kubernetes 网络策略限制容器组（pod）流量](cni-network-policy.md) ## EC2 托管式实例安全性 Amazon EKS 自动模式使用以下安全控制措施运行 EC2 托管式实例： ### EC2 安全性 + EC2 托管式实例保持了 Amazon EC2 的安全功能。 + 有关 EC2 托管式实例的更多信息，请参阅 [Amazon EC2 中的安全性](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)。 ### 实例生命周期管理 对于由 EKS 自动模式运行的 EC2 托管式实例，最长生命周期为 21 天。Amazon EKS 自动模式会自动终止超过此生命周期的实例。此生命周期限制有助于防止配置偏差并保持安全态势。 ### 数据保护 + Amazon EC2 实例存储直接挂载到实例并进行了加密。有关更多信息，请参阅 [Amazon EC2 中的数据保护](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html)。 + EKS 自动模式负责管理在创建时挂载到 EC2 实例的卷，包括根卷和数据卷。EKS 自动模式并不完全管理使用 Kubernetes 持久性存储功能创建的 EBS 卷。 ### 补丁管理 + Amazon EKS 自动模式会自动将补丁应用于托管式实例。 + 这些补丁包括： + 操作系统更新 + 安全补丁 + Amazon EKS 自动模式组件 **注意** 客户继续负责保护和更新在这些实例上运行的工作负载。 ### 访问控制 + 直接实例访问权限受到限制： + 不支持 SSH 访问。 + 不支持 AWS Systems Manager 会话管理器（SSM）。 + 管理操作通过 Amazon EKS API 和 Kubernetes API 执行。 ## 自动化的资源管理 Amazon EKS 自动模式并不完全管理使用 Kubernetes 持久性存储功能创建的 Amazon Elastic Block Store（Amazon EBS）卷。EKS 自动模式也不会管理弹性负载均衡（ELB）。Amazon EKS 自动模式可自动执行这些资源的例行任务。 ### 存储安全性 + AWS 建议您为 Kubernetes 持久性存储功能预置的 EBS 卷启用加密。有关更多信息，请参阅 [创建存储类](create-storage-class.md)。 + 使用 AWS KMS 的静态加密 + 您可以配置 AWS 账户对您创建的新 EBS 卷和快照副本进行加密。有关更多信息，请参阅《Amazon EBS 用户指南》中的 [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)。 + 有关更多信息，请参阅 [Security in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html)。 ### 负载均衡器安全性 + 自动配置负载均衡器 + 通过 AWS Certifice Manager 集成来管理 SSL/TLS 证书 + 通过安全组自动化实施负载均衡器访问控制 + 有关更多信息，请参阅 [Security in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html)。 ## 安全最佳实践 下一部分介绍 Amazon EKS 自动模式的安全最佳实践。 + 定期检查 AWS IAM 策略和 EKS 访问条目。 + 为工作负载实施最低权限访问模式。 + 通过 AWS CloudTrail 和 Amazon CloudWatch 监控集群活动。有关更多信息，请参阅[日志 API 调用作为 AWS CloudTrail 事件](logging-using-cloudtrail.md) 和[使用 Amazon CloudWatch 监控集群数据](cloudwatch.md)。 + 使用 AWS Security Hub 进行安全态势评估。 + 实施适合工作负载的容器组安全标准。 # EKS 功能的安全注意事项 本主题涵盖了 EKS 功能的重要安全注意事项，包括 IAM 角色配置、Kubernetes 权限、多集群部署的架构模式和跨账户 AWS 资源管理。 EKS 功能使用 IAM 角色、EKS 访问条目和 Kubernetes RBAC 的组合来提供对 AWS 服务、集群内 Kubernetes 资源以及与 AWS CodeConnections、AWS Secrets Manager 和其他 AWS 服务的集成的安全访问。 ## 功能 IAM 角色 创建功能时，您将提供一个 IAM 功能角色，EKS 使用该角色代表您执行操作。此角色必须满足以下要求： + 与集群和功能资源位于同一 AWS 账户中 + 拥有信任策略，允许 `capabilities.eks.amazonaws.com` 服务主体代入该角色 + 拥有适合功能类型和使用案例的 IAM 权限，具体取决于您的需求。有关所需 IAM 权限的详细信息，请参阅[使用 AWS CodeConnections 连接到 Git 存储库](integration-codeconnections.md)、[使用 AWS Secrets Manager 管理应用程序密钥](integration-secrets-manager.md)和[配置 ACK 权限](ack-permissions.md) 最佳做法是考虑您的特定使用案例所需的权限范围，并仅授予满足您的要求所必需的权限。例如，在使用 Kube Resource Orchestrator 的 EKS 功能时，可能不需要 IAM 权限，而在使用 AWS Controllers for Kubernetes 的 EKS 功能时，您可以授予对一项或多项 AWS 服务的完全访问权限。 **重要** 虽然某些使用案例可能需要使用广泛的管理权限，但要遵循最低权限原则，即仅授予特定使用案例所需的最低 IAM 权限，使用 ARN 和条件键而不是使用通配符权限来限制对特定资源的访问。 有关创建和配置功能 IAM 角色的详细信息，请参阅 [Amazon EKS 功能 IAM 角色](capability-role.md)。 ## EKS 访问条目 当您使用 IAM 角色创建功能时，Amazon EKS 会在您的集群上自动为该角色创建访问条目。此访问条目授予功能基准 Kubernetes 权限，使其能够运行。 **注意** 将为创建该功能所在的集群创建访问条目。要将 Argo CD 部署到远程集群，您必须在这些集群上创建访问条目，使其具有部署和管理应用程序的 Argo CD 功能的相应权限。 访问条目包括： + 作为主体的 IAM 角色 ARN + 授予基准 Kubernetes 权限的功能特定访问条目策略 + 基于功能类型的适当范围（集群范围或命名空间范围） **注意** 对于 Argo CD，将向功能配置中指定的命名空间授予命名空间范围的权限（默认为 `argocd`）。 **按功能划分的默认访问条目策略** 每种功能类型都向功能角色授予所需的权限，设置如下所示的不同默认访问条目策略： **kro** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`（集群范围） 授予监视和管理 ResourceGraphDefinitions 以及创建由 RGD 定义的自定义资源实例的权限。 **ACK** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`（集群范围） 授予在所有命名空间中创建、读取、更新和删除 ACK 自定义资源的权限。 **Argo CD** + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`（集群范围） 授予 Argo CD 的集群级别权限，以便发现资源，并管理集群范围内的对象。 + `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`（命名空间范围） 授予 Argo CD 部署和管理应用程序的命名空间级权限。范围限定为功能配置中指定的命名空间（默认为 `argocd`）。 有关更多详细信息，请参阅[检查访问策略权限](access-policy-permissions.md)。 ## 其他 Kubernetes 权限 某些功能可能需要除默认访问条目策略之外的其他 Kubernetes 权限。您可以使用以下任一方法授予这些权限： + **访问条目策略**：将其他托管策略与访问条目相关联 + **Kubernetes RBAC**：为该功能的 Kubernetes 用户创建 `Role` 或 `ClusterRole` 绑定 **ACK 密钥读取器权限** 某些 ACK 控制器需要读取 Kubernetes 密钥才能检索数据库密码等敏感数据。以下 ACK 控制器需要密钥读取权限： + `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager` 要授予密钥读取权限，请执行以下操作： 1. 将 `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` 访问条目策略与功能的访问条目相关联 1. 将策略范围限定到特定的命名空间，ACK 资源将在其中引用密钥，或者授予整个集群的访问权限 **重要** 密钥读取权限的范围限定为您在关联访问条目策略时指定的命名空间。这允许您限制该功能可以访问的密钥。 **kro 任意资源权限** kro 需要权限才能创建和管理 ResourceGraphDefinitions 中定义的资源。默认情况下，kro 只能自行监视和管理 RGD。 要授予 kro 创建资源的权限，请执行以下操作： **选项 1：访问条目策略** 将预定义的访问条目策略（如 `AmazonEKSAdminPolicy` 或 `AmazonEKSEditPolicy`）与功能的访问条目相关联。 **选项 2：Kubernetes RBAC** 创建一个向该功能的 Kubernetes 用户授予必要权限的 `ClusterRoleBinding`： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kro-cluster-admin subjects: - kind: User name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io ``` **注意** kro 的 Kubernetes 用户名遵循以下模式：`arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO` 会话名称 `/KRO`（大写字母）由 EKS kro 功能自动设置。 ## 功能所需的 IAM 权限 **kro（Kube Resource Orchestrator）** 不需要 IAM 权限。您可以创建没有附加策略的功能角色。kro 只需要 Kubernetes RBAC 权限。 **ACK（AWS Controllers for Kubernetes）** 需要权限才能管理 ACK 将创建和管理的 AWS 资源。您应根据自己的要求将权限范围限定为特定服务、操作和资源。有关配置 ACK 权限的详细信息，包括使用 IAM 角色选择器的生产最佳实践，请参阅[配置 ACK 权限](ack-permissions.md)。 **Argo CD** 默认情况下，不需要 IAM 权限。以下功能可能需要可选权限： + AWS Secrets Manager：如果在 Secrets Manager 中存储 Git 存储库凭证 + AWS CodeConnections：如果使用 CodeConnections 进行 Git 存储库身份验证 + Amazon ECR：如果使用在 Amazon ECR 中以 OCI 格式存储的 Helm 图表 ## 安全最佳实践 ### IAM 最低权限 仅授予您的功能资源您的使用案例所需的权限。这并不意味着在需要时您无法向自己的功能授予广泛的管理权限。在这种情况下，您应适当地管理对这些资源的访问权限。 **功能角色**： + **ACK**：在可能的情况下，根据使用案例和要求，将 IAM 权限限制为仅能访问团队所需的特定 AWS 服务和资源 + **Argo CD**：限制对特定的 Git 存储库和 Kubernetes 命名空间的访问权限 + **kro**：需要信任策略的功能角色，但不需要 IAM 权限（仅使用集群 RBAC） **示例**：为特定资源或资源组指定模式，而非 `"Resource": "*"`。 ``` "Resource": [ "arn:aws:s3:::my-app-*", "arn:aws:rds:us-west-2:111122223333:db:prod-*" ] ``` 使用 IAM 条件键进一步限制访问权限： ``` "Condition": { "StringEquals": { "aws:ResourceTag/Environment": "production" } } ``` 有关其他 IAM 配置信息，请参阅每项功能的注意事项部分。 ### Argo CD 密钥的命名空间隔离 托管 Argo CD 功能可以访问其配置的命名空间中的所有 Kubernetes 密钥（默认：`argocd`）。要保持最佳安全状况，请遵循以下命名空间隔离实践： + 在 Argo CD 命名空间中只保留 Argo CD 相关的密钥 + 避免将不相关的应用程序密钥存储在与 Argo CD 相同的命名空间中 + 使用单独的命名空间来存放 Argo CD 操作不需要的应用程序密钥 这种隔离可确保 Argo CD 的密钥访问权限仅限于 Git 存储库身份验证和其他 Argo CD 特定操作所需的凭证。 ### Kubernetes RBAC 控制哪些用户和服务账户可以创建和管理功能资源。使用适当的 RBAC 策略在专用命名空间中部署功能资源是最佳实践。 示例：与 ACK 配合使用 RBAC 角色，允许在 `app-team` 命名空间中管理 S3 存储桶资源： ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: ack-s3-manager namespace: app-team rules: - apiGroups: ["s3.services.k8s.aws"] resources: ["buckets"] verbs: ["get", "list", "create", "update", "delete"] ``` ### 审计日志记录 **CloudTrail**：所有 EKS 功能 API 操作（创建、更新、删除）都将记录到 AWS CloudTrail 中。 启用 CloudTrail 日志记录来跟踪： + 哪些用户创建或修改了功能 + 功能配置发生更改时 + 哪些功能角色在使用中 ### 网络访问和 VPC 端点 #### 私有 Argo CD API 访问权限 您可以通过将一个或多个 VPC 端点与托管的 Argo CD 端点关联，来限制对 Argo CD API 服务器的访问。这样就可以在您的 VPC 内进行私有连接，而无需通过公共互联网。VPC 端点提供对 Argo CD Web UI 和 Argo CD API 的访问（包括 CLI 访问）。 **注意** 连接到托管的 Argo CD API 端点的 VPC 端点（使用 eks-capabilities.*region*.amazonaws.com）不支持 VPC 端点策略。 #### 部署到私有集群 Argo CD 功能可以将应用程序部署到完全私有的 EKS 集群，无需进行 VPC 对等互连或复杂的网络配置，从而提供显著的运营优势。但是，在设计此架构时，请考虑 Argo CD 将从 Git 存储库（可能是公有存储库）中拉取配置并将其应用于您的私有集群。 请确保： + 使用私有 Git 存储库处理敏感工作负载 + 实施适当的 Git 仓库访问控制和身份验证 + 先通过拉取请求查看和批准更改，再进行合并 + 考虑使用 Argo CD 的同步窗口来控制部署的时间 + 监控 Argo CD 审计日志中是否有未经授权的配置更改 ### 合规 EKS 功能是完全托管的，并已获得 Amazon EKS 的合规性认证。 有关更多信息，请参阅[按合规性计划划分的范围内的 AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)。 ## 后续步骤 + [配置 ACK 权限](ack-permissions.md)：为 ACK 配置 IAM 权限 + [配置 kro 权限](kro-permissions.md)：为 kro 配置 Kubernetes RBAC + [配置 Argo CD 权限](argocd-permissions.md)：为 Argo CD 配置 Identity Center 集成 + [EKS 功能问题排查](capabilities-troubleshooting.md)：对安全和权限问题进行问题排查 # 适用于 Amazon EKS 的身份和访问管理 AWS Identity and Access Management（IAM）是一项 AWS 服务，可帮助管理员安全地控制对 AWS 资源的访问。IAM 管理员控制谁可以通过*身份验证*（登录）和*授权*（具有权限）使用 Amazon EKS 资源。IAM 是一项可以免费使用的 AWS 服务。 ## 受众 您使用 AWS Identity and Access Management（IAM）的方式有所不同，具体取决于您在 Amazon EKS 中完成的工作。 **服务用户** – 如果您使用 Amazon EKS 服务来执行任务，则您的管理员会为您提供所需的凭证和权限。随着您使用更多 Amazon EKS 功能来完成工作，您可能需要额外权限。了解如何管理访问权限有助于您向管理员请求适合的权限。如果您无法访问 Amazon EKS 中的功能，请参阅 [IAM 故障排除](security-iam-troubleshoot.md)。 **服务管理员** – 如果您在公司负责管理 Amazon EKS 资源，您可能对 Amazon EKS 具有完全访问权限。您有责任确定您的服务用户应访问哪些 Amazon EKS 功能和资源。然后，您必须向 IAM 管理员提交请求以更改服务用户的权限。请查看该页面上的信息以了解 IAM 的基本概念。要了解有关您的公司如何将 IAM 与 Amazon EKS 搭配使用的更多信息，请参阅 [Amazon EKS 如何与 IAM 配合使用](security-iam-service-with-iam.md)。 **IAM 管理员** – 如果您是 IAM 管理员，您可能希望了解如何编写策略以管理对 Amazon EKS 的访问的详细信息。要查看您可在 IAM 中使用的 Amazon EKS 基于身份的策略示例，请参阅 [Amazon EKS 基于身份的策略示例](security-iam-id-based-policy-examples.md)。 ## 使用身份进行身份验证 身份验证是您使用身份凭证登录 AWS 的方法。您必须作为 AWS 账户根用户、IAM 用户或通过代入 IAM 角色进行*身份验证*（登录到 AWS）。 您可以使用通过身份源提供的凭证以联合身份登录到 AWS。AWSIAM Identity Center（IAM Identity Center）用户、您公司的单点登录身份验证以及您的 Google 或 Facebook 凭证都是联合身份的示例。当您以联合身份登录时，您的管理员以前使用 IAM 角色设置了身份联合验证。当您使用联合身份验证访问 AWS 时，您就是在间接代入角色。 根据您的用户类型，您可以登录 AWS 管理控制台 或 AWS 访问门户。有关登录到 AWS 的更多信息，请参阅《AWS Sign-In 用户指南》**中的[如何登录到您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。 如果您以编程方式访问 AWS，则 AWS 将提供软件开发工具包（SDK）和命令行界面（CLI），以便使用您的凭证以加密方式签署您的请求。如果您不使用 AWS 工具，则必须自行对请求签名。有关使用推荐的方法自行签署请求的更多信息，请参阅《IAM 用户指南》**中的[签署 AWS API 请求](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html)。 无论使用何种身份验证方法，您可能需要提供其他安全信息。例如，AWS 建议您使用多重身份验证（MFA）来提高账户的安全性。要了解更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[多重身份验证](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)和《IAM 用户指南》**中的[在 AWS 中使用多重身份验证（MFA）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)。 ### AWS 账户根用户 在创建 AWS 账户时，您首先需要使用一个对账户中所有 AWS 服务和资源拥有完全访问权限的登录身份。此身份称为 AWS 账户*根用户*，使用您创建账户时所用的电子邮件地址和密码登录，即可获得该身份。强烈建议您不要使用根用户执行日常任务。保护好根用户凭证，并使用这些凭证来执行仅根用户可以执行的任务。有关需要您以根用户身份登录的任务的完整列表，请参阅*《IAM 用户指南》*中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 ### IAM 用户和群组 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)是 AWS 账户内对某个人员或应用程序具有特定权限的一个身份。在可能的情况下，我们建议使用临时凭证，而不是创建具有长期凭证（如密码和访问密钥）的 IAM 用户。但是，如果您有一些特定的使用案例需要长期凭证以及 IAM 用户，建议您轮换访问密钥。有关更多信息，请参阅《IAM 用户指南》**中的[对于需要长期凭证的使用案例，应在需要时更新访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)。 [IAM 组](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)是一个指定一组 IAM 用户的身份。您不能使用组的身份登录。您可以使用组来一次性为多个用户指定权限。如果有大量用户，使用组可以更轻松地管理用户权限。例如，您可能具有一个名为 *IAMAdmins* 的组，并为该组授予权限以管理 IAM 资源。 用户与角色不同。用户唯一地与某个人员或应用程序关联，而角色旨在让需要它的任何人代入。用户具有永久的长期凭证，而角色提供临时凭证。要了解更多信息，请参阅《IAM 用户指南》**中的[何时创建 IAM 用户（而不是角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)。 ### IAM 角色 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)是 AWS 账户中具有特定权限的实体。它类似于 IAM 用户，但与特定人员不关联。您可以通过[切换角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)，在 AWS 管理控制台 中暂时代入 IAM 角色。可以通过调用 AWS CLI 或 AWS API 操作或使用自定义 URL 来代入角色。有关使用角色的方法的更多信息，请参阅《IAM 用户指南》中的[使用 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)**。 具有临时凭证的 IAM 角色在以下情况下很有用： + **联合用户访问**：要向联合身份分配权限，请创建角色并为角色定义权限。当联合身份进行身份验证时，该身份将与角色相关联并被授予由此角色定义的权限。有关联合身份验证的角色的信息，请参阅《IAM 用户指南》中的[为第三方身份提供者创建角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)**。如果您使用 IAM Identity Center，则需要配置权限集。为控制您的身份在进行身份验证后可以访问的内容，IAM Identity Center 将权限集与 IAM 中的角色相关联。有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[权限集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)。 + **临时 IAM 用户权限**：IAM 用户可代入 IAM 用户或角色，以暂时获得针对特定任务的不同权限。 + **跨账户访问**：您可以使用 IAM 角色以允许不同账户中的某个人（可信主体）访问您的账户中的资源。角色是授予跨账户访问权限的主要方式。但是，对于某些 AWS 服务，您可以将策略直接附加到资源（而不是使用角色作为代理）。要了解用于跨账户访问的角色和基于资源的策略之间的差别，请参阅 *IAM 用户指南*中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 + **跨服务访问**：某些 AWS 服务使用其它 AWS 服务中的功能。例如，当您在某个服务中进行调用时，该服务通常会在 Amazon EC2 中运行应用程序或在 Simple Storage Service（Amazon S3）中存储对象。服务可能会使用发出调用的主体的权限、使用服务角色或使用服务相关角色来执行此操作。 + **转发访问会话（FAS）**：当您使用 IAM 用户或角色在 AWS 中执行操作时，您将被视为主体。使用某些服务时，您可能会执行一个操作，然后此操作在其他服务中启动另一个操作。FAS 使用主体调用 AWS 服务的权限，结合请求的 AWS 服务，向下游服务发出请求。只有在服务收到需要与其它 AWS 服务或资源交互才能完成的请求时，才会发出 FAS 请求。在这种情况下，您必须具有执行这两项操作的权限。有关发出 FAS 请求时的策略详情，请参阅[转发访问会话](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)。 + **服务角色** - 服务角色是服务代表您在您的账户中执行操作而分派的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。IAM 管理员可以在 IAM 中创建、修改和删除服务角色。有关更多信息，请参阅 *IAM 用户指南*中的[创建向 AWS 服务委派权限的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)。 + **服务相关角色** – 服务相关角色是与 AWS 服务关联的一种服务角色。服务可以代入代表您执行操作的角色。服务相关角色显示在您的 AWS 账户中，并由该服务拥有。IAM 管理员可以查看但不能编辑服务关联角色的权限。 + **在 Amazon EC2 上运行的应用程序**：您可以使用 IAM 角色管理在 EC2 实例上运行并发出 AWS CLI 或 AWS API 请求的应用程序的临时凭证。这优先于在 EC2 实例中存储访问密钥。要将 AWS 角色分配给 EC2 实例并使其对该实例的所有应用程序可用，您可以创建一个附加到实例的实例配置文件。实例配置文件包含角色，并使 EC2 实例上运行的程序能够获得临时凭证。有关更多信息，请参阅《IAM 用户指南》中的[使用 IAM 角色为 Amazon EC2 实例上运行的应用程序授予权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)**。 要了解是使用 IAM 角色还是 IAM 用户，请参阅*IAM 用户指南*中的[何时创建 IAM 角色（而不是用户）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)。 ## 使用策略管理访问 您将创建策略并将其附加到 AWS 身份或资源，以控制 AWS 中的访问。策略是 AWS 中的对象；在与身份或资源相关联时，策略定义它们的权限。在主体（用户、根用户或角色会话）发出请求时，AWS 将评估这些策略。策略中的权限确定是允许还是拒绝请求。大多数策略在 AWS 中存储为 JSON 文档。有关 JSON 策略文档的结构和内容的更多信息，请参阅 *IAM 用户指南*中的 [JSON 策略概览](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。 管理员可以使用 AWS JSON 策略来指定谁有权访问什么内容。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 默认情况下，用户和角色没有权限。要授予用户对所需资源执行操作的权限，IAM 管理员可以创建 IAM 策略。管理员随后可以向角色添加 IAM 策略，用户可以代入角色。 IAM 策略定义操作的权限，无关乎您使用哪种方法执行操作。例如，假设您有一个允许 `iam:GetRole` 操作的策略。具有该策略的用户可以从 AWS 管理控制台、AWS CLI 或 AWS API 获取角色信息。 ### 基于身份的策略 基于身份的策略是可附加到身份（如 IAM 用户、用户组或角色）的 JSON 权限策略文档。这些策略控制用户和角色可在何种条件下对哪些资源执行哪些操作。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[创建 IAM 策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 基于身份的策略可以进一步归类为*内联策略*或*托管策略*。内联策略直接嵌入单个用户、组或角色中。托管式策略是可以附加到 AWS 账户中的多个用户、组和角色的独立策略。托管式策略包括 AWS 托管式策略和客户托管式策略。要了解如何在托管式策略和内联策略之间进行选择，请参阅 *IAM 用户指南*中的[在托管式策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)。 ### 基于资源的策略 基于资源的策略是附加到资源的 JSON 策略文档。基于资源的策略的示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。对于在其中附加策略的资源，策略定义指定主体可以对该资源执行哪些操作以及在什么条件下执行。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。主体可以包括账户、用户、角色、联合用户或 AWS 服务。 基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用来自 IAM 的 AWS 托管式策略。 ### 访问控制列表（ACL） 访问控制列表（ACL）控制哪些主体（账户成员、用户或角色）有权访问资源。ACL 与基于资源的策略类似，但它们不使用 JSON 策略文档格式。 Amazon S3、AWS WAF 和 Amazon VPC 是支持 ACL 的服务示例。要了解有关 ACL 的更多信息，请参阅《Amazon Simple Storage Service 开发人员指南》**中的[访问控制列表（ACL）概览](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。 ### 其他策略类型 AWS 支持额外的、不太常用的策略类型。这些策略类型可以设置更常用的策略类型向您授予的最大权限。 + **权限边界**：权限边界是一个高级特征，用于设置基于身份的策略可以为 IAM 实体（IAM 用户或角色）授予的最大权限。您可为实体设置权限边界。这些结果权限是实体基于身份的策略及其权限边界的交集。在 `Principal` 中指定用户或角色的基于资源的策略不受权限边界限制。任一项策略中的显式拒绝将覆盖允许。有关权限边界的更多信息，请参阅*IAM 用户指南*中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。 + **服务控制策略 (SCP)** – SCP 是指定 AWS Organizations 中的组织或组织单元 (OU) 的最大权限的 JSON 策略。AWSOrganizations 是一个服务，用于对您的企业拥有的多个 AWS 账户进行分组和集中管理。如果在组织内启用了所有特征，则可对任意或全部账户应用服务控制策略（SCP）。SCP 限制成员账户中实体的权限，包括每个 AWS 账户根用户。有关组织和 SCP 的更多信息，请参阅《AWS Organizations 用户指南》**中的 [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 + **会话策略**：会话策略是当您以编程方式为角色或联合用户创建临时会话时作为参数传递的高级策略。结果会话的权限是用户或角色的基于身份的策略和会话策略的交集。权限也可以来自基于资源的策略。任一项策略中的显式拒绝将覆盖允许。有关更多信息，请参阅 *IAM 用户指南*中的[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。 ### 多个策略类型 当多个类型的策略应用于一个请求时，生成的权限更加复杂和难以理解。要了解 AWS 如何确定在涉及多种策略类型时是否允许请求，请参阅 *IAM 用户指南*中的[策略评测逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。 # Amazon EKS 如何与 IAM 配合使用 在使用 IAM 管理对 Amazon EKS 的访问权限之前，您应该了解哪些 IAM 功能可用于 Amazon EKS。要大致了解 Amazon EKS 和其他AWS服务如何与 IAM 一起使用，请参阅 *IAM 用户指南*中的[与 IAM 一起使用的AWS服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 **Topics** + [Amazon EKS 基于身份的策略](#security-iam-service-with-iam-id-based-policies) + [Amazon EKS 基于资源的策略](#security-iam-service-with-iam-resource-based-policies) + [基于 Amazon EKS 标签的授权](#security-iam-service-with-iam-tags) + [Amazon EKS IAM 角色](#security-iam-service-with-iam-roles) ## Amazon EKS 基于身份的策略 通过使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源以及允许或拒绝操作的条件。Amazon EKS 支持特定的操作、资源和条件键。要了解在 JSON 策略中使用的所有元素，请参阅《IAM 用户指南》中的 [IAM JSON 策略元素参考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)**。 ### 操作 管理员可以使用 AWS JSON 策略来指定谁有权访问什么内容。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。策略操作通常与关联的 AWS API 操作同名。有一些例外情况，例如没有匹配 API 操作的*仅限权限*操作。还有一些操作需要在策略中执行多个操作。这些附加操作称为*相关操作*。 在策略中包含操作以授予执行关联操作的权限。 Amazon EKS 中的策略操作在操作前面使用以下前缀：`eks:`。例如，要授予某人获取关于 Amazon EKS 集群的描述性信息的权限，您应将 `DescribeCluster` 操作纳入其策略中。策略语句必须包含 `Action` 或 `NotAction` 元素。 要在单个语句中指定多项操作，请使用逗号将它们隔开，如下所示： ``` "Action": ["eks:action1", "eks:action2"] ``` 您也可以使用通配符 （\$1) 指定多个操作。例如，要指定以单词 `Describe` 开头的所有操作，包括以下操作： ``` "Action": "eks:Describe*" ``` 要查看 Amazon EKS 操作的列表，请参阅《服务授权参考》**中的 [Amazon Elastic Kubernetes Service 定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。 ### 资源 管理员可以使用 AWS JSON 策略来指定谁有权访问什么内容。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。 `Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。语句必须包含 `Resource` 或 `NotResource` 元素。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于支持特定资源类型（称为*资源级权限*）的操作，您可以执行此操作。 对于不支持资源级权限的操作（如列出操作），请使用通配符 (\$1) 指示语句应用于所有资源。 ``` "Resource": "*" ``` Amazon EKS 集群资源具有以下 ARN。 ``` arn:aws:eks:region-code:account-id:cluster/cluster-name ``` 有关 ARN 格式的更多信息，请参阅 [Amazon 资源名称 (ARN) 和 AWS 服务命名空间](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)。 例如，要在语句中指定名为 *my-cluster* 的集群，请使用以下 ARN： ``` "Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster" ``` 要指定属于特定账户和 AWS 区域的所有集群，请使用通配符（\$1）： ``` "Resource": "arn:aws:eks:region-code:111122223333:cluster/*" ``` 无法对特定资源执行某些 Amazon EKS 操作，例如用于创建资源的操作。在这些情况下，您必须使用通配符（\$1)。 ``` "Resource": "*" ``` 要查看 Amazon EKS 资源类型及其 ARN 的列表，请参阅《服务授权参考》**中的 [Amazon Elastic Kubernetes Service 定义的资源](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies)。要了解您可以在哪些操作中指定每个资源的 ARN，请参阅 [Amazon Elastic Kubernetes Service 定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。 ### 条件键 Amazon EKS 定义了自己的一组条件键，还支持使用一些全局条件键。要查看所有 AWS 全局条件键，请参阅《IAM 用户指南》**中的 [AWS 全局条件上下文键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。 在将 OpenID Connect 提供商与集群关联时，您可以设置条件键。有关更多信息，请参阅 [示例 IAM policy](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy)。 所有 Amazon EC2 操作都支持 `aws:RequestedRegion` 和 `ec2:Region` 条件键。有关更多信息，请参阅[示例：限制对特定 AWS 区域的访问](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)。 有关 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)。要了解您可以对哪些操作和资源使用条件键，请参阅 [Amazon Elastic Kubernetes Service 定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。 ### 示例 要查看 Amazon EKS 基于身份的策略的示例，请参阅 [Amazon EKS 基于身份的策略示例](security-iam-id-based-policy-examples.md)。 创建 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`。 有关使用 ConfigMap 的更多信息，请参阅 [向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)。 ## Amazon EKS 基于资源的策略 Amazon EKS 不支持基于资源的策略。 ## 基于 Amazon EKS 标签的授权 您可以将标签附加到 Amazon EKS 资源，或者在请求中将标签传递给 Amazon EKS。要基于标签控制访问，您需要使用 `aws:ResourceTag/key-name ``aws:RequestTag/key-name ` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。有关标记 Amazon EKS 资源的更多信息，请参阅 [使用标签整理 Amazon EKS 资源](eks-using-tags.md)。想要了解您可以将条件键中的标签用于哪些操作，请参阅[服务授权参考](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html)中的 [Amazon EKS 定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)。 ## Amazon EKS IAM 角色 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)是 AWS 账户中具有特定权限的实体。 ### 将临时凭证用于 Amazon EKS 可以使用临时凭证进行联合身份验证登录，分派 IAM 角色或分派跨账户角色。您可以通过调用AWS STS API 操作（[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 或 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)）获得临时安全凭证。 Amazon EKS 支持使用临时凭证。 ### 服务关联角色 [服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)允许 AWS 服务访问其他服务中的资源以代表您完成操作。服务关联角色显示在 IAM 账户中，并归该服务所有。管理员可以查看但不能编辑服务相关角色的权限。 Amazon EKS 支持服务相关角色。有关创建或管理 Amazon EKS 服务相关角色的详细信息，请参阅 [对 Amazon EKS 使用服务相关角色](using-service-linked-roles.md)。 ### 服务角色 此功能允许服务代表您担任[服务角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role)。此角色允许服务访问其他服务中的资源以代表您完成操作。服务角色显示在 IAM 账户中，并归该账户所有。这意味着，IAM 管理员可以更改该角色的权限。但是，这样做可能会中断服务的功能。 Amazon EKS 支持服务角色。有关更多信息，请参阅[Amazon EKS 集群 IAM 角色](cluster-iam-role.md)和[Amazon EKS 节点 IAM 角色](create-node-role.md)。 ### 在 Amazon EKS 中选择 IAM 角色 当您在 Amazon EKS 中创建集群资源时，您必须选择一个角色以允许 Amazon EKS 代表您访问一些其他AWS资源。如果您之前创建了一个服务角色，Amazon EKS 会为您提供一个角色列表供您选择。请务必选择一个附带 Amazon EKS 托管策略的角色。有关更多信息，请参阅[检查现有集群角色](cluster-iam-role.md#check-service-role)和[检查现有节点角色](create-node-role.md#check-worker-node-role)。 # Amazon EKS 基于身份的策略示例 默认情况下，IAM 用户和角色没有创建或修改 Amazon EKS 资源的权限。它们也无法使用AWS 管理控制台、AWS CLI 或者 AWS API 执行任务。IAM 管理员必须创建 IAM 策略，以便为用户和角色授予权限以对所需的指定资源执行特定的 API 操作。然后，管理员必须将这些策略附加到需要这些权限的 IAM 用户或组。 要了解如何使用这些示例 JSON 策略文档创建 IAM 基于身份的策略，请参阅《*IAM 用户指南*》中的[在 JSON 选项卡上创建策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)。 创建 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`。 有关使用 ConfigMap 的更多信息，请参阅 [向 IAM 用户和角色授予对 Kubernetes API 的访问权限](grant-k8s-access.md)。 **Topics** + [策略最佳实践](#security-iam-service-with-iam-policy-best-practices) + [使用 Amazon EKS 控制台](#security-iam-id-based-policy-examples-console) + [允许 IAM 用户查看他们自己的权限](#security-iam-id-based-policy-examples-view-own-permissions) + [在 AWS 云上创建 Kubernetes 集群](#policy-create-cluster) + [在 Outpost 上创建本地 Kubernetes 集群](#policy-create-local-cluster) + [更新 Kubernetes 集群](#policy-example1) + [列出或描述所有集群](#policy-example2) ## 策略最佳实践 基于身份的策略确定某个人是否可以创建、访问或删除您账户中的 Amazon EKS 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议： + **AWS 托管策略及转向最低权限许可入门** – 要开始向用户和工作负载授予权限，请使用 *AWS 托管式策略*来为许多常见使用案例授予权限。您可以在 AWS 账户中找到这些策略。我们建议通过定义特定于您的使用案例的 AWS 客户管理型策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的 AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。 + **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。 + **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果通过特定 AWS 服务（例如 AWS CloudFormation）使用服务操作，您还可以使用条件来授予对服务操作的访问权限。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。 + **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM Acess Analyzer 策略验证](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。 + **需要多重身份验证（MFA）** – 如果您所处的场景要求您的 AWS 账户中有 IAM 用户或根用户，请启用 MFA 来提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[配置受 MFA 保护的 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。 有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》中的 [IAM 中的安全最佳实操](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)**。 ## 使用 Amazon EKS 控制台 要访问 Amazon EKS 控制台，[IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必须具有一组最低的权限。这些权限允许主体列出和查看有关您的 AWS 账户中的 Amazon EKS 资源的详细信息。如果创建比必需的最低权限更为严格的基于身份的策略，对于附加了该策略的主体，控制台将无法按预期正常运行。 为确保 IAM 主体仍可以使用 Amazon EKS 控制台，请用唯一名称创建一个策略，如 `AmazonEKSAdminPolicy`。将策略附加到主体。有关更多信息，请参阅《IAM 用户指南》**中的[添加和移除 IAM 身份权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)。 **重要** 以下示例策略将允许主体查看控制台中**配置**选项卡上的信息。要在 AWS 管理控制台中的**概述**和**资源**选项卡上查看信息，该主体还需要 Kubernetes 权限。有关更多信息，请参阅 [所需的权限](view-kubernetes-resources.md#view-kubernetes-resources-permissions)。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "eks.amazonaws.com" } } } ] } ``` 对于仅调用 AWS CLI 或 AWS API 的主体，您不需要允许最低控制台权限。相反，只允许访问与您尝试执行的 API 操作相匹配的操作。 ## 允许 IAM 用户查看他们自己的权限 该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管式策略。此策略包含通过控制台或者使用 AWS CLI 或 AWS API 以编程方式完成此操作所需的权限。 ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## 在 AWS 云上创建 Kubernetes 集群 此示例策略包含在 *us-west-2* AWS 区域中创建名为 *my-cluster* 的 Amazon EKS 集群所需的最低权限。您可以将 AWS 区域替换为要在其中创建集群的 AWS 区域。如果 AWS 管理控制台 中显示警告，提示**您的策略中的操作不支持资源级权限，因而要求您选择 `All resources` **，您可以放心地忽略该警告。如果账户已经有 *AWSServiceRoleForAmazonEKS* 角色，您可以从策略中删除 `iam:CreateServiceLinkedRole` 操作。如果在账户中创建过 Amazon EKS 集群，则此角色已经存在，除非您已将其删除。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:CreateCluster", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS", "Condition": { "ForAnyValue:StringEquals": { "iam:AWSServiceName": "eks" } } }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/cluster-role-name" } ] } ``` ## 在 Outpost 上创建本地 Kubernetes 集群 此示例策略包括在 *us-west-2* AWS 区域中创建名为 *my-cluster* 的 Amazon EKS 本地集群所需的最低权限。您可以将 AWS 区域替换为要在其中创建集群的 AWS 区域。如果 AWS 管理控制台 中显示警告，提示**您的策略中的操作不支持资源级权限，因而要求您选择 `All resources` **，您可以放心地忽略该警告。如果您的账户已经有 `AWSServiceRoleForAmazonEKSLocalOutpost` 角色，您可以从策略中删除 `iam:CreateServiceLinkedRole` 操作。如果您曾经在您的账户中的 Outpost 上创建过 Amazon EKS 本地集群，则此角色已存在，除非您将其删除。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:CreateCluster", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" }, { "Action": [ "ec2:DescribeSubnets", "ec2:DescribeVpcs", "iam:GetRole" ], "Resource": "*", "Effect": "Allow" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost" }, { "Effect": "Allow", "Action": [ "iam:PassRole", "iam:ListAttachedRolePolicies" ], "Resource": "arn:aws:iam::111122223333:role/cluster-role-name" }, { "Action": [ "iam:CreateInstanceProfile", "iam:TagInstanceProfile", "iam:AddRoleToInstanceProfile", "iam:GetInstanceProfile", "iam:DeleteInstanceProfile", "iam:RemoveRoleFromInstanceProfile" ], "Resource": "arn:aws:iam::*:instance-profile/eks-local-*", "Effect": "Allow" } ] } ``` ## 更新 Kubernetes 集群 此示例策略包含在 us-west-2 AWS 区域中更新名为 *my-cluster* 的集群所需的最低权限。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "eks:UpdateClusterVersion", "Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster" } ] } ``` ## 列出或描述所有集群 此示例策略包含列出和描述账户中所有集群所需的最低权限。[IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)必须能够列出和描述集群，才能使用 `update-kubeconfig` AWS CLI 命令。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] } ``` # 对 Amazon EKS 使用服务相关角色 Amazon Elastic Kubernetes Service 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 **Topics** + [使用 Amazon EKS 集群的角色](using-service-linked-roles-eks.md) + [使用 Amazon EKS 节点组的角色](using-service-linked-roles-eks-nodegroups.md) + [使用 Amazon EKS Fargate 配置文件的角色](using-service-linked-roles-eks-fargate.md) + [使用角色将 Kubernetes 集群连接到 Amazon EKS](using-service-linked-roles-eks-connector.md) + [使用 Outpost 上的 Amazon EKS 本地集群的角色](using-service-linked-roles-eks-outpost.md) + [使用 Amazon EKS 控制面板的角色](using-service-linked-roles-eks-dashboard.md) # 使用 Amazon EKS 集群的角色 Amazon Elastic Kubernetes Service 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 服务相关角色可让您更轻松地设置 Amazon EKS，因为您不必手动添加必要的权限。Amazon EKS 定义其服务相关角色的权限，除非另外定义，否则只有 Amazon EKS 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务相关角色。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其它服务的信息，请参阅[与 IAM 配合使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务相关角色文档。 ## Amazon EKS 的服务相关角色权限 Amazon EKS 使用名为 `AWSServiceRoleForAmazonEKS` 的服务相关角色。该角色允许 Amazon EKS 管理您账户中的集群。附加的策略允许角色管理以下资源：网络接口、安全组、日志和 VPC。 **注意** `AWSServiceRoleForAmazonEKS` 服务相关角色不同于创建集群所需的角色。有关更多信息，请参阅 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)。 `AWSServiceRoleForAmazonEKS` 服务相关角色信任以下服务代入该角色： + `eks.amazonaws.com` 角色权限策略允许 Amazon EKS 对指定资源完成以下操作： + [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html) 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务相关角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 为 Amazon EKS 创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建集群时，Amazon EKS 会为您创建服务相关角色。 如果您删除该服务相关角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。当您创建集群时，Amazon EKS 将再次为您创建服务相关角色。 ## 为 Amazon EKS 编辑服务相关角色 Amazon EKS 不允许您编辑 `AWSServiceRoleForAmazonEKS` 服务相关角色。创建服务相关角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除适用于 Amazon EKS 的服务相关角色 如果不再需要使用某个需要服务相关角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，您必须先清除您的服务相关角色，然后才能手动删除它。 ### 清除服务相关角色 必须先删除服务相关角色使用的所有资源，然后才能使用 IAM 删除该角色。 **注意** 如果当您试图删除资源时 Amazon EKS 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 在左侧导航窗格中，选择**集群**。 1. 如果您的集群具有任何节点组或 Fargate 配置文件，则必须先将其删除，然后才能删除该集群。有关更多信息，请参阅 [从集群中删除托管式节点组](delete-managed-node-group.md) 和 [删除 Fargate 配置文件](delete-fargate-profile.md)。 1. 在 **Clusters（集群）**页面上，选择要删除的集群，然后选择 **Delete（删除）**。 1. 在删除确认窗口中键入集群的名称，然后选择 **Delete（删除）**。 1. 对您账户中的任何其他集群重复此过程。等待所有删除操作完成。 ### 手动删除服务相关角色 使用 IAM 控制台、AWS CLI 或 AWS API 删除 `AWSServiceRoleForAmazonEKS` 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## Amazon EKS 服务相关角色支持的区域 Amazon EKS 支持在该服务可用的所有区域中使用服务相关角色。有关更多信息，请参阅 [Amazon EKS 端点和配额](https://docs.aws.amazon.com/general/latest/gr/eks.html)。 # 使用 Amazon EKS 节点组的角色 Amazon API Gateway 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 服务相关角色可让您更轻松地设置 Amazon EKS，因为您不必手动添加必要的权限。Amazon EKS 定义其服务相关角色的权限，除非另外定义，否则只有 Amazon EKS 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务相关角色。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其它服务的信息，请参阅[与 IAM 配合使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务相关角色文档。 ## Amazon EKS 的服务相关角色权限 Amazon EKS 使用名为 `AWSServiceRoleForAmazonEKSNodegroup` 的服务相关角色。该角色允许 Amazon EKS 管理您账户中的节点组。附加的 `AWSServiceRoleForAmazonEKSNodegroup` 策略允许角色管理以下资源：自动扩缩组、安全组、启动模板和 IAM 实例配置文件。有关更多信息，请参阅 [AWS托管策略：AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 `AWSServiceRoleForAmazonEKSNodegroup` 服务相关角色信任以下服务代入该角色： + `eks-nodegroup.amazonaws.com` 角色权限策略允许 Amazon EKS 对指定资源完成以下操作： + [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html) 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务相关角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 为 Amazon EKS 创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建节点组时，Amazon EKS 会为您创建服务相关角色。 **重要** 如果您在其他使用此角色支持的功能的服务中完成某个操作，此服务相关角色可以出现在您的账户中。如果在 2017 年 1 月 1 日（从此时开始支持服务相关角色）之前已使用 Amazon EKS 服务，则 Amazon EKS 已在您的账户中创建了 AWSServiceRoleForAmazonEKSNodegroup 角色。要了解更多信息，请参阅[我的 IAM 账户中出现新角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)。 ### 在 Amazon EKS（AWS API）中创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建托管节点组时，Amazon EKS 会为您创建服务相关角色。 如果您删除该服务相关角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。当您创建另一个托管节点组时，Amazon EKS 再次为您创建服务相关角色。 ## 为 Amazon EKS 编辑服务相关角色 Amazon EKS 不允许您编辑 `AWSServiceRoleForAmazonEKSNodegroup` 服务相关角色。创建服务相关角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除适用于 Amazon EKS 的服务相关角色 如果不再需要使用某个需要服务相关角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，您必须先清除您的服务相关角色，然后才能手动删除它。 ### 清除服务相关角色 必须先删除服务相关角色使用的所有资源，然后才能使用 IAM 删除该角色。 **注意** 如果当您试图删除资源时 Amazon EKS 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 在左侧导航窗格中，选择**集群**。 1. 选择 **Compute**（计算）选项卡。 1. 在 **Node groups**（节点组）部分中，选择要删除的节点组。 1. 在删除确认窗口中键入节点组的名称，然后选择 **Delete（删除）**。 1. 对集群中的任何其他节点组重复此过程。等待所有删除操作完成。 ### 手动删除服务相关角色 使用 IAM 控制台、AWS CLI 或 AWS API 删除 `AWSServiceRoleForAmazonEKSNodegroup` 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## Amazon EKS 服务相关角色支持的区域 Amazon EKS 支持在该服务可用的所有区域中使用服务相关角色。有关更多信息，请参阅 [Amazon EKS 端点和配额](https://docs.aws.amazon.com/general/latest/gr/eks.html)。 # 使用 Amazon EKS Fargate 配置文件的角色 Amazon API Gateway 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 服务相关角色可让您更轻松地设置 Amazon EKS，因为您不必手动添加必要的权限。Amazon EKS 定义其服务相关角色的权限，除非另外定义，否则只有 Amazon EKS 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务相关角色。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其它服务的信息，请参阅[与 IAM 配合使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务相关角色文档。 ## Amazon EKS 的服务相关角色权限 Amazon EKS 使用名为 `AWSServiceRoleForAmazonEKSForFargate` 的服务相关角色。该角色允许 Amazon EKS Fargate 配置 Fargate 容器组（pod）所需的 VPC 联网。附加的策略允许角色创建和删除弹性网络接口，并描述弹性网络接口和资源。 `AWSServiceRoleForAmazonEKSForFargate` 服务相关角色信任以下服务代入该角色： + `eks-fargate.amazonaws.com` 角色权限策略允许 Amazon EKS 对指定资源完成以下操作： + [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html) 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务相关角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 为 Amazon EKS 创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建 Fargate 配置文件时，Amazon EKS 将为您创建服务相关角色。 **重要** 如果您在其他使用此角色支持的功能的服务中完成某个操作，此服务相关角色可以出现在您的账户中。如果在 2019 年 12 月 13 日（从此时开始支持服务相关角色）之前已使用 Amazon EKS 服务，则 Amazon EKS 已在您的账户中创建了 AWSServiceRoleForAmazonEKSForFargate 角色。要了解更多信息，请参阅[我的 IAM 账户中出现新角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)。 ### 在 Amazon EKS（AWS API）中创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建 Fargate 配置文件时，Amazon EKS 将为您创建服务相关角色。 如果您删除该服务相关角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。当您创建另一个托管节点组时，Amazon EKS 再次为您创建服务相关角色。 ## 为 Amazon EKS 编辑服务相关角色 Amazon EKS 不允许您编辑 `AWSServiceRoleForAmazonEKSForFargate` 服务相关角色。创建服务相关角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除适用于 Amazon EKS 的服务相关角色 如果不再需要使用某个需要服务相关角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，您必须先清除您的服务相关角色，然后才能手动删除它。 ### 清除服务相关角色 必须先删除服务相关角色使用的所有资源，然后才能使用 IAM 删除该角色。 **注意** 如果当您试图删除资源时 Amazon EKS 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 在左侧导航窗格中，选择**集群**。 1. 在 **Clusters (集群)** 页面上，选择您的集群。 1. 选择 **Compute**（计算）选项卡。 1. 如果 **Fargate profiles**（Fargate 配置文件）部分中有任何 Fargate 配置文件，则分别选择每个配置文件，然后选择 **Delete**（删除）。 1. 在删除确认窗口中键入配置文件的名称，然后选择 **Delete（删除）**。 1. 对集群中以及您账户中任何其他集群的任何其它 Fargate 配置文件重复此过程。 ### 手动删除服务相关角色 使用 IAM 控制台、AWS CLI 或 AWS API 删除 AWSServiceRoleForAmazonEKSForFargate 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## Amazon EKS 服务相关角色支持的区域 Amazon EKS 支持在该服务可用的所有区域中使用服务相关角色。有关更多信息，请参阅 [Amazon EKS 端点和配额](https://docs.aws.amazon.com/general/latest/gr/eks.html)。 # 使用角色将 Kubernetes 集群连接到 Amazon EKS Amazon API Gateway 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 服务相关角色可让您更轻松地设置 Amazon EKS，因为您不必手动添加必要的权限。Amazon EKS 定义其服务相关角色的权限，除非另外定义，否则只有 Amazon EKS 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务关联角色。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其它服务的信息，请参阅[与 IAM 配合使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务关联角色文档。 ## Amazon EKS 的服务相关角色权限 Amazon EKS 使用名为 `AWSServiceRoleForAmazonEKSConnector` 的服务相关角色。该角色允许 Amazon EKS 连接 Kubernetes 集群。附加的策略允许角色管理必要的资源，以便连接到注册的 Kubernetes 集群。 `AWSServiceRoleForAmazonEKSConnector` 服务相关角色信任以下服务代入该角色： + `eks-connector.amazonaws.com` 角色权限策略允许 Amazon EKS 对指定资源完成以下操作： + [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 此角色使用 SSM（Systems Manager）权限来建立安全连接和管理连接的 Kubernetes 集群。 ## 为 Amazon EKS 创建服务相关角色 无需手动创建服务相关角色来连接集群。当您在 AWS 管理控制台、AWS CLI、`eksctl` 或 AWS API 中连接集群时，Amazon EKS 会为您创建服务相关角色。 如果您删除该服务关联角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。连接集群时，Amazon EKS 将再次为您创建服务相关角色。 ## 为 Amazon EKS 编辑服务相关角色 Amazon EKS 不允许您编辑 `AWSServiceRoleForAmazonEKSConnector` 服务相关角色。创建服务关联角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除适用于 Amazon EKS 的服务相关角色 如果不再需要使用某个需要服务关联角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，您必须先清除您的服务相关角色，然后才能手动删除它。 ### 清除服务相关角色 必须先删除服务相关角色使用的所有资源，然后才能使用 IAM 删除该角色。 **注意** 如果当您试图删除资源时 Amazon EKS 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 在左侧导航窗格中，选择**集群**。 1. 在 **Clusters (集群)** 页面上，选择您的集群。 1. 选择 **Deregister**（取消注册）选项卡，然后选择 **Ok**（确定）选项卡。 ### 手动删除服务相关角色 使用 IAM 控制台、AWS CLI 或 AWS API 删除 AWSServiceRoleForAmazonEKSConnector 服务相关角色。有关更多信息，请参阅《IAM 用户指南》中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)**。 # 使用 Outpost 上的 Amazon EKS 本地集群的角色 Amazon Elastic Kubernetes Service 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 服务相关角色可让您更轻松地设置 Amazon EKS，因为您不必手动添加必要的权限。Amazon EKS 定义其服务相关角色的权限，除非另外定义，否则只有 Amazon EKS 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务相关角色。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其它服务的信息，请参阅[与 IAM 配合使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务相关角色文档。 ## Amazon EKS 的服务相关角色权限 Amazon EKS 使用名为 `AWSServiceRoleForAmazonEKSLocalOutpost` 的服务相关角色。该角色允许 Amazon EKS 管理您账户中的本地集群。附加的策略允许角色管理以下资源：网络接口、安全组、日志和 Amazon EC2 实例。 **注意** `AWSServiceRoleForAmazonEKSLocalOutpost` 服务相关角色不同于创建集群所需的角色。有关更多信息，请参阅 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)。 `AWSServiceRoleForAmazonEKSLocalOutpost` 服务相关角色信任以下服务代入该角色： + `outposts.eks-local.amazonaws.com` 角色权限策略允许 Amazon EKS 对指定资源完成以下操作： + [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html) 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务相关角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 为 Amazon EKS 创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建集群时，Amazon EKS 会为您创建服务相关角色。 如果您删除该服务相关角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。当您创建集群时，Amazon EKS 将再次为您创建服务相关角色。 ## 为 Amazon EKS 编辑服务相关角色 Amazon EKS 不允许您编辑 `AWSServiceRoleForAmazonEKSLocalOutpost` 服务相关角色。在创建服务相关角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。不过，您可以使用 IAM 编辑角色的说明。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除适用于 Amazon EKS 的服务相关角色 如果不再需要使用某个需要服务相关角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，您必须先清除您的服务相关角色，然后才能手动删除它。 ### 清除服务相关角色 必须先删除服务相关角色使用的所有资源，然后才能使用 IAM 删除该角色。 **注意** 如果当您试图删除资源时 Amazon EKS 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。 1. 打开 [Amazon EKS 控制台](https://console.aws.amazon.com/eks/home#/clusters)。 1. 请在左侧导航窗格中，选择 Amazon EKS **Clusters**（集群）。 1. 如果您的集群具有任何节点组或 Fargate 配置文件，则必须先将其删除，然后才能删除该集群。有关更多信息，请参阅 [从集群中删除托管式节点组](delete-managed-node-group.md) 和 [删除 Fargate 配置文件](delete-fargate-profile.md)。 1. 在 **Clusters（集群）**页面上，选择要删除的集群，然后选择 **Delete（删除）**。 1. 在删除确认窗口中键入集群的名称，然后选择 **Delete（删除）**。 1. 对您账户中的任何其他集群重复此过程。等待所有删除操作完成。 ### 手动删除服务相关角色 使用 IAM 控制台、AWS CLI 或 AWS API 删除 `AWSServiceRoleForAmazonEKSLocalOutpost` 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## Amazon EKS 服务相关角色支持的区域 Amazon EKS 支持在该服务可用的所有区域中使用服务相关角色。有关更多信息，请参阅 [Amazon EKS 端点和配额](https://docs.aws.amazon.com/general/latest/gr/eks.html)。 # 使用 Amazon EKS 控制面板的角色 Amazon EKS 控制面板通过此服务相关角色，来聚合有关来自多个区域和账户的集群资源的信息。控制面板与 AWS Organizations 集成，可安全读取有关组织中多个账户的信息。 要了解有关 Amazon EKS 控制面板的更多信息，请参阅 [使用 EKS 控制面板查看有关集群资源的聚合数据](cluster-dashboard.md)。 ## 背景 Amazon API Gateway 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Amazon EKS 直接相关。服务相关角色是由 Amazon EKS 预定义的，并包含服务代表您调用其它 AWS 服务所需的所有权限。 服务相关角色可让您更轻松地设置 Amazon EKS，因为您不必手动添加必要的权限。Amazon EKS 定义其服务相关角色的权限，除非另外定义，否则只有 Amazon EKS 可以代入该角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。 只有在首先删除相关资源后，您才能删除服务相关角色。这将保护您的 Amazon EKS 资源，因为您不会无意中删除对资源的访问权限。 有关支持服务相关角色的其它服务的信息，请参阅[与 IAM 配合使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务相关角色文档。 ## Amazon EKS 的服务相关角色权限 Amazon EKS 使用名为 `AWSServiceRoleForAmazonEKSDashboard` 的服务相关角色。该角色允许 Amazon EKS 生成和显示 EKS 控制面板，包括有关集群资源的聚合信息。附加的 `AmazonEKSDashboardServiceRolePolicy` 策略允许角色管理以下资源：自动扩缩组、安全组、启动模板和 IAM 实例配置文件。有关更多信息，请参阅 [AWS 托管策略：AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy)。 `AWSServiceRoleForAmazonEKSDashboard` 服务相关角色信任以下服务代入该角色： + `dashboard.eks.amazonaws.com` 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)。 您必须配置权限，允许 IAM 实体（如用户、组或角色）创建、编辑或删除服务相关角色。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 ## 为 Amazon EKS 创建服务相关角色 您无需手动创建服务相关角色。当您在 AWS 控制台中启用控制面板时，Amazon EKS 会为您创建服务相关角色。 有关启用 EKS 控制面板的更多信息，请参阅 [配置 EKS 控制面板与 AWS Organizations 的集成](cluster-dashboard-orgs.md)。 **重要** 如果您在其他使用此角色支持的功能的服务中完成某个操作，此服务相关角色可以出现在您的账户中。 ## 为 Amazon EKS 编辑服务相关角色 Amazon EKS 不允许您编辑 `AWSServiceRoleForAmazonEKSDashboard` 服务相关角色。创建服务相关角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 删除适用于 Amazon EKS 的服务相关角色 如果不再需要使用某个需要服务相关角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，您必须先清除您的服务相关角色，然后才能手动删除它。 ### 清除服务相关角色 必须先删除服务相关角色使用的所有资源，然后才能使用 IAM 删除该角色。 **注意** 如果当您试图删除资源时 Amazon EKS 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。 有关禁用 EKS 控制面板的更多信息，请参阅 [配置 EKS 控制面板与 AWS Organizations 的集成](cluster-dashboard-orgs.md)。 ### 手动删除服务相关角色 使用 IAM 控制台、AWS CLI 或 AWS API 删除 `AWSServiceRoleForAmazonEKSDashboard` 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## Amazon EKS 服务相关角色支持的区域 Amazon EKS 支持在该服务可用的所有区域中使用服务相关角色。有关更多信息，请参阅 [Amazon EKS 端点和配额](https://docs.aws.amazon.com/general/latest/gr/eks.html)。 # Amazon EKS 容器组（pod）执行 IAM 角色 要在 AWS Fargate 基础设施上运行容器组（pod），需要有 Amazon EKS 容器组（pod）执行角色。 当集群在 AWS Fargate 基础设施上创建容器组（pod）时，在 Fargate 基础设施上运行的组件必须代表您调用 AWS API。这是为了他们可以执行诸如从 Amazon ECR 中拉取容器镜像或将日志路由到其他 AWS 服务的操作。Amazon EKS 容器组（pod）执行角色提供执行此操作的 IAM 权限。 创建 Fargate 配置文件时，必须使用配置文件为在 Fargate 基础设施上运行的 Amazon EKS 组件指定容器组（pod）执行角色。此角色将被添加到集群的 Kubernetes [基于角色的访问控制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)（RBAC）以进行授权。这允许在 Fargate 基础设施上运行的 `kubelet` 注册到您的 Amazon EKS 集群，以便它可以作为节点显示在您的集群中。 **注意** Fargate 配置文件的 IAM 角色必须与 Amazon EC2 节点组的 IAM 角色不同。 **重要** 在 Fargate 容器组（pod）中运行的容器不能承担与容器组（pod）执行角色相关联的 IAM 权限。要授予 Fargate 容器组（pod）中的容器访问其他 AWS 服务的权限，您必须使用[服务账户的 IAM 角色](iam-roles-for-service-accounts.md)。 在创建 Fargate 配置文件之前，必须使用 [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html)创建 IAM 角色。 ## 检查是否有配置正确的现有容器组（pod）执行角色 您可以按照以下程序检查并查看账户是否已有正确配置的 Amazon EKS 容器组（pod）执行角色。为了避免混淆代理安全问题，该角色必须根据 `SourceArn` 限制访问权限。您可以根据需要修改执行角色，以包括对其他集群上的 Fargate 配置文件的支持。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在 **Roles**（角色）页面上，搜索 **AmazonEKSFargatePodExecutionRole** 的角色列表。如果该角色不存在，请参阅 [创建 Amazon EKS 容器组（pod）执行角色](#create-pod-execution-role) 以创建该角色。如果该角色存在，请选择该角色。 1. 在 **AmazonEKSFargatePodExecutionRole** 页面上，请执行以下操作： 1. 选择**权限**。 1. 确保将 **AmazonEKSFargatePodExecutionRolePolicy** Amazon 托管策略附加到该角色。 1. 选择**信任关系**。 1. 选择 **Edit trust policy**（编辑信任策略）。 1. 在 **Edit trust policy**（编辑信任策略）页面中，验证信任关系是否包含以下策略，并且在集群上是否有 Fargate 配置文件的行。如果是这样，请选择 **Cancel**（取消）。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 如果策略匹配但没有指定集群上 Fargate 配置文件的行，则可以在 `ArnLike` 对象顶部添加以下行。将 *region-code* 替换为您在其中创建该集群的 AWS 区域，将 *111122223333* 替换为您的账户 ID，并将 *my-cluster* 替换为您的集群的名称。 ``` "aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*", ``` 如果策略不匹配，请将之前的完整策略复制到表单中，然后选择 **Update policy**（更新策略）。将 *region-code* 替换为您的集群所在的 AWS 区域。如果您希望在账户中的所有 AWS 区域使用相同的角色，请将 *region-code* 替换为 `*`。将 *111122223333* 替换为您的账户 ID，并将 *my-cluster* 替换为您的集群名称。如果您希望在账户中对所有集群使用相同角色，请将 *my-cluster* 替换为 `*`。 ## 创建 Amazon EKS 容器组（pod）执行角色 如果尚无用于集群的 Amazon EKS 容器组（pod）执行角色，您可以使用 AWS 管理控制台 或 AWS CLI 来创建该角色。 AWS 管理控制台 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **Roles**（角色）。 1. 在 **Roles**（角色）页面上，选择 **Create role**（创建角色）。 1. 在 **Select trusted entity**（选择受信任的实体）页面上，请执行以下操作： 1. 在**可信实体类型**部分中，选择 **AWS 服务**。 1. 从**其它 AWS 服务的使用案例**下拉列表中，选择 **EKS**。 1. 选择 **EKS – Fargate 容器组（pod）**。 1. 选择**下一步**。 1. 在 **Add permissions**（添加权限）页面上，选择 **Next**（下一步）。 1. 在 **Name, review, and create**（命名、查看和创建）页面中，请执行以下操作： 1. 对于 **Role name**（角色名称），请为角色输入唯一名称，例如 `AmazonEKSFargatePodExecutionRole`。 1. 在**添加标签（可选）**下，将标签作为键值对附加，以将元数据添加到角色。有关在 IAM 中使用标签的更多信息，请参阅《IAM 用户指南》** 中的[标记 IAM 资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)。 1. 选择**创建角色**。 1. 在**角色**页面上，搜索 **AmazonEKSFargatePodExecutionRole** 的角色列表。选择角色。 1. 在 **AmazonEKSFargatePodExecutionRole** 页面上，请执行以下操作： 1. 选择**信任关系**。 1. 选择 **Edit trust policy**（编辑信任策略）。 1. 在 **Edit trust policy**（编辑信任策略）页面上，执行以下操作： 1. 将以下内容复制并粘贴到 **Edit trust policy**（编辑信任策略）表单中。将 *region-code* 替换为您的集群所在的 AWS 区域。如果您希望在账户中的所有 AWS 区域使用相同的角色，请将 *region-code* 替换为 `*`。将 *111122223333* 替换为您的账户 ID，并将 *my-cluster* 替换为您的集群名称。如果您希望在账户中对所有集群使用相同角色，请将 *my-cluster* 替换为 `*`。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. 选择**更新策略**。 AWS CLI 1. 复制并将以下内容粘贴到名为 `pod-execution-role-trust-policy.json` 的文件中。将 *region-code* 替换为您的集群所在的 AWS 区域。如果您希望在账户中的所有 AWS 区域使用相同的角色，请将 *region-code* 替换为 `*`。将 *111122223333* 替换为您的账户 ID，并将 *my-cluster* 替换为您的集群名称。如果您希望在账户中对所有集群使用相同角色，请将 *my-cluster* 替换为 `*`。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*" } }, "Principal": { "Service": "eks-fargate-pods.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. 创建容器组（pod）执行 IAM 角色。 ``` aws iam create-role \ --role-name AmazonEKSFargatePodExecutionRole \ --assume-role-policy-document file://"pod-execution-role-trust-policy.json" ``` 1. 将所需的 Amazon EKS 托管 IAM policy 附加到角色。 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \ --role-name AmazonEKSFargatePodExecutionRole ``` # Amazon EKS Connector IAM 角色 您可以连接 Kubernetes 集群以便在 AWS 管理控制台 中查看。要连接 Kubernetes 集群，创建 IAM 角色。 ## 检查现有 EKS connector 角色 您可以使用以下过程检查并查看您的账户是否已有 Amazon EKS connector 角色。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在角色列表中搜索 `AmazonEKSConnectorAgentRole`。如果不存在包含 `AmazonEKSConnectorAgentRole` 的角色，请参阅 [创建 Amazon EKS Connector 代理角色](#create-connector-role) 来创建角色。如果包含 `AmazonEKSConnectorAgentRole` 的角色确实存在，则选择角色以查看附加的策略。 1. 选择**权限**。 1. 确保将 **AmazonEKSConnectorAgentPolicy** 托管策略附加到此角色。如果附加该策略，则将正确配置 Amazon EKS connector 角色。 1. 选择 **Trust relationships**（信任关系），然后选择 **Edit trust policy**（编辑信任策略）。 1. 验证信任关系是否包含以下策略。如果信任关系符合以下策略，请选择 **Cancel**（取消）。如果信任关系不匹配，请将策略复制到**编辑信任策略**窗口并选择**更新策略**。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ## 创建 Amazon EKS Connector 代理角色 您可以使用 AWS 管理控制台 或 AWS CloudFormation 创建 connector 代理角色。 AWS CLI 1. 创建一个名为 `eks-connector-agent-trust-policy.json` 的文件，其中包含要用于 IAM 角色的以下 JSON。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` 1. 创建一个名为 `eks-connector-agent-policy.json` 的文件，其中包含要用于 IAM 角色的以下 JSON。 ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SsmControlChannel", "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel" ], "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "ssmDataplaneOperations", "Effect": "Allow", "Action": [ "ssmmessages:CreateDataChannel", "ssmmessages:OpenDataChannel", "ssmmessages:OpenControlChannel" ], "Resource": "*" } ] } ``` 1. 使用您在之前列表项中创建的信任策略和策略创建 Amazon EKS Connector 代理角色。 ``` aws iam create-role \ --role-name AmazonEKSConnectorAgentRole \ --assume-role-policy-document file://eks-connector-agent-trust-policy.json ``` 1. 将该策略附加到 Amazon EKS Connector 代理角色。 ``` aws iam put-role-policy \ --role-name AmazonEKSConnectorAgentRole \ --policy-name AmazonEKSConnectorAgentPolicy \ --policy-document file://eks-connector-agent-policy.json ``` AWS CloudFormation 1. 将以下 AWS CloudFormation 模板保存到本地系统中的文本文件。 **注意** 此模板还创建服务相关角色，否则调用 `registerCluster` API 时将创建。有关详细信息，请参阅 [使用角色将 Kubernetes 集群连接到 Amazon EKS](using-service-linked-roles-eks-connector.md)。 ``` --- AWSTemplateFormatVersion: '2010-09-09' Description: 'Provisions necessary resources needed to register clusters in EKS' Parameters: {} Resources: EKSConnectorSLR: Type: AWS::IAM::ServiceLinkedRole Properties: AWSServiceName: eks-connector.amazonaws.com EKSConnectorAgentRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: [ 'sts:AssumeRole' ] Principal: Service: 'ssm.amazonaws.com' EKSConnectorAgentPolicy: Type: AWS::IAM::Policy Properties: PolicyName: EKSConnectorAgentPolicy Roles: - {Ref: 'EKSConnectorAgentRole'} PolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Action: [ 'ssmmessages:CreateControlChannel' ] Resource: - Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*' - Effect: 'Allow' Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ] Resource: "*" Outputs: EKSConnectorAgentRoleArn: Description: The agent role that EKS connector uses to communicate with AWS services. Value: !GetAtt EKSConnectorAgentRole.Arn ``` 1. 打开 [AWS CloudFormation 控制台](https://console.aws.amazon.com/cloudformation/)。 1. 选择使用新资源**创建堆栈**（标准）。 1. 对于**指定模板**，选择**上传模板文件**，然后选择**选择文件**。 1. 选择您之前创建的文件，然后选择**下一步**。 1. 对于 **Stack name (堆栈名称)**，输入角色的名称，如 `eksConnectorAgentRole`，然后选择 **Next (下一步)**。 1. 在**配置堆栈选项**页面上，请选择**下一步**。 1. 在 **Review（审核）**页面上审核您的信息，确认堆栈可创建 IAM 资源，然后选择 **Create stack（创建堆栈）**。 # Amazon Elastic Kubernetes Service 的AWS托管策略 AWS 托管式策略是由 AWS 创建和管理的独立策略。AWS 托管式策略旨在为许多常见使用案例提供权限，以便您可以开始为用户、组和角色分配权限。 请记住，AWS 托管式策略可能不会为您的特定使用案例授予最低权限，因为其可供所有 AWS 客户使用。我们建议通过定义特定于使用案例的[客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)来进一步减少权限。 您无法更改 AWS 托管式策略中定义的权限。如果 AWS 更新在 AWS 托管策略中定义的权限，则更新会影响该策略所附加到的所有主体身份（用户、组和角色）。当新的 AWS 服务启动或新的 API 操作可用于现有服务时，AWS 最有可能更新 AWS 托管策略。 有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。 ## AWS托管策略：AmazonEKS\$1CNI\$1Policy 您可以将 `AmazonEKS_CNI_Policy` 附加到 IAM 实体。在创建 Amazon EC2 节点组之前，此策略必须附加到[节点 IAM 角色](create-node-role.md)，或适用于 Kubernetes 的 Amazon VPC CNI 插件专用的 IAM 角色。这样它可以代表您执行操作。我们建议您将策略附加到仅由插件使用的角色。有关更多信息，请参阅[使用 Amazon VPC CNI 将 IP 分配给容器组（pod）](managing-vpc-cni.md)和[配置 Amazon VPC CNI 插件以使用 IRSA](cni-iam-role.md)。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + **`ec2:*NetworkInterface` 和 `ec2:*PrivateIpAddresses`**：允许 Amazon VPC CNI 插件执行操作，例如为容器组（pod）预置弹性网络接口和 IP 地址，以便为 Amazon EKS 中运行的应用程序提供联网。 + **`ec2` 读取操作** – 允许 Amazon VPC CNI 插件执行操作，例如描述实例和子网，以查看您的 Amazon VPC 子网中的免费 IP 地址数量。VPC CNI 可以使用每个子网中的免费 IP 地址来选择空闲 IP 地址最多的子网，以便在创建弹性网络接口时使用。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json)。 ## AWS托管策略：AmazonEKSClusterPolicy 您可以将 `AmazonEKSClusterPolicy` 附加到您的 IAM 实体。在创建集群之前，您必须拥有附加了此策略的[集群 IAM 角色](cluster-iam-role.md)。由 Amazon EKS 托管的 Kubernetes 集群会代表您调用其他 AWS 服务。它们这样做的目的是为了管理您与服务一起使用的资源。 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + **`autoscaling`** – 读取和更新自动扩缩组的配置。Amazon EKS 不使用这些权限，但它们保留在策略中，以确保向后兼容。 + **`ec2`** – 使用与 Amazon EC2 节点关联的卷和网络资源执行工作。此为必需操作，以便 Kubernetes 控制面板可以将实例加入到集群，并动态预置和管理 Kubernetes 持久卷请求的 Amazon EBS 卷。 + **`ec2`**：删除由 VPC CNI 创建的弹性网络接口。这是必需项，以便 EKS 可以清理 VPC CNI 意外退出时留下的弹性网络接口。 + ** `elasticloadbalancing` **：使用弹性负载均衡器并将节点添加到其中作为目标。此为必需操作，以便 Kubernetes 控制层面能够动态预置 Kubernetes 服务请求的 Elastic Load Balancer。 + ** `iam` **：创建服务相关角色。此为必需操作，以便 Kubernetes 控制面板能够动态预置 Kubernetes 服务请求的 Elastic Load Balancer。 + **`kms`** – 从 AWS KMS 读取密钥。这对于 Kubernetes 控制面板是必需的，以支持 `etcd` 中存储的 Kubernetes 密钥的[密钥加密](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json)。 ## AWS 托管策略：AmazonEKSDashboardConsoleReadOnly 您可以将 `AmazonEKSDashboardConsoleReadOnly` 附加到 IAM 实体。 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + **`eks`**：对 EKS 控制面板数据、资源和集群版本信息的只读访问权限。这允许查看与 EKS 相关的指标和集群配置详细信息。 + **`organizations`**：对 AWS Organizations 信息的只读访问权限，包括： + 查看组织详细信息和服务访问权限 + 列出组织根、账户和组织单位 + 查看组织结构 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSDashboardConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json)。 ## AWS托管策略：AmazonEKSFargatePodExecutionRolePolicy 您可以将 `AmazonEKSFargatePodExecutionRolePolicy` 附加到您的 IAM 实体。在创建 Fargate 配置文件之前，您必须创建 Fargate 容器组（pod）执行角色并将此策略附加到其上。有关更多信息，请参阅 [第 2 步：创建 Fargate 容器组（pod）执行角色](fargate-getting-started.md#fargate-sg-pod-execution-role) 和 [定义启动时将使用 AWS Fargate 的容器组（pod）](fargate-profile.md)。 此策略向该角色授予权限，可提供对必须在 Fargate 上运行 Amazon EKS 容器组（pod）的其他 AWS 服务资源的访问权限。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + ** `ecr` **：允许在 Fargate 上运行的容器组（pod）提取存储在 Amazon ECR 中的容器镜像。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json)。 ## AWS 托管式策略：AmazonEKSConnectorServiceRolePolicy 您不能将 `AmazonEKSConnectorServiceRolePolicy` 附加到自己的 IAM 实体。将此策略附加到允许 Amazon EKS 代表您执行操作的服务相关角色。有关更多信息，请参阅 [使用角色将 Kubernetes 集群连接到 Amazon EKS](using-service-linked-roles-eks-connector.md)。 该角色允许 Amazon EKS 连接 Kubernetes 集群。附加的策略允许角色管理必要的资源，以便连接到注册的 Kubernetes 集群。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限。 + ** `SSM Management` **：创建、描述和删除 SSM 激活，并取消注册托管实例。此功能允许基本的 Systems Manager 操作。 + ** `Session Management` **：启动专门针对 EKS 集群的 SSM 会话，并使用 AmazonEKS 文档执行非交互式命令。 + ** `IAM Role Passing` **：将 IAM 角色专门传递给 SSM 服务，该服务由将传递角色限制为 `ssm.amazonaws.com` 的条件控制。 + ** `EventBridge Rules` **：创建 EventBridge 规则和目标，但仅当由 `eks-connector.amazonaws.com` 管理时。作为事件源，规则特别限于 AWS SSM。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)。 ## AWS托管策略：AmazonEKSForFargateServiceRolePolicy 您不能将 `AmazonEKSForFargateServiceRolePolicy` 附加到自己的 IAM 实体。将此策略附加到允许 Amazon EKS 代表您执行操作的服务相关角色。有关更多信息，请参阅 `AWSServiceRoleforAmazonEKSForFargate`。 此策略授予 Amazon EKS 运行 Fargate 任务所必要的权限。仅当您具有 Fargate 节点时，才会使用此策略。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限。 + ** `ec2` **：创建和删除弹性网络接口，并描述弹性网络接口和资源。此为必需操作，以便 Amazon EKS Fargate 服务可以配置 Fargate 容器组（pod）所需的 VPC 联网。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json)。 ## AWS 托管策略：AmazonEKSComputePolicy 您可以将 `AmazonEKSComputePolicy` 附加到 IAM 实体。您可以将此策略附加到您的[集群 IAM 角色](cluster-iam-role.md)，以扩展 EKS 可以在您的账户中管理的资源。 该策略授予 Amazon EKS 为 EKS 集群创建和管理 EC2 实例所需的权限，以及配置 EC2 所需的 IAM 权限。此外，此策略还授予 Amazon EKS 代表您创建 EC2 竞价型实例服务相关角色的权限。 ### 权限详细信息 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + ** `ec2` 权限**： + `ec2:CreateFleet` 和 `ec2:RunInstances` – 允许创建 EC2 实例，并将特定的 EC2 资源（映像、安全组、子网）用于 EKS 集群节点。 + `ec2:CreateLaunchTemplate` – 允许为 EKS 集群节点创建 EC2 启动模板。 + 该策略还包括一些条件，用于将这些 EC2 权限的使用限制在标有 EKS 集群名称和其他相关标签的资源。 + `ec2:CreateTags` – 允许向 `CreateFleet`、`RunInstances` 和 `CreateLaunchTemplate` 操作创建的 EC2 资源添加标签。 + ** `iam` 权限**： + `iam:AddRoleToInstanceProfile` – 允许向 EKS 计算实例配置文件添加 IAM 角色。 + `iam:PassRole` – 允许将必要的 IAM 角色传递给 EC2 服务。 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json)。 ## AWS 托管策略：AmazonEKSNetworkingPolicy 您可以将 `AmazonEKSNetworkingPolicy` 附加到 IAM 实体。您可以将此策略附加到您的[集群 IAM 角色](cluster-iam-role.md)，以扩展 EKS 可以在您的账户中管理的资源。 该策略旨在授予 Amazon EKS 创建和管理 EKS 集群网络接口的必要权限，从而允许控制面板和 Worker 节点正常通信和运行。 ### 权限详细信息 此策略授予以下权限以允许 Amazon EKS 管理集群的网络接口： + **`ec2` 网络接口权限**： + `ec2:CreateNetworkInterface` – 允许创建 EC2 网络接口。 + 该策略包括一些条件，用于将此权限的使用限制在标有 EKS 集群名称和 Kubernetes CNI 节点名称的网络接口。 + `ec2:CreateTags` – 允许向 `CreateNetworkInterface` 操作创建的网络接口添加标签。 + **`ec2` 网络接口管理权限**： + `ec2:AttachNetworkInterface`、`ec2:ModifyNetworkInterfaceAttribute`、`ec2:DetachNetworkInterface`–允许附加、修改网络接口属性以及从 EC2 实例分离网络接口。 + `ec2:UnassignPrivateIpAddresses`、`ec2:UnassignIpv6Addresses`、`ec2:AssignPrivateIpAddresses`、`ec2:AssignIpv6Addresses` – 允许管理网络接口的 IP 地址分配。 + 这些权限仅限于标有 EKS 集群名称的网络接口。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json)。 ## AWS 托管策略：AmazonEKSBlockStoragePolicy 您可以将 `AmazonEKSBlockStoragePolicy` 附加到 IAM 实体。您可以将此策略附加到您的[集群 IAM 角色](cluster-iam-role.md)，以扩展 EKS 可以在您的账户中管理的资源。 该策略授予 Amazon EKS 为 EKS 集群创建、管理和维护 EC2 卷和快照的必要权限，从而允许控制面板和 Worker 节点按照 Kubernetes 工作负载的要求预置和使用永久存储。 ### 权限详细信息 此 IAM 策略授予以下允许 Amazon EKS 管理 EC2 卷和快照的权限： + ** `ec2` 卷管理权限**： + `ec2:AttachVolume`、`ec2:DetachVolume`、`ec2:ModifyVolume`、`ec2:EnableFastSnapshotRestores` – 允许附加、分离、修改和启用 EC2 卷的快速快照还原。 + 这些权限仅限于标有 EKS 集群名称的卷。 + `ec2:CreateTags` – 允许向 `CreateVolume` 和 `CreateSnapshot` 操作创建的 EC2 卷和快照添加标签。 + ** `ec2` 卷创建权限**： + `ec2:CreateVolume` – 允许创建新的 EC2 卷。 + 该策略包括一些条件，用于将此项权限的使用限制在标有 EKS 集群名称和其他相关标签的卷。 + `ec2:CreateSnapshot` – 允许创建新的 EC2 卷快照。 + 该策略包括一些条件，用于将此项权限的使用限制在标有 EKS 集群名称和其他相关标签的快照。 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json)。 ## AWS 托管策略：AmazonEKSLoadBalancingPolicy 您可以将 `AmazonEKSLoadBalancingPolicy` 附加到 IAM 实体。您可以将此策略附加到您的[集群 IAM 角色](cluster-iam-role.md)，以扩展 EKS 可以在您的账户中管理的资源。 此 IAM 策略授予 Amazon EKS 使用各种 AWS 服务管理弹性负载均衡器（ELB）和相关资源的必要权限。 ### 权限详细信息 此策略授予的密钥权限是： + **`elasticloadbalancing` **：允许创建、修改和管理弹性负载均衡器和目标组。这包括创建、更新和删除负载均衡器、目标组、侦听器和规则的权限。 + **`ec2` **：允许创建和管理 Kubernetes 控制面板将实例加入到集群并管理 Amazon EBS 卷所需的安全组。还允许描述和列出 EC2 资源，例如实例、VPC、子网、安全组和其他联网资源。 + **`iam` **：允许为弹性负载均衡创建服务相关角色，这是 Kubernetes 控制面板动态预置 ELB 所必需的。 + ** `kms` **：允许通过 AWS KMS 读取密钥，这对于 Kubernetes 控制面板是必需的，以支持 etcd 中存储的 Kubernetes 密钥的加密。 + ** `wafv2` ** 和 ** `shield` **：允许关联和取消关联 Web ACL 以及为弹性负载均衡器创建/删除 AWS Shield 保护。 + ** `cognito-idp` **、** `acm` ** 和 ** `elasticloadbalancing` **：授予描述用户池客户端、列出和描述证书以及描述目标群体的权限，这些权限是 Kubernetes 控制面板管理弹性负载均衡器所必需的。 该策略还包括多项条件检查，确保使用 `eks:eks-cluster-name` 标签将权限范围限于所托管的特定 EKS 集群。 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json)。 ## AWS 托管式策略：AmazonEKSMCPReadOnlyAccess 您可以将 `AmazonEKSMCPReadOnlyAccess` 附加到 IAM 实体。此策略提供对 Amazon EKS 资源和相关 AWS 服务的只读访问权限，使 Amazon EKS 模型上下文协议（MCP）服务器无需对您的基础设施进行任何修改，即可执行可观测性和问题排查操作。 **权限详细信息** 此策略包含允许主体完成下列任务的以下权限： + ** `eks` ** 允许主体描述和列出 EKS 集群、节点组、附加组件、访问条目、见解以及访问 Kubernetes API 以执行只读操作。 + ** `iam` ** 允许主体检索有关 IAM 角色、策略及其附件的信息，以了解与 EKS 资源关联的权限。 + ** `ec2` ** 允许主体描述 VPC、子网和路由表，以了解 EKS 集群的网络配置。 + ** `sts` ** 允许主体出于身份验证和授权目的检索呼叫方身份信息。 + ** `logs` ** 允许主体启动查询并从 CloudWatch Logs 中检索查询结果以进行问题排查和监控。 + ** `cloudwatch` ** 允许主体检索用于监控集群和工作负载性能的指标数据。 + ** `eks-mcp` ** 允许主体在 Amazon EKS MCP 服务器中调用 MCP 操作和调用只读工具。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html)。 ## AWS托管策略：AmazonEKSServicePolicy 您可以将 `AmazonEKSServicePolicy` 附加到 IAM 实体。在 2020 年 4 月 16 日之前创建的集群需要您创建 IAM 角色并向其附加此策略。在 2020 年 4 月 16 日或之后创建的集群无需您创建角色，也不需要您分配此策略。当您使用具有 `iam:CreateServiceLinkedRole` 权限的 IAM 主体创建集群时，将会自动为您创建 [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 服务相关角色。服务相关角色附加了[托管策略：AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 此策略允许 Amazon EKS 创建和管理运行 Amazon EKS 集群所需的资源。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限。 + ** `eks` **：启动更新后，更新您集群的 Kubernetes 版本。Amazon EKS 不使用此权限，但其仍保留在策略中，以确保向后兼容。 + ** `ec2` **：使用弹性网络接口和其它网络资源和标签。这是 Amazon EKS 配置联网以便于节点和 Kubernetes 控制层面之间进行通信所必需的。阅读有关安全组的信息。更新安全组上的标签。 + ** `route53` **：将 VPC 与托管区域关联。这是 Amazon EKS 实现 Kubernetes 集群 API 服务器私有端点联网所必需的。 + ** `logs` **：录入事件。此为必需操作，以便 Amazon EKS 可以将 Kubernetes 控制层面日志发送到 CloudWatch。 + ** `iam` **：创建服务相关角色。此为必需操作，以便 Amazon EKS 可以代表您创建 [Amazon EKS 的服务相关角色权限](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 服务相关角色。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json)。 ## AWS托管策略：AmazonEKSServiceRolePolicy 您不能将 `AmazonEKSServiceRolePolicy` 附加到自己的 IAM 实体。将此策略附加到允许 Amazon EKS 代表您执行操作的服务相关角色。有关更多信息，请参阅 [Amazon EKS 的服务相关角色权限](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)。当您使用具有 `iam:CreateServiceLinkedRole` 权限的 IAM 主体创建集群时，将会自动为您创建 [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) 服务相关角色，而且此策略会附加到该角色。 此策略允许服务相关角色代表您调用AWS服务。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限。 + ** `ec2` **：创建和描述弹性网络接口和 Amazon EC2 实例、集群安全组及创建集群所需的 VPC。有关更多信息，请参阅 [查看集群的 Amazon EKS 安全组要求](sec-group-reqs.md)。阅读有关安全组的信息。更新安全组上的标签。阅读关于按需容量预留的信息。阅读包括路由表和网络 ACL 在内的 VPC 配置，以检测配置问题，这是集群见解的一部分。 + **`ec2` 自动模式** – 终止由 EKS 自动模式创建的 EC2 实例。有关更多信息，请参阅 [使用 EKS 自动模式实现集群基础设施自动化](automode.md)。 + ** `iam` **：列出附加到 IAM 角色的所有托管式策略。此为必需操作，以便 Amazon EKS 能够列出和验证创建集群所需的所有托管策略和权限。 + **将 VPC 与托管区关联** – 这是 Amazon EKS 实现 Kubernetes 集群 API 服务器私有端点联网所必需的。 + **日志事件** – 此为必需操作，以便 Amazon EKS 可以将 Kubernetes 控制面板日志发送到 CloudWatch。 + **放入指标** – 此为必需操作，这样 Amazon EKS 就可以将 Kubernetes 控制面板日志发送到 CloudWatch。 + ** `eks` **：管理集群访问条目和策略，允许精细控制可以访问 EKS 资源的主体以及其可执行的操作。这包括为计算、联网、负载均衡和存储操作关联标准访问策略。 + ** `elasticloadbalancing` **：创建、管理和删除与 EKS 集群关联的负载均衡器及其组件（侦听器、目标组、证书）。查看负载均衡器属性和运行状态。 + ** `events` ** – 创建并管理 EventBridge 规则，以便监控与 EKS 集群相关的 EC2 和 AWS Health 事件，实现对基础设施更改和运行状况警报的自动响应。 + ** `iam` **：管理含“eks”前缀的 EC2 实例配置文件，包括创建、删除和角色关联，这是 EKS 节点管理所必需的。允许描述任何实例配置文件，以使用户能够为其 Worker 节点定义自定义实例配置文件以供使用。 + ** `pricing` ** ** `shield` **：访问 AWS 定价信息和 Shield 保护状态，为 EKS 资源启用成本管理和高级安全功能。 + **资源清理** – 在集群清理操作期间，安全删除带有 EKS 标签的资源，包括卷、快照、启动模板和网络接口。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json)。 ## AWS托管策略：AmazonEKSVPCResourceController 您可以将 `AmazonEKSVPCResourceController` 策略附加到 IAM 身份。如果您使用[适用于容器组（pod）的安全组](security-groups-for-pods.md)，您必须将此策略附加到您的 [Amazon EKS 集群 IAM 角色](cluster-iam-role.md)，以便其代表您执行操作。 此策略授予集群角色管理弹性网络接口和节点 IP 地址的权限。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + ** `ec2` **：管理弹性网络接口和 IP 地址以支持容器组（pod）安全组和 Windows 节点。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json)。 ## AWS托管策略：AmazonEKSWorkerNodePolicy 您可以将 `AmazonEKSWorkerNodePolicy` 附加到 IAM 实体。您必须将此策略附加到您在创建允许 Amazon EKS 代表您执行操作的 Amazon EC2 节点时指定的[节点 IAM 角色](create-node-role.md)。如果您使用 `eksctl` 创建节点组，则其会创建节点 IAM 角色并自动将此策略附加到角色。 此策略授予 Amazon EKS Amazon EC2 节点连接到 Amazon EKS 集群的权限。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + ** `ec2` **：读取实例卷和网络信息。此为必需操作，以便 Kubernetes 节点能够描述有关节点加入 Amazon EKS 集群所需的 Amazon EC2 资源的信息。 + ** `eks` **：可选地将集群描述为节点引导启动的一部分。 + ** `eks-auth:AssumeRoleForPodIdentity` **：允许检索节点上 EKS 工作负载的凭证。需要执行此操作 EKS 容器组身份才能正常运行。 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json)。 ## AWS 托管策略：AmazonEKSWorkerNodeMinimalPolicy 您可以将 AmazonEKSWorkerNodeMinimalPolicy 附加到您的 IAM 实体。您可以将此策略附加到您在创建允许 Amazon EKS 代表您执行操作的 Amazon EC2 节点时指定的节点 IAM 角色。 此策略授予 Amazon EKS Amazon EC2 节点连接到 Amazon EKS 集群的权限。与 AmazonEKSWorkerNodePolicy 相比，此策略的权限较少。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + `eks-auth:AssumeRoleForPodIdentity` – 允许检索节点上 EKS 工作负载的凭证。需要执行此操作 EKS 容器组身份才能正常运行。 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json)。 ## AWS托管策略：AWSServiceRoleForAmazonEKSNodegroup 您不能将 `AWSServiceRoleForAmazonEKSNodegroup` 附加到自己的 IAM 实体。将此策略附加到允许 Amazon EKS 代表您执行操作的服务相关角色。有关更多信息，请参阅 [Amazon EKS 的服务相关角色权限](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups)。 此策略授予 `AWSServiceRoleForAmazonEKSNodegroup` 角色权限，允许其在您的账户中创建和管理 Amazon EC2 节点组。 **权限详细信息** 此策略包含允许 Amazon EKS 完成以下任务的以下权限： + ** `ec2` **：与安全组、标签、容量预留和启动模板结合使用。Amazon EKS 托管式节点组需要此功能才能启用远程访问配置和描述可在托管式节点组中使用的容量预留。此外，Amazon EKS 托管节点组会代表您创建启动模板。这样做的目的是配置为每个托管节点组提供支持的 Amazon EC2 Auto Scaling 组。 + ** `iam` **：创建服务相关角色并传递角色。这是 Amazon EKS 托管节点组管理创建托管节点组时传递的角色的实例配置文件所必需的。此实例配置文件由作为托管节点组的一部分启动的 Amazon EC2 实例使用。Amazon EKS 需要为其他服务（如 Amazon EC2 Auto Scaling 组）创建服务相关角色。这些权限用于创建托管节点组。 + ** `autoscaling` **：使用安全自动扩缩组。这是 Amazon EKS 托管节点组管理支持每个托管节点组的 Amazon EC2 Auto Scaling 组所必需的。它还用于支持一些功能，例如，在节点组更新期间终止或回收节点时移出容器组（pod）以及管理在托管节点组上配置的暖池。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json)。 ## AWS 托管策略：AmazonEKSDashboardServiceRolePolicy 您不能将 `AmazonEKSDashboardServiceRolePolicy` 附加到自己的 IAM 实体。将此策略附加到允许 Amazon EKS 代表您执行操作的服务相关角色。有关更多信息，请参阅 [Amazon EKS 的服务相关角色权限](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard)。 此策略授予 `AWSServiceRoleForAmazonEKSDashboard` 角色权限，允许其在您的账户中创建和管理 Amazon EC2 节点组。 **权限详细信息** 此策略包含允许访问以完成这些任务的以下权限： + **`organizations`**：查看有关 AWS Organizations 结构和账户的信息。这包括列出组织中的账户、查看组织单元和根、列出委派管理员、查看有权访问组织的服务以及检索有关组织和账户详细信息的权限。 要查看 JSON 策略文档的最新版本，请参阅《AWS Managed Policy Reference Guide》中的 [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)。 ## AWS 托管策略：AmazonEBSCSIDriverPolicy `AmazonEBSCSIDriverPolicy` 策略允许 Amazon EBS Container Storage Interface（CSI）驱动程序代表您创建、修改、复制、附加、分离和删除卷。这包括修改现有卷上的标签以及在 EBS 卷上启用快速快照还原（FSR）。此外还将向 EBS CSI 驱动程序授予创建、锁定、还原和删除快照，以及列出实例、卷和快照的权限。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json)。 ## AWS 托管式策略：AmazonEFSCSIDriverPolicy `AmazonEFSCSIDriverPolicy` 策略允许 Amazon EFS 容器存储接口（CSI）代表您创建和删除接入点。该策略还将向 Amazon EFS CSI 驱动程序授予列出您的接入点文件系统、挂载目标和 Amazon EC2 可用区的权限。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEFSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json)。 ## AWS 托管策略：AmazonEKSLocalOutpostClusterPolicy 您可以将此策略附加到 IAM 实体。在创建本地集群之前，您必须将此策略附加到[集群角色](cluster-iam-role.md)。由 Amazon EKS 托管的 Kubernetes 集群会代表您调用其他 AWS 服务。它们这样做的目的是为了管理您与服务一起使用的资源。 `AmazonEKSLocalOutpostClusterPolicy` 包含以下权限： + **`ec2` 读取操作**：允许控制面板实例描述可用区、路由表、实例和网络接口属性。Amazon EC2 实例作为控制面板实例成功加入集群所必需的权限。 + ** `ssm` **：允许通向控制面板实例的 Amazon EC2 Systems Manager 连接，Amazon EKS 使用该连接与您账户中的本地集群通信并对其进行管理。 + ** `logs` **：允许实例将日志推送到 Amazon CloudWatch。 + **`secretsmanager`** – 允许实例安全地从 AWS Secrets Manager 中获取和删除控制面板实例的引导数据。 + ** `ecr` **：允许容器组（pod）和在控制面板实例上运行的容器拉取存储在 Amazon Elastic Container Registry 中的容器映像。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json)。 ## AWS 托管策略：AmazonEKSLocalOutpostServiceRolePolicy 您不能将此策略附加到您的 IAM 实体。当您使用具有 `iam:CreateServiceLinkedRole` 权限的 IAM 主体创建集群时，Amazon EKS 将自动为您创建 [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) 服务相关角色，并将此策略附加到该角色。此策略允许该服务相关角色代表您为本地集群调用 AWS 服务。 `AmazonEKSLocalOutpostServiceRolePolicy` 包含以下权限： + ** `ec2` **：允许 Amazon EKS 使用安全、网络和其他资源，成功启动和管理您的账户中的控制面板实例。 + ** `ssm`、`ssmmessages`**：允许通向控制面板实例的 Amazon EC2 Systems Manager 连接，Amazon EKS 使用该连接与您账户中的本地集群通信并对其进行管理。 + ** `iam` **：允许 Amazon EKS 管理与控制面板实例关联的实例配置文件。 + **`secretsmanager`** – 允许 Amazon EKS 将控制面板实例的引导数据放入 AWS Secrets Manager，以便能在实例引导期间安全地引用它。 + ** `outposts` **：允许 Amazon EKS 从您的账户中获取 Outpost 信息，以便在 Outpost 中成功启动本地集群。 要查看 JSON 策略文档的最新版本，请参阅《AWS 托管式策略参考指南》中的 [AmazonEKSLocalOutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json)。 ## AWS托管策略的 Amazon EKS 更新 查看有关 Amazon EKS（自从其开始跟踪更新更改以来）的AWS托管策略的更新的详细信息。 要接收此特定文档页面的所有源文件更改通知，您可以通过 RSS 阅读器订阅以下 URL： ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom ``` | 更改 | 描述 | 日期 | | --- | --- | --- | | 已将权限添加至 [AWS 托管策略：AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)。 | 在 `AmazonEKSNetworkingPolicy` 中添加了 `ec2:ModifyNetworkInterfaceAttribute` 权限。这允许 Amazon EKS Auto Mode 控制器修改与 EC2 实例相关的网络接口属性。 | 2026 年 2 月 3 日 | | 已将权限添加至 [AWS托管策略：AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 | 已为 `AWSServiceRoleForAmazonEKSNodegroup` 新增 `autoscaling:PutWarmPool`、`autoscaling:DeleteWarmPool` 和 `autoscaling:DescribeWarmPool` 权限。这使得 Amazon EKS 托管节点组能够在节点组的整个生命周期内管理底层 ASG 的暖池资源。 | 2026 年 2 月 17 日 | | 已将权限添加至 [AWS托管策略：AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | 移除了 `AmazonEKSServiceRolePolicy` 中 `iam:GetInstanceProfile` 权限的目标实例配置文件名称中的“eks”前缀要求。这使得 Amazon EKS 自动模式能够在 NodeClasses 中验证和利用自定义实例配置文件，而无需“eks”命名前缀。 | 2026 年 2 月 2 日 | | 为 [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) 增加了权限。 | 已新增 `ec2:LockSnapshot` 权限，以使 EBS CSI 驱动程序能够直接锁定 EBS 快照。 | 2026 年 1 月 15 日 | | 引入 [AWS 托管式策略：AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess)。 | Amazon EKS 已发布一项全新的托管式策略 `AmazonEKSMCPReadOnlyAccess`，用于在 Amazon EKS MCP 服务器中启用只读工具，实现可观测性和问题排查功能。 | 2025 年 11 月 21 日 | | 为 [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) 增加了权限。 | 增加了 `ec2:CopyVolumes` 权限，支持 EBS CSI 驱动程序直接复制 EBS 卷。 | 2025 年 11 月 17 日 | | 已将权限添加至 [AWS托管策略：AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | 已为 `AmazonEKSServiceRolePolicy` 新增 `ec2:DescribeRouteTables` 和 `ec2:DescribeNetworkAcls` 权限。作为集群洞察功能的一部分，此项能力支持 Amazon EKS 检测混合节点的 VPC 路由表与网络 ACL 的配置问题。 | 2025 年 10 月 22 日 | | 为 [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) 添加了权限 | 已为 `AmazonEKSConnectorServiceRolePolicy` 新增 `ssmmessages:OpenDataChannel` 权限 | 2025 年 10 月 15 日 | | 已将权限添加至 [AWS托管策略：AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | 此角色可以附加新的访问策略 `AmazonEKSEventPolicy`。`ec2:DeleteLaunchTemplate` 和 `ec2:TerminateInstances` 的权限受限。 | 2025 年 8 月 26 日 | | 已将权限添加至 [AWS 托管策略：AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | 已将 `ssmmessages:OpenDataChannel` 权限添加至 `AmazonEKSLocalOutpostServiceRolePolicy`。 | 2025 年 6 月 26 日 | | 已将权限添加至 [AWS 托管策略：AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy)。 | 更新了 `ec2:RunInstances` 和 `ec2:CreateFleet` 操作的资源权限以包括容量预留 ` arn:aws:ec2:*:*:capacity-reservation/*`。这允许 Amazon EKS 自动模式使用您账户中的 EC2 按需容量预留来启动实例。添加了 `iam:CreateServiceLinkedRole` 以允许 Amazon EKS 自动模式代表您创建 EC2 竞价型实例服务相关角色 `AWSServiceRoleForEC2Spot`。 | 2025 年 6 月 20 日 | | 已将权限添加至 [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | 添加了 `ec2:DescribeCapacityReservations` 权限以允许 Amazon EKS 自动模式使用您账户中的 EC2 按需容量预留来启动实例。 | 2025 年 6 月 20 日 | | 引入 [AWS 托管策略：AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly)。 | 引入了新的 `AmazonEKSDashboardConsoleReadOnly` 策略。 | 2025 年 6 月 19 日 | | 引入 [AWS 托管策略：AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy)。 | 引入了新的 `AmazonEKSDashboardServiceRolePolicy` 策略。 | 2025 年 5 月 21 日 | | 已将权限添加至 [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy)。 | 添加了 `ec2:DeleteNetworkInterfaces` 权限，允许 Amazon EKS 删除 VPC CNI 意外退出时留下的弹性网络接口。 | 2025 年 4 月 16 日 | | 已将权限添加至 [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | 作为 EKS 1.33 版本发行的一部分，添加了 `ec2:RevokeSecurityGroupEgress` 和 `ec2:AuthorizeSecurityGroupEgress` 权限，允许 EKS AI/ML 客户向与 EFA 兼容的默认 EKS 集群安全组添加安全组出口规则。 | 2025 年 4 月 14 日 | | 已将权限添加至 [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | 增加了终止由 EKS 自动模式创建的 EC2 实例的权限。 | 2025 年 2 月 28 日 | | 为 [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) 增加了权限。 | 增加了授权 EBS CSI 驱动程序还原所有快照的新语句。此前现有策略允许这一操作，但由于 IAM 处理 `CreateVolume` 的方式发生了变化，因此需要新的显式语句。 增加了 EBS CSI 驱动程序修改现有卷上标签的功能。EBS CSI 驱动程序可以通过 Kubernetes VolumeAttributesClasses 中的参数修改现有卷的标签。 增加了 EBS CSI 驱动程序在 EBS 卷上启用快速快照还原（FSR）的功能。EBS CSI 驱动程序可以通过 Kubernetes 存储类中的参数在新卷上启用 FSR。 | 2025 年 1 月 13 日 | | 已将权限添加至 [AWS 托管策略：AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)。 | 更新了 `AmazonEKSLoadBalancingPolicy`，以允许列出和描述联网和 IP 地址资源。 | 2024 年 12 月 26 日 | | 已将权限添加至 [AWS托管策略：AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 | 为兼容中国区域，更新了 `AWSServiceRoleForAmazonEKSNodegroup`。 | 2024 年 11 月 22 日 | | 已将权限添加至 [AWS 托管策略：AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | 为 `AmazonEKSLocalOutpostClusterPolicy` 添加了 `ec2:DescribeAvailabilityZones` 权限，以便集群控制面板上的 AWS Cloud Controller Manager 可以识别各个节点所在的可用区。 | 2024 年 11 月 21 日 | | 已将权限添加至 [AWS托管策略：AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 | 更新了 `AWSServiceRoleForAmazonEKSNodegroup` 策略，允许 `ec2:RebootInstances`，以实现由 Amazon EKS 托管节点组创建的实例。限制了 Amazon EC2 资源的 `ec2:CreateTags` 权限。 | 2024 年 11 月 20 日 | | 已将权限添加至 [AWS托管策略：AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | EKS 更新了 AWS 托管策略 `AmazonEKSServiceRolePolicy`。添加了 EKS 访问策略、负载均衡器管理和自动集群资源清理的权限。 | 2024 年 11 月 16 日 | | 引入 [AWS 托管策略：AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy)。 | EKS 更新了 AWS 托管策略 `AmazonEKSComputePolicy`。更新了 `iam:AddRoleToInstanceProfile` 操作的资源权限。 | 2024 年 11 月 7 日 | | 引入 [AWS 托管策略：AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy)。 | AWS 引入了 `AmazonEKSComputePolicy`。 | 2024 年 11 月 1 日 | | 已将权限添加至 `AmazonEKSClusterPolicy` | 添加了 `ec2:DescribeInstanceTopology` 权限，允许 Amazon EKS 将拓扑信息作为标签附加到节点。 | 2024 年 11 月 1 日 | | 引入 [AWS 托管策略：AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)。 | AWS 引入了 `AmazonEKSBlockStoragePolicy`。 | 2024 年 10 月 30 日 | | 引入 [AWS 托管策略：AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)。 | AWS 引入了 `AmazonEKSLoadBalancingPolicy`。 | 2024 年 10 月 30 日 | | 已将权限添加至 [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy)。 | 添加了 `cloudwatch:PutMetricData` 权限，允许 Amazon EKS 向 Amazon CloudWatch 发布指标。 | 2024 年 10 月 29 日 | | 引入 [AWS 托管策略：AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)。 | AWS 引入了 `AmazonEKSNetworkingPolicy`。 | 2024 年 10 月 28 日 | | 增加了对 `AmazonEKSServicePolicy` 和 `AmazonEKSServiceRolePolicy` 的权限。 | 添加了 `ec2:GetSecurityGroupsForVpc` 和相关的标签权限，以允许 EKS 读取安全组信息和更新相关标签。 | 2024 年 10 月 10 日 | | 引入了 [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)。 | AWS 引入了 `AmazonEKSWorkerNodeMinimalPolicy`。 | 2024 年 10 月 3 日 | | 已将权限添加至 [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 | 添加了 `autoscaling:ResumeProcesses` 和 `autoscaling:SuspendProcesses` 权限，以允许 Amazon EKS 在 Amazon EKS 托管的自动扩缩组中暂停和恢复 `AZRebalance`。 | 2024 年 8 月 21 日 | | 已将权限添加至 [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 | 增加了 `ec2:DescribeCapacityReservations` 权限，以允许 Amazon EKS 描述用户账户的容量预留。增加了 `autoscaling:PutScheduledUpdateGroupAction` 权限，以在 `CAPACITY_BLOCK` 节点组上启用设置计划扩缩。 | 2024 年 6 月 27 日 | | [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) – 更新到现有策略 | Amazon EKS 添加了新的 `ec2:DescribeSubnets` 权限，允许适用于 Kubernetes 的 Amazon VPC CNI 插件查看 Amazon VPC 子网中的免费 IP 地址数量。VPC CNI 可以使用每个子网中的免费 IP 地址来选择空闲 IP 地址最多的子网，以便在创建弹性网络接口时使用。 | 2024 年 3 月 4 日 | | [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy)：更新现有策略 | Amazon EKS 添加了新的权限以允许 EKS 容器组身份。Amazon EKS 容器组身份代理使用节点角色。 | 2023 年 11 月 26 日 | | 推出了 [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy)。 | AWS 引入了 `AmazonEFSCSIDriverPolicy`。 | 2023 年 7 月 26 日 | | 已将权限添加至 [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy)。 | 增加了 `ec2:DescribeAvailabilityZones` 权限以允许 Amazon EKS 在创建负载均衡器时在子网自动发现期间获取可用区详细信息。 | 2023 年 2 月 7 日 | | 更新了 [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) 中的策略条件。 | 删除了 `StringLike` 键字段中带有通配符的无效策略条件。还将一个新条件 `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` 添加到 `ec2:DeleteVolume`，以允许 EBS CSI 驱动程序删除由树内插件创建的卷。 | 2022 年 11 月 17 日 | | 添加了对 [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) 的权限。 | 添加了 `ec2:DescribeVPCAttribute`、`ec2:GetConsoleOutput` 和 `ec2:DescribeSecret` 以实现更好的先决条件验证和托管式生命周期控制。还添加了 `ec2:DescribePlacementGroups`、`"arn:aws:ec2:*:*:placement-group/*"` 和 `ec2:RunInstances` 以支持控制面板 Amazon EC2 实例在 Outposts 上的置放控制。 | 2022 年 10 月 24 日 | | 更新了 [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) 中的 Amazon Elastic Container Registry 权限。 | 将操作 `ecr:GetDownloadUrlForLayer` 从所有资源部分移至限定范围部分。添加了资源 ` arn:aws:ecr:*:*:repository/eks/ `。删除了资源 ` arn:aws:ecr:`。此资源涵盖在增加的 ` arn:aws:ecr:*:*:repository/eks/*` 资源中。 | 2022 年 10 月 20 日 | | 将权限添加到了 [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)。 | 添加了 ` arn:aws:ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry 存储库，以便集群控制面板实例能够更新某些 `kubelet` 参数。 | 2022 年 8 月 31 日 | | 引入了 [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy)。 | AWS 引入了 `AmazonEKSLocalOutpostClusterPolicy`。 | 2022 年 8 月 24 日 | | 引入了 [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy)。 | AWS 引入了 `AmazonEKSLocalOutpostServiceRolePolicy`。 | 2022 年 8 月 23 日 | | 引入的 [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy)。 | AWS 引入了 `AmazonEBSCSIDriverPolicy`。 | 2022 年 4 月 4 日 | | 已添加权限到 [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy)。 | 增加了 `ec2:DescribeInstanceTypes` 以启用能够自动发现实例级别属性的 Amazon EKS 优化版 AMI。 | 2022 年 3 月 21 日 | | 已将权限添加至 [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)。 | 添加了 `autoscaling:EnableMetricsCollection` 权限以允许 Amazon EKS 启用指标收集。 | 2021 年 12 月 13 日 | | 已将权限添加至 [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy)。 | 添加了 `ec2:DescribeAccountAttributes`、`ec2:DescribeAddresses` 和 `ec2:DescribeInternetGateways` 权限，以允许 Amazon EKS 为 Network Load Balancer 创建服务相关角色。 | 2021 年 6 月 17 日 | | Amazon EKS 已开始跟踪更改。 | Amazon EKS 开始跟踪其AWS托管策略的更改。 | 2021 年 6 月 17 日 | # IAM 故障排除 本主题介绍将 Amazon EKS 与 IAM 结合使用时可能遇到的一些常见错误以及相应的错误处理方式。 ## AccessDeniedException 如果您在调用 AWS API 操作时收到 `AccessDeniedException`，则表明您使用的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)凭证不具有发起该调用所需的权限。 ``` An error occurred (AccessDeniedException) when calling the DescribeCluster operation: User: arn:aws:iam::111122223333:user/user_name is not authorized to perform: eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster ``` 在前述示例消息中，用户没有权限调用 Amazon EKS `DescribeCluster` API 操作。要为 IAM 主体提供 Amazon EKS 管理员权限，请参阅[Amazon EKS 基于身份的策略示例](security-iam-id-based-policy-examples.md)。 有关 IAM 的一般信息，请参阅 *IAM 用户指南*中的[使用策略控制访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)。 ## 无法在**计算**选项卡上看到**节点**，或在**资源**选项卡上看到任何内容，您将在 AWS 管理控制台 中收到错误 您可能会看到一条内容为“`Your current user or role does not have access to Kubernetes objects on this EKS cluster`”的控制台错误消息。确保您将 AWS 管理控制台 与其结合使用的 [IAM 主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)用户具有必要的权限。有关更多信息，请参阅 [所需的权限](view-kubernetes-resources.md#view-kubernetes-resources-permissions)。 ## aws-auth `ConfigMap` 不授予对集群的访问权限 [AWS IAM 身份验证器](https://github.com/kubernetes-sigs/aws-iam-authenticator)不允许在 `ConfigMap` 中使用角色 ARN 中的路径。因此，在指定 `rolearn` 之前，请删除路径。例如，将 ` arn:aws:iam::111122223333:role/team/developers/eks-admin ` 更改为 ` arn:aws:iam::111122223333:role/eks-admin `。 ## 我无权执行 iam:PassRole 如果您收到一个错误，表明您无权执行 `iam:PassRole` 操作，则必须更新策略以允许您将角色传递给 Amazon EKS。 有些 AWS 服务允许您将现有角色传递到该服务，而不是创建新服务角色或服务相关角色。为此，您必须具有将角色传递到服务的权限。 当名为 `marymajor` 的 IAM 用户尝试使用控制台在 Amazon EKS 中执行操作时，会发生以下示例错误。但是，服务必须具有服务角色所授予的权限才可执行此操作。Mary 不具有将角色传递到服务的权限。 ``` User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` 在这种情况下，必须更新 Mary 的策略以允许她执行 `iam:PassRole` 操作。 如果您需要帮助，请联系 AWS 管理员。您的管理员是提供登录凭证的人。 ## 我希望允许我的AWS账户以外的人访问我的 Amazon EKS 资源 您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表（ACL）的服务，您可以使用这些策略向人员授予对您的资源的访问权。 要了解更多信息，请参阅以下内容： + 要了解 Amazon EKS 是否支持这些功能，请参阅 [Amazon EKS 如何与 IAM 配合使用](security-iam-service-with-iam.md)。 + 要了解如何为您拥有的 AWS 账户中的资源提供访问权限，请参阅 *IAM 用户指南*中的[为您拥有的另一个 AWS 账户中的 IAM 用户提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。 + 要了解如何为第三方 AWS 账户提供您的资源的访问权限，请参阅*IAM 用户指南中的 [ 为第三方拥有的 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) 账户提供访问权限*。 + 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（身份联合验证）提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。 + 要了解使用角色和基于资源的策略进行跨账户访问之间的差别，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 ## 容器组（pod）容器收到以下错误：`An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region` 如果应用程序明确向 AWS STS 全局端点（`https://sts.amazonaws`）提出要求并且 Kubernetes 服务账户已配置为使用区域端点，您的容器会收到此错误。您可以使用以下选项之一解决问题： + 更新应用程序代码以删除对 AWS STS 全局端点的显式调用。 + 更新应用程序代码以明确调用区域端点，例如 `https://sts.us-west-2.amazonaws.com`。您的应用程序应内置冗余功能，以便在该 AWS 区域的服务出现故障时选择其它 AWS 区域。有关更多信息，请参阅《IAM 用户指南》中的[在 AWS 区域中管理 AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)。 + 将服务账户配置为使用全局端点。默认情况下，集群使用区域端点。有关更多信息，请参阅 [为服务账户配置 AWS Security Token Service 端点](configure-sts-endpoint.md)。 # Amazon EKS 集群 IAM 角色 每个集群都需要一个 Amazon EKS 集群 IAM 角色。由 Amazon EKS 管理的 Kubernetes 集群会使用此角色来管理节点，而[旧版云提供商](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)会使用此角色为服务创建带有 Elastic Load Balancing 的负载均衡器。 必须先使用以下任一 IAM policy 创建 IAM 角色，然后才能创建 Amazon EKS 集群： + [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) + 自定义 IAM policy。随后的最低权限允许 Kubernetes 集群管理节点，但不允许[旧版云提供商](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)创建带有 Elastic Load Balancing 的负载均衡器。您的自定义 IAM policy必须至少具有以下权限： ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "kubernetes.io/cluster/*" } } }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DescribeDhcpOptions", "ec2:DescribeAvailabilityZones", "ec2:DescribeInstanceTopology", "kms:DescribeKey" ], "Resource": "*" } ] } ``` **注意** 在 2023 年 10 月 3 日之前，每个集群的 IAM 角色都必须有 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)。 在 2020 年 4 月 16 日之前，[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) 和 [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) 是必需的，建议的角色名称是 `eksServiceRole`。有了 `AWSServiceRoleForAmazonEKS` 服务相关角色后，在 2020 年 4 月 16 日或之后创建的集群将不再需要 [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) 策略。 ## 检查现有集群角色 可使用以下程序检查并确定您的账户是否已有 Amazon EKS 集群角色。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在角色列表中搜索 `eksClusterRole`。如果不存在包含 `eksClusterRole` 的角色，请参阅 [创建 Amazon EKS 集群角色](#create-service-role) 来创建角色。如果包含 `eksClusterRole` 的角色确实存在，则选择角色以查看附加的策略。 1. 选择**权限**。 1. 确保将 **AmazonEKSClusterPolicy** 托管策略附加到此角色。如果附加该策略，则将正确配置 Amazon EKS 集群角色。 1. 选择 **Trust relationships**（信任关系），然后选择 **Edit trust policy**（编辑信任策略）。 1. 验证信任关系是否包含以下策略。如果信任关系符合以下策略，请选择 **Cancel**（取消）。如果信任关系不匹配，请将策略复制到**编辑信任策略**窗口并选择**更新策略**。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## 创建 Amazon EKS 集群角色 要创建集群角色，您可以使用 AWS 管理控制台 或 AWS CLI。 AWS 管理控制台 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 选择 **Roles**，然后选择 **Create role**。 1. 在**受信任的实体类型**下，选择 **AWS 服务**。 1. 从**其它 AWS 服务的使用案例**下拉列表中，选择 **EKS**。 1. 为您的使用案例选择 **EKS - Cluster**（EKS - 集群），然后选择 **Next**（下一步）。 1. 在 **Add permissions**（添加权限）选项卡上，选择 **Next**（下一步）。 1. 对于 **Role name**（角色名称），请为角色输入唯一名称，例如 `eksClusterRole`。 1. 对于 **Description**（说明），请输入描述性文本，例如 `Amazon EKS - Cluster role`。 1. 选择**创建角色**。 AWS CLI 1. 将以下内容复制到名为 *cluster-trust-policy.json* 的文件中。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. 创建角色。您可以将 *eksClusterRole* 替换为您选择的任何名称。 ``` aws iam create-role \ --role-name eksClusterRole \ --assume-role-policy-document file://"cluster-trust-policy.json" ``` 1. 将所需的 IAM policy 附加到角色。 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \ --role-name eksClusterRole ``` # Amazon EKS 节点 IAM 角色 Amazon EKS 节点 `kubelet` 守护进程代表您调用 AWS API。节点通过 IAM 实例配置文件和关联的策略获得这些 API 调用的权限。您必须先为节点创建 IAM 角色以在启动它们时使用，然后才能启动这些节点并在集群中注册它们。此要求适用于通过由 Amazon 提供的 Amazon EKS 优化版 AMI 启动的节点，也适用于您打算使用的任何其他节点 AMI。此外，此要求适用于托管节点组和自行管理的节点。 **注意** 您不能使用创建任何集群时使用的相同角色。 必须先使用以下权限创建 IAM 角色，然后才能创建节点： + `kubelet` 描述 VPC 中 Amazon EC2 资源的权限，例如 [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) 策略提供的权限。该策略还为 Amazon EKS 容器组身份代理提供权限。 + `kubelet` 使用来自 Amazon Elastic Container Registry（Amazon ECR）的容器映像的权限，例如 [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) 策略提供的权限。使用来自 Amazon Elastic Container Registry（Amazon ECR）的容器映像的权限是必要条件，因为用于联网的内置附加组件运行的 Pod 使用来自 Amazon ECR 的容器映像。 + （可选）Amazon EKS 容器组身份代理使用 `eks-auth:AssumeRoleForPodIdentity` 操作检索容器组凭证的权限。如果不使用 [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html)，则除了使用 EKS 容器组身份的 EC2 权限外，您还必须提供此权限。 + （可选）如果不使用 IRSA 或 EKS 容器组身份向 VPC CNI 容器组授予权限，则必须在实例角色中提供 VPC CNI 的权限。您可以使用 [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) 托管策略（如果使用 `IPv4` 系列创建集群）或[您创建的 IPv6 策略](cni-iam-role.md#cni-iam-role-create-ipv6-policy)（如果使用 `IPv6` 系列创建集群）。但是，我们建议您将策略附加到专门用于 Amazon VPC CNI 附加组件的单独角色，而不是附加到此角色。有关为 Amazon VPC CNI 附加组件创建单独角色的详细信息，请参阅 [配置 Amazon VPC CNI 插件以使用 IRSA](cni-iam-role.md)。 **注意** Amazon EC2 节点组必须具有与 Fargate 配置文件不同的 IAM 角色。有关更多信息，请参阅 [Amazon EKS 容器组（pod）执行 IAM 角色](pod-execution-role.md)。 ## 检查现有节点角色 可以使用以下过程检查并查看您的账户是否已有 Amazon EKS 节点角色。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在角色列表中搜索 `eksNodeRole`、`AmazonEKSNodeRole` 或 `NodeInstanceRole`。如果其中一个名称的角色不存在，请参阅[创建 Amazon EKS 节点 IAM 角色](#create-worker-node-role)以创建该角色。如果包含 `eksNodeRole`、`AmazonEKSNodeRole` 或 `NodeInstanceRole` 的角色确实存在，请选择该角色以查看附加的策略。 1. 选择**权限**。 1. 确保将 **AmazonEKSWorkerNodePolicy** 和 **AmazonEC2ContainerRegistryPullOnly** 托管策略附加到此角色，或者使用最低权限附加自定义策略。 **注意** 如果 **AmazonEKS\$1CNI\$1Policy** 策略已附加到角色，我们建议删除此策略并改为将其附加到映射到 `aws-node` Kubernetes 服务账户的 IAM 角色。有关更多信息，请参阅 [配置 Amazon VPC CNI 插件以使用 IRSA](cni-iam-role.md)。 1. 选择 **Trust relationships**（信任关系），然后选择 **Edit trust policy**（编辑信任策略）。 1. 验证信任关系是否包含以下策略。如果信任关系符合以下策略，请选择 **Cancel**（取消）。如果信任关系不匹配，请将策略复制到**编辑信任策略**窗口并选择**更新策略**。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Principal": { "Service": [ "ec2.amazonaws.com" ] } } ] } ``` ## 创建 Amazon EKS 节点 IAM 角色 您可以使用 AWS 管理控制台 或 AWS 创建节点 IAM 角色。 AWS 管理控制台 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **Roles**（角色）。 1. 在 **Roles**（角色）页面上，选择 **Create role**（创建角色）。 1. 在 **Select trusted entity**（选择受信任的实体）页面上，请执行以下操作： 1. 在**可信实体类型**部分中，选择 **AWS 服务**。 1. 在 **Use case**（使用案例）下，选择 **EC2**。 1. 选择**下一步**。 1. 在**添加权限**页面上，附加自定义策略或执行以下操作： 1. 在 **Filter policies (筛选器策略)** 框中，输入 `AmazonEKSWorkerNodePolicy`。 1. 选中搜索结果中的 **AmazonEKSWorkerNodePolicy** 左侧的复选框。 1. 请选择 **Clear filters**（清除筛选条件）。 1. 在 **Filter policies (筛选器策略)** 框中，输入 `AmazonEC2ContainerRegistryPullOnly`。 1. 选中搜索结果中的 **AmazonEC2ContainerRegistryPullOnly** 左侧的复选框。 **AmazonEKS\$1CNI\$1Policy** 托管式策略或您创建的 [IPv6 策略](cni-iam-role.md#cni-iam-role-create-ipv6-policy)还必须附加到此角色或映射到 `aws-node` Kubernetes 服务账户的其他角色。我们建议将策略分配给与 Kubernetes 服务账户关联的角色，而不是将其分配给此角色。有关更多信息，请参阅 [配置 Amazon VPC CNI 插件以使用 IRSA](cni-iam-role.md)。 1. 选择**下一步**。 1. 在 **Name, review, and create**（命名、查看和创建）页面中，请执行以下操作： 1. 对于 **Role name**（角色名称），请为角色输入唯一名称，例如 `AmazonEKSNodeRole`。 1. 对于 **Description**（说明），请将当前文本替换为描述性文本，例如 `Amazon EKS - Node role`。 1. 在**添加标签（可选）**下，将标签作为键值对附加，以将元数据添加到角色。有关在 IAM 中使用标签的更多信息，请参阅《IAM 用户指南》** 中的[标记 IAM 资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)。 1. 选择**创建角色**。 AWS CLI 1. 运行以下命令以创建 `node-role-trust-relationship.json` 文件。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Principal": { "Service": [ "ec2.amazonaws.com" ] } } ] } ``` 1. 创建 IAM 角色。 ``` aws iam create-role \ --role-name AmazonEKSNodeRole \ --assume-role-policy-document file://"node-role-trust-relationship.json" ``` 1. 将两个所需的 IAM 托管策略附加到 IAM 角色。 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \ --role-name AmazonEKSNodeRole aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \ --role-name AmazonEKSNodeRole ``` 1. 根据创建集群时使用的 IP 系列，将以下 IAM policy 之一附加到 IAM 角色。该策略必须附加到此角色，或与用于 Kubernetes 的 Amazon VPC CNI 插件的 Kubernetes `aws-node` 服务账户关联的角色。我们建议将策略分配给与 Kubernetes 服务账户关联的角色。要将策略分配给与 Kubernetes 服务账户关联的角色，请参阅 [配置 Amazon VPC CNI 插件以使用 IRSA](cni-iam-role.md)。 + IPv4 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --role-name AmazonEKSNodeRole ``` + IPv6 1. 复制以下文本并将其保存到名为 `vpc-cni-ipv6-policy.json` 的文件。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssignIpv6Addresses", "ec2:DescribeInstances", "ec2:DescribeTags", "ec2:DescribeNetworkInterfaces", "ec2:DescribeInstanceTypes" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ] } ] } ``` 1. 创建 IAM policy。 ``` aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json ``` 1. 将 IAM policy 附加到 IAM 角色。将 *111122223333* 替换为您的账户 ID。 ``` aws iam attach-role-policy \ --policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \ --role-name AmazonEKSNodeRole ``` # Amazon EKS 自动模式集群 IAM 角色 每个集群都需要一个 Amazon EKS 集群 IAM 角色。由 Amazon EKS 管理的 Kubernetes 集群使用此角色来自动执行存储、联网和计算自动扩缩等方面的例行任务。 在创建 Amazon EKS 集群之前，必须首先使用 EKS 自动模式必需的策略创建一个 IAM 角色。您可以附加建议的 AWS IAM 托管式策略，也可以创建具有等效权限的自定义策略。 + [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy) + [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) + [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) + [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) + [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) ## 检查现有集群角色 可使用以下程序检查并确定您的账户是否已有 Amazon EKS 集群角色。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在角色列表中搜索 `AmazonEKSAutoClusterRole`。如果不存在包含 `AmazonEKSAutoClusterRole` 的角色，请参阅下一部分的说明以创建该角色。如果包含 `AmazonEKSAutoClusterRole` 的角色确实存在，则选择角色以查看附加的策略。 1. 选择**权限**。 1. 确保将 **AmazonEKSClusterPolicy** 托管策略附加到此角色。如果附加该策略，则将正确配置 Amazon EKS 集群角色。 1. 选择 **Trust relationships**（信任关系），然后选择 **Edit trust policy**（编辑信任策略）。 1. 验证信任关系是否包含以下策略。如果信任关系符合以下策略，请选择 **Cancel**（取消）。如果信任关系不匹配，请将策略复制到**编辑信任策略**窗口并选择**更新策略**。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` **注意** AWS 不要求此角色使用名称 `AmazonEKSAutoClusterRole`。 ## 创建 Amazon EKS 集群角色 要创建集群角色，您可以使用 AWS 管理控制台 或 AWS CLI。 ### AWS 管理控制台 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 选择 **Roles**，然后选择 **Create role**。 1. 在**受信任的实体类型**下，选择 **AWS 服务**。 1. 从**其它 AWS 服务的使用案例**下拉列表中，选择 **EKS**。 1. 为您的使用案例选择 **EKS - Cluster**（EKS - 集群），然后选择 **Next**（下一步）。 1. 在**添加权限**选项卡上，选择相关策略，然后选择**下一步**。 + [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy) + [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) + [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) + [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) + [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) 1. 对于 **Role name**（角色名称），请为角色输入唯一名称，例如 `AmazonEKSAutoClusterRole`。 1. 对于 **Description**（说明），请输入描述性文本，例如 `Amazon EKS - Cluster role`。 1. 选择**创建角色**。 ### AWS CLI 1. 将以下内容复制到名为 *cluster-trust-policy.json* 的文件中。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 1. 创建角色。您可以将 *AmazonEKSAutoClusterRole* 替换为您选择的任何名称。 ``` aws iam create-role \ --role-name AmazonEKSAutoClusterRole \ --assume-role-policy-document file://"cluster-trust-policy.json" ``` 1. 将所需的 IAM 策略附加到角色： **AmazonEKSClusterPolicy**： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy ``` **AmazonEKSComputePolicy**： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy ``` **AmazonEKSBlockStoragePolicy**： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy ``` **AmazonEKSLoadBalancingPolicy**： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy ``` **AmazonEKSNetworkingPolicy**： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoClusterRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy ``` # Amazon EKS 自动模式节点 IAM 角色 **注意** 您不能使用创建任何集群时使用的相同角色。 在创建节点之前，必须首先创建具有以下策略或同等权限的 IAM 角色： + [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) + [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly) ## 检查现有节点角色 可以使用以下过程检查并查看您的账户是否已有 Amazon EKS 节点角色。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在角色列表中搜索 `AmazonEKSAutoNodeRole`。如果具有其中一个名称的角色不存在，请参阅下一部分的说明以创建该角色。如果包含 `AmazonEKSAutoNodeRole` 的角色确实存在，请选择该角色以查看附加的策略。 1. 选择**权限**。 1. 确保附加了上述必需的策略或等效自定义策略。 1. 选择 **Trust relationships**（信任关系），然后选择 **Edit trust policy**（编辑信任策略）。 1. 验证信任关系是否包含以下策略。如果信任关系符合以下策略，请选择 **Cancel**（取消）。如果信任关系不匹配，请将策略复制到**编辑信任策略**窗口并选择**更新策略**。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## 创建 Amazon EKS 节点 IAM 角色 您可以使用 AWS 管理控制台 或 AWS 创建节点 IAM 角色。 ### AWS 管理控制台 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **Roles**（角色）。 1. 在 **Roles**（角色）页面上，选择 **Create role**（创建角色）。 1. 在 **Select trusted entity**（选择受信任的实体）页面上，请执行以下操作： 1. 在**可信实体类型**部分中，选择 **AWS 服务**。 1. 在 **Use case**（使用案例）下，选择 **EC2**。 1. 选择**下一步**。 1. 在**添加权限**页面上，附加以下策略： + [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) + [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly) 1. 在 **Name, review, and create**（命名、查看和创建）页面中，请执行以下操作： 1. 对于 **Role name**（角色名称），请为角色输入唯一名称，例如 `AmazonEKSAutoNodeRole`。 1. 对于 **Description**（说明），请将当前文本替换为描述性文本，例如 `Amazon EKS - Node role`。 1. 在**添加标签（可选）**下，将标签作为键值对附加，以将元数据添加到角色。有关在 IAM 中使用标签的更多信息，请参阅《IAM 用户指南》** 中的[标记 IAM 资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)。 1. 选择**创建角色**。 ### AWS CLI **创建节点 IAM 角色** 使用上一步中的 **node-trust-policy.json** 文件来定义哪些实体可以代入该角色。运行以下命令以创建节点 IAM 角色： ``` aws iam create-role \ --role-name AmazonEKSAutoNodeRole \ --assume-role-policy-document file://node-trust-policy.json ``` **记下角色 ARN** 创建角色后，检索并保存节点 IAM 角色的 ARN。在后续步骤中，您将需要此 ARN。使用以下命令来获取 ARN： ``` aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text ``` **附加必需的策略** 将以下 AWS 托管式策略附加到节点 IAM 角色，以提供必要的权限： 附加 AmazonEKSWorkerNodeMinimalPolicy： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy ``` 附加 AmazonEC2ContainerRegistryPullOnly： ``` aws iam attach-role-policy \ --role-name AmazonEKSAutoNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly ``` # Amazon EKS 功能 IAM 角色 EKS 功能需要配置功能 IAM 角色（或功能角色）。EKS 功能使用此角色对 AWS 服务执行操作，并通过自动创建的访问条目访问集群中的 Kubernetes 资源。 在功能创建期间指定功能角色之前，您必须创建具有相应信任策略和相应功能类型的权限的 IAM 角色。创建此 IAM 角色后，可以将其重用于任意数量的功能资源。 ## 功能角色要求 功能角色必须满足以下要求： + 该角色必须与集群和功能资源位于同一 AWS 账户中 + 该角色必须拥有信任策略，以允许 EKS 功能服务代入该角色 + 该角色必须拥有与功能类型和使用案例要求相适应的权限（请参阅[按功能类型划分的权限](#capability-permissions)） ## 功能角色的信任策略 所有功能角色必须包含以下信任策略： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "capabilities.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 此信任策略允许 EKS 执行以下操作： + 担任该角色，以执行 AWS API 操作 + 标记会话以进行审计和跟踪 ## 按功能类型划分的权限 所需的 IAM 权限取决于您使用的功能和部署模式。 **注意** 对于搭配使用 IAM 角色选择器与 ACK 的生产部署，或者在没有 AWS 服务集成的情况下使用 kro 或 Argo CD 时，功能角色可能不需要信任策略之外的任何 IAM 权限。 **kro（Kube Resource Orchestrator）** 不需要 IAM 权限。您可以创建没有附加策略的功能角色。kro 只需要 Kubernetes RBAC 权限即可创建和管理 Kubernetes 资源。 ** AWS Controllers for Kubernetes（ACK）** ACK 支持两种权限模型： + **简单设置（开发/测试）**：直接向功能角色添加 AWS 服务权限。这非常适合入门级的单账户部署或所有用户都需要相同权限的情况。 + **生产最佳实践**：使用 IAM 角色选择器，实施最低权限访问。使用这种方法，功能角色只需要获得 `sts:AssumeRole` 权限即可代入服务特定角色。您无需向功能角色本身添加 AWS 服务权限（如 S3 或 RDS），系统会将这些权限授予映射到特定命名空间的各个 IAM 角色。 IAM 角色选择器可启用以下功能： + 命名空间级别权限隔离 + 跨账户资源管理 + 团队特定 IAM 角色 + 最低权限安全模型 IAM 角色选择器方法的功能角色策略示例： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/ACK-S3-Role", "arn:aws:iam::111122223333:role/ACK-RDS-Role", "arn:aws:iam::444455556666:role/ACKCrossAccountRole" ] } ] } ``` 有关包括 IAM 角色选择器在内的 ACK 权限配置的详细信息，请参阅[配置 ACK 权限](ack-permissions.md)。 **Argo CD** 默认情况下，不需要 IAM 权限。以下功能可能需要可选权限： + ** AWS Secrets Manager**：如果使用 Secrets Manager 来存储 Git 存储库凭证 + ** AWS CodeConnections**：如果使用 CodeConnections 进行 Git 存储库身份验证 Secrets Manager 和 CodeConnections 策略示例： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*" }, { "Effect": "Allow", "Action": [ "codeconnections:UseConnection", "codeconnections:GetConnection" ], "Resource": "arn:aws:codeconnections:region:account-id:connection/*" } ] } ``` 有关 Argo CD 权限要求的详细信息，请参阅 [Argo CD 注意事项](argocd-considerations.md)。 ## 检查现有功能角色 您可使用以下过程来检查账户是否已具有适合您使用案例的功能 IAM 角色。 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 在左侧导航窗格中，选择 **角色**。 1. 在角色列表中搜索功能角色名称（例如，`ACKCapabilityRole` 或 `ArgoCDCapabilityRole`）。 1. 如果存在角色，请选择该角色，查看附加策略和信任关系。 1. 选择 **Trust relationships**（信任关系），然后选择 **Edit trust policy**（编辑信任策略）。 1. 验证信任关系是否与[功能信任策略](#capability-trust-policy)相匹配。如果不匹配，请更新信任策略。 1. 选择**权限**并验证该角色是否具有适用于您的功能类型和使用案例的权限。 ## 创建功能 IAM 角色 要创建功能角色，您可以使用 AWS 管理控制台 或 AWS CLI。 ** AWS 管理控制台 ** 1. 通过 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。 1. 选择 **Roles**，然后选择 **Create role**。 1. 对于**可信实体类型**，选择**自定义信任策略**。 1. 将[功能信任策略](#capability-trust-policy)复制并粘贴到信任策略编辑器中。 1. 选择**下一步**。 1. 在**添加权限**选项卡上，选择或创建适合您的功能类型的策略（请参阅[按功能类型划分的权限](#capability-permissions)）。对于 kro，您可以跳过此步骤。 1. 选择**下一步**。 1. 对于**角色名称**，请为角色输入唯一名称，例如 `ACKCapabilityRole`、`ArgoCDCapabilityRole` 或 `kroCapabilityRole`。 1. 对于 **Description**（说明），请输入描述性文本，例如 `Amazon EKS - ACK capability role`。 1. 选择**创建角色**。 **AWS CLI** 1. 将[功能信任策略](#capability-trust-policy)复制到名为 `capability-trust-policy.json` 的文件中。 1. 创建角色。将 `ACKCapabilityRole` 替换为您所需的角色名称。 ``` aws iam create-role \ --role-name ACKCapabilityRole \ --assume-role-policy-document file://capability-trust-policy.json ``` 1. 将所需的 IAM 策略附加到角色。对于 ACK，请为要管理的 AWS 服务附加策略。对于 Argo CD，请根据需要为 Secrets Manager 或 CodeConnections 附加策略。对于 kro，您可以跳过此步骤。 具有 S3 权限的 ACK 示例： ``` aws iam put-role-policy \ --role-name ACKCapabilityRole \ --policy-name S3Management \ --policy-document file://s3-policy.json ``` ## 对功能角色问题进行问题排查 **功能创建失败，并显示“IAM 角色无效”** 验证： + 该角色与集群位于同一账户中 + 信任策略与[功能信任策略](#capability-trust-policy)相匹配 + 您拥有该角色的 `iam:PassRole` 权限 **功能显示权限错误** 验证： + 该角色具有此功能类型所需的 IAM 权限 + 该角色的访问条目存在于集群上 + 如有需要，还可配置其他 Kubernetes 权限（请参阅[其他 Kubernetes 权限](capabilities-security.md#additional-kubernetes-permissions)） **ACK 资源失败并出现“权限被拒绝”错误** 验证： + 此角色具有您的使用案例所需的 IAM 权限 + 对于引用密钥的 ACK 控制器，请确保已将范围限定为相应命名空间的 `AmazonEKSSecretReaderPolicy` 访问条目策略进行了关联。 有关更多问题排查指导，请参阅[EKS 功能的安全注意事项](capabilities-security.md)。