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

身份和访问管理

Id@@ entity and Access Managem ent (IAM) 是一项 AWS 服务，它执行两个基本功能：身份验证和授权。身份验证涉及身份验证，而授权则控制 AWS 资源可以执行的操作。在 AWS 中，资源可以是其他 AWS 服务，例如 EC2，也可以是 AWS 委托人，例如 I AM 用户或角色。管理允许资源执行的操作的规则以 IAM 策略表示。

控制 EKS 集群的访问权限

Kubernetes 项目支持各种不同的策略来验证对 kube-apiserver 服务的请求，例如不记名令牌、X.509 证书、OIDC 等。EKS 目前原生支持 webhook 令牌身份验证、服务账户令牌以及截至 2021 年 2 月 21 日的 OIDC 身份验证。

Webhook 身份验证策略调用一个 webhook 来验证不记名令牌。在 EKS 上，这些不记名令牌是在您运行kubectl命令时由 AWS CLI 或aws-iam-authenticator客户端生成的。当你执行命令时，令牌会被传递给 kube-apiserver，kube-apiserver 会将其转发到身份验证 webhook。如果请求格式正确，则 webhook 会调用嵌入在令牌正文中的预签名 URL。此 URL 会验证请求的签名，并返回有关用户的信息，例如用户的账户、Arn 和 UserId kube-apiserver。

要手动生成身份验证令牌，请在终端窗口中键入以下命令：

aws eks get-token --cluster-name <cluster_name>

您也可以通过编程方式获取代币。以下是用 Go 编写的示例：

package main

import (
  "fmt"
  "log"
  "sigs.k8s.io/aws-iam-authenticator/pkg/token"
)

func main()  {
  g, _ := token.NewGenerator(false, false)
  tk, err := g.Get("<cluster_name>")
  if err != nil {
    log.Fatal(err)
  }
  fmt.Println(tk)
}

输出应如下所示：

{
  "kind": "ExecCredential",
  "apiVersion": "client.authentication.k8s.io/v1alpha1",
  "spec": {},
  "status": {
    "expirationTimestamp": "2020-02-19T16:08:27Z",
    "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz"
  }
}

每个标记以开头，k8s-aws-v1.后跟一个 base64 编码的字符串。解码后的字符串应类似于以下内容：

https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393

该令牌由包含亚马逊凭证和签名的预签名 URL 组成。有关更多详细信息，请参阅 https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html。

代币的存活时间 (TTL) 为 15 分钟，之后需要生成一个新代币。当您使用客户端时，会自动处理此问题kubectl，但是，如果您使用的是 Kubernetes 控制面板，则每次令牌到期时都需要生成新令牌并重新进行身份验证。

AWS IAM 服务对用户的身份进行身份验证后，kube-apiserver 就会读取kube-system命名空间aws-auth ConfigMap 中的内容，以确定要与该用户关联的 RBAC 组。用于在 aws-auth ConfigMap IAM 委托人（即 IAM 用户和角色）与 Kubernetes RBAC 组之间创建静态映射。可以在 Kub RoleBindings ernetes 中引用 RBAC 群组，或者。ClusterRoleBindings它们与 IAM 角色的相似之处在于，它们定义了一组可以对 Kubernetes 资源（对象）集合执行的操作（动词）。

集群访问管理器

集群访问管理器现在是管理 AWS IAM 委托人对 Amazon EKS 集群的访问的首选方式，它是 AWS API 的一项功能，也是 EKS v1.23 及更高版本集群（新集群或现有集群）的可选功能。它简化了 AWS IAM 和 Kubernetes 之间的身份映射RBACs，无需在 AWS 和 Kubernetes 之间切换 APIs 或编辑访问管理，从而减少了aws-auth ConfigMap 运营开销，并有助于解决配置错误。该工具还允许集群管理员撤销或完善自动授予用于创建集群的 AWS IAM 委托人的cluster-admin权限。

此 API 依赖于两个概念：

在启动时，Amazon EKS 仅支持预定义策略和 AWS 托管策略。访问策略不是 IAM 实体，由 Amazon EKS 定义和管理。

集群访问管理器允许将上游 RBAC 与支持允许和通过（但不拒绝）有关 API 服务器请求的 Kubernetes AuthZ 决策的访问策略相结合。当上游 RBAC 和 Amazon EKS 授权机构都无法确定请求评估的结果时，就会做出拒绝决定。

借助此功能，Amazon EKS 支持三种身份验证模式：

首先，集群管理员可以创建或更新 Amazon EKS 集群，将首选身份验证设置为API_AND_CONFIG_MAP或API方法，并定义访问条目以授予所需的 AWS IAM 委托人访问权限。

$ aws eks create-cluster \
    --name <CLUSTER_NAME> \
    --role-arn <CLUSTER_ROLE_ARN> \
    --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
    --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false

上面的命令是在没有集群创建者管理员权限的情况下创建 Amazon EKS 集群的示例。

可以使用命令更新 Amazon EKS 集群配置以启用 A API uthenticationMod update-cluster-config e，要使用该命令在现有集群上执行此操作，CONFIG_MAP则必须先更新到，API_AND_CONFIG_MAP然后再更新到。API这些操作无法恢复，这意味着无法从或切换API到API_AND_CONFIG_MAP或CONFIG_MAP以及从切换API_AND_CONFIG_MAP到CONFIG_MAP。

$ aws eks update-cluster-config \
    --name <CLUSTER_NAME> \
    --access-config authenticationMode=API

API 支持添加和撤消对集群的访问权限的命令，以及验证指定集群的现有访问策略和访问条目的命令。创建的默认策略是为了匹配 KubernetesRBACs ，如下所示。

$ aws eks list-access-policies
{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

在没有集群创建者管理员权限的情况下创建集群时，没有访问条目可用，这是默认情况下创建的唯一条目。

aws-auth ConfigMap （已弃用）

Kubernetes 与 AWS 身份验证集成的一种方法是通过 aws-auth ConfigMap，它位于命名空间中。kube-system它负责将 AWS IAM 身份（用户、群组和角色）身份验证映射到 Kubernetes 基于角色的访问控制 (RBAC) 授权。aws-auth ConfigMap 是在您的 Amazon EKS 集群的预配置阶段自动创建的。它最初是为了允许节点加入您的集群而创建的，但如前所述，您也可以使用它 ConfigMap 来添加对 IAM 委托人的 RBACs 访问权限。

要检查您的集群 aws-auth ConfigMap，您可以使用以下命令。

kubectl -n kube-system get configmap aws-auth -o yaml

这是的默认配置示例aws-authConfigMap。

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID>
      username: system:node:{{SessionName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2023-10-22T18:19:30Z"
  name: aws-auth
  namespace: kube-system

它的主会话位于mapRoles区块下方data，它基本上由 3 个参数组成。 ConfigMap

也可以映射 AWS IAM 用户的权限，data在下面为mapUsers替换 userarn 的 rolearn 参数定义一个新的配置块，但作为最佳实践，始终建议用户改为使用它。aws-auth ConfigMap mapRoles

要管理权限，您可以编辑aws-auth ConfigMap 添加或移除对 Amazon EKS 集群的访问权限。尽管可以aws-auth ConfigMap 手动编辑，但建议使用诸如此类的工具，因为这是一个非常敏感的配置eksctl，不准确的配置可能会将您锁定在 Amazon EKS 集群之外。有关更多详细信息，请查看 ConfigMap下面的 “使用工具对 aws-auth 进行更改” 小节。

集群访问建议

将 EKS 集群终端节点设为私有

默认情况下，当您配置 EKS 集群时，API 集群终端节点设置为公共终端节点，即可以从互联网进行访问。尽管可以从互联网访问，但终端节点仍然被认为是安全的，因为它要求所有 API 请求都必须通过 IAM 进行身份验证，然后由 Kubernetes RBAC 授权。也就是说，如果您的公司安全策略要求您限制从 Internet 访问 API 或禁止您在集群 VPC 之外路由流量，则您可以：

请勿使用服务帐号令牌进行身份验证

服务帐号令牌是一种长期存在的静态凭证。如果该令牌遭到入侵、丢失或被盗，攻击者可能能够执行与该令牌相关的所有操作，直到服务帐户被删除。有时，对于必须从集群外部使用 Kubernetes API 的应用程序，例如 CI/CD 管道应用程序，您可能需要允许例外。如果此类应用程序在 AWS 基础设施（如 EC2 实例）上运行，请考虑使用实例配置文件并将其映射到 Kubernetes RBAC 角色。

采用 AWS 资源的最低权限访问权限

IAM 用户无需获得 AWS 资源的权限即可访问 Kubernetes API。如果您需要授予 IAM 用户访问 EKS 集群的权限，请在中aws-auth ConfigMap 为该用户创建一个映射到特定 Kubernetes RBAC 组的条目。

从集群创建者主体中移除集群管理员权限

默认情况下，Amazon EKS 集群是使用绑定到集群创建者主体的永久cluster-admin权限创建的。使用集群访问管理器 API，在使用API_AND_CONFIG_MAP或API身份验证模式时false，无需将此权限设置为，--access-config bootstrapClusterCreatorAdminPermissions即可创建集群。撤消此访问权限被认为是最佳实践，可以避免对集群配置进行任何不必要的更改。撤消此访问权限的过程与撤消对集群的任何其他访问权限的过程相同。

API 允许您灵活地仅解除 IAM 委托人与访问策略的关联，在本例中AmazonEKSClusterAdminPolicy为。

$ aws eks list-associated-access-policies \
    --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN. \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

或者完全删除与该cluster-admin权限关联的访问条目。

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

$ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

在事件、紧急情况或无法访问集群的情况下，如果需要，可以再次授予此访问权限。

如果集群仍配置了CONFIG_MAP身份验证方法，则应通过向所有其他用户授予访问集群的权限 aws-auth ConfigMap，配置完成后 aws-auth ConfigMap ，可以删除分配给创建集群的实体的角色，并且只能在发生事件、紧急情况或破碎玻璃情形，或者群集损坏而无法访问集群时才能重新创建。aws-auth ConfigMap 这在生产集群中可能特别有用。

当多个用户需要相同的集群访问权限时，请使用 IAM 角色

与其为每个 IAM 用户创建条目，不如允许这些用户担任 IAM 角色并将该角色映射到 Kubernetes RBAC 群组。这将更易于维护，尤其是在需要访问权限的用户数量增加的情况下。

如果仍使用 aws-auth ConfigMap 作为身份验证方法，则在向 IAM 角色分配 K8s RBAC 权限时，应在用户名中包含\ {{SessionName}}。这样，审核日志将记录会话名称，这样您就可以跟踪实际用户是谁担任此角色以及日 CloudTrail 志。

- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole
  username: testRole:{{SessionName}}
  groups:
    - system:masters

创建时使用最低特权访问权限 RoleBindings 和 ClusterRoleBindings

就像前面关于授予 AWS 资源访问权限的观点一样，RoleBindings 并且 ClusterRoleBindings 应仅包括执行特定功能所需的权限集。除非绝对必要， ClusterRoles 否则请避免["*"]在角色中使用。如果你不确定要分配什么权限，可以考虑使用像 a udit2rbac 这样的工具，根据在 Kubernetes 审计日志中观察到的 API 调用自动生成角色和绑定。

使用自动流程创建集群

如前面的步骤所示，在创建 Amazon EKS 集群时，如果不使用使用API_AND_CONFIG_MAP或API身份验证模式，并且不选择向集群创建者委派cluster-admin权限，则在集群的 RBAC 配置中，IAM 实体用户或角色（例如创建集群的联合用户）将自动获得system:masters权限。即使是移除此权限的最佳实践，如本文所述，如果使用CONFIG_MAP身份验证方法 aws-auth ConfigMap，则无法撤消此访问权限。因此，最好使用与专用 IAM 角色绑定的基础设施自动化管道创建集群，其他用户或实体不具备任何权限，并定期审计该角色的权限、策略以及有权触发管道的人员。此外，不应使用此角色在集群上执行例行操作，而应专门用于由管道触发的集群级别操作，例如，通过 SCM 代码更改触发。

使用专用 IAM 角色创建集群

创建 Amazon EKS 集群时，会自动向 IAM 实体用户或角色（例如创建集群的联合用户）授予该集群的 RBAC system:masters 配置中的权限。此访问权限无法删除，也不能通过进行管理aws-auth ConfigMap。因此，最好创建具有专用 IAM 角色的集群，并定期审计谁可以担任此角色。不应使用此角色在群集上执行例行操作，而是应为此向其他用户授予访问群集aws-auth ConfigMap 的权限。配置完成后，应保护该角色，并且仅在临时提升的权限模式下使用/break glass，以其他方式无法访问集群。aws-auth ConfigMap 这在未配置直接用户访问权限的集群中特别有用。

定期审核对集群的访问权限

谁需要访问权限可能会随着时间的推移而发生变化。计划定期审计，aws-auth ConfigMap 以查看谁获得了访问权限以及他们被分配了哪些权限。您还可以使用开源工具（例如 kubectl-who-can，或 rbac-lookup）来检查绑定到特定服务帐号、用户或群组的角色。当我们进入审计部分时，我们将进一步探讨这个话题。其他想法可以在NCC集团的这篇文章中找到。

如果依赖 aws-auth ConfigMap，请使用工具进行更改

格式不正确的 aws-auth ConfigMap 可能会导致您无法访问集群。如果您需要对进行更改 ConfigMap，请使用工具。

eksctl CL eksctl I 包含一个用于向 aws-auth 添加身份映射的命令。 ConfigMap

查看 CLI 帮助：

$ eksctl create iamidentitymapping --help
...

检查映射到您的 Amazon EKS 集群的身份。

$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION
ARN                                                                   USERNAME                        GROUPS                                                  ACCOUNT
arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID>      system:node:{{SessionName}}     system:bootstrappers,system:nodes,system:node-proxier

将 IAM 角色设为集群管理员：

$ eksctl create iamidentitymapping --cluster  <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin
...

如需了解更多信息，请查看eksctl文档

keikoproj 的 aws-auth

aws-authby keikoproj 包括一个 cli 和 go 库。

下载并查看帮助 CLI 帮助：

$ go get github.com/keikoproj/aws-auth
...
$ aws-auth help
...

或者，aws-auth使用适用于 kubectl 的 ku rew 插件管理器进行安装。

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

请查看 aws-auth 文档 GitHub以获取更多信息，包括 go 库。

AWS IAM Authenticator IAM Auth

该aws-iam-authenticator项目包括用于更新的 CLI ConfigMap。

在上下载发行版 GitHub。

向 IAM 角色添加集群权限：

$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config
...

身份验证和访问管理的替代方法

虽然 IAM 是对需要访问 EKS 集群的用户进行身份验证的首选方式，但也可以使用 OIDC 身份提供商，例如GitHub 使用身份验证代理和 Kubernetes 模拟。AWS 开源博客上已经发布了两个此类解决方案的文章：

您还可以使用 AWS SSO 将 AW S 与外部身份提供商（例如 Azure AD）联合起来。如果您决定使用此功能，AWS CLI v2.0 包含一个用于创建命名配置文件的选项，可轻松将 SSO 会话与您当前的 CLI 会话关联并担任 IAM 角色。请注意，在运行之前，您必须代入一个角色，kubectl因为 IAM 角色用于确定用户的 Kubernetes RBAC 组。

EKS 容器的身份和凭证

在 Kubernetes 集群中运行的某些应用程序需要获得调用 Kubernetes API 的权限才能正常运行。例如，AWS Load Balancer 控制器需要能够列出服务的终端节点。控制器还需要能够调用 AWS APIs 来配置和配置 ALB。在本节中，我们将探讨为 Pod 分配权限和权限的最佳实践。

Kubernetes 服务账号

服务账号是一种特殊类型的对象，允许你为容器分配 Kubernetes RBAC 角色。系统会自动为集群中的每个命名空间创建一个默认服务帐户。当您在不引用特定服务帐户的情况下将 Pod 部署到命名空间时，该命名空间的默认服务帐户将自动分配给该 Pod，而 Secret（即该服务帐户的服务帐户 (JWT) 令牌）将作为卷安装到该 Pod 上。/var/run/secrets/kubernetes.io/serviceaccount解码该目录中的服务账号令牌将显示以下元数据：

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba",
  "sub": "system:serviceaccount:default:default"
}

默认服务账号对 Kubernetes API 具有以下权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-01-30T18:13:25Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "43"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
  uid: 350d2ab8-438c-11ea-9438-063a49b60fba
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get

此角色授权未经身份验证和经过身份验证的用户读取 API 信息，并且被认为是安全的，可以公开访问。

当在 Pod 中运行的应用程序调用 Kubernetes 时 APIs，需要为该 Pod 分配一个服务账户，明确授予其调用这些服务的权限。 APIs与用户访问指南类似，角色或 ClusterRole 绑定到服务帐号的权限应仅限于应用程序运行所需的 API 资源和方法，仅限于其他任何内容。要使用非默认服务帐号，只需将 Pod 的spec.serviceAccountName字段设置为您要使用的服务帐号名称即可。有关创建服务帐号的更多信息，请参阅 https://kubernetes。 io/docs/reference/access-authn-authz/rbac/# service-account-permissions。

服务账户的 IAM 角色 (IRSA)

IRSA 是一项允许您为 Kubernetes 服务账户分配 IAM 角色的功能。它通过利用名为服务账户代币量投影的 Kubernetes 功能来工作。当 Pod 配置了引用 IAM 角色的服务账户时，Kubernetes API 服务器将在启动时调用集群的公共 OIDC 发现终端节点。端点对由 Kubernetes 发行的 OIDC 令牌进行加密签名，并将生成的令牌作为一个卷挂载。此签名令牌允许 Pod 调用 AWS APIs 关联的 IAM 角色。调用 AWS API 时，AWS 会 SDKs 调用sts:AssumeRoleWithWebIdentity。验证令牌的签名后，IAM 将 Kubernetes 颁发的令牌交换为临时的 AWS 角色证书。

使用 IRSA 时，务必重复使用 AWS 开发工具包会话，以避免不必要地调用 AWS STS。

解码 IRSA 的（JWT）令牌将生成类似于以下示例的输出：

{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1582306514,
  "iat": 1582220114,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "alpine-57b5664646-rf966",
      "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436"
    },
    "serviceaccount": {
      "name": "s3-read-only",
      "uid": "a720ba5c-5406-11ea-9438-063a49b60fba"
    }
  },
  "nbf": 1582220114,
  "sub": "system:serviceaccount:default:s3-read-only"
}

此特定令牌通过担任 IAM 角色向 S3 授予 Pod 仅限查看的权限。当应用程序尝试从 S3 读取时，会将该令牌交换为一组临时的 IAM 证书，如下所示：

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc",
        "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc"
    },
    "Audience": "sts.amazonaws.com",
    "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only",
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=",
        "Expiration": "2020-02-20T18:49:50Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

作为 EKS 控制平面一部分运行的变异 webhook 将 AWS 角色 ARN 和网络身份令牌文件的路径作为环境变量注入 Pod。这些值也可以手动提供。

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

当预计代币超过其总TTL的80％或24小时后，kubelet将自动轮换该代币。AWS 负责 SDKs 在令牌轮换时重新加载代币。有关 IRSA 的更多信息，请参阅 https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html。

EKS 容器组身份

EKS Pod Identities 是 re: Invent 2023 上推出的一项功能，允许您为 kubernetes 服务账户分配 IAM 角色，而无需为 AWS 账户中的每个集群配置 Open Id Connect (OIDC) 身份提供商 (IDP)。要使用 EKS Pod Identity，您必须在每个符合条件的工作节点上部署一个作为 DaemonSet Pod 运行的代理。此代理作为 EKS 附加组件提供给您，并且是使用 EKS Pod 身份功能的先决条件。您的应用程序必须使用支持版本的 AWS 开发工具包才能使用此功能。

为 Pod 配置 EKS Pod 身份后，EKS 将在上安装并刷新容器身份令牌/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token。AWS 开发工具包将使用此令牌与 EKS Pod Identity Agent 通信，后者使用 pod 身份令牌和代理的 IAM 角色通过调用 AssumeRoleForPodIdentityAPI 为您的容器创建临时证书。交付给您的 pod 的 pod 身份令牌是从您的 EKS 集群颁发的 JWT，并经过加密签名，并带有相应的 JWT 声明，可与 EKS Pod 身份一起使用。

要了解有关 EKS Pod 身份的更多信息，请参阅此博客。

您无需对应用程序代码进行任何修改即可使用 EKS Pod 身份。支持的 AWS 开发工具包版本将使用凭证提供者链自动发现通过 EKS Pod 身份提供的证书。与 IRSA 一样，EKS Pod 身份会在您的 pod 中设置变量，以指导他们如何查找 AWS 证书。

使用 EKS Pod 身份的 IAM 角色

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceOrgId": "${aws:ResourceOrgId}"
        }
      }
    }
  ]
}

AWS 建议使用诸如此类的条件键aws:SourceOrgId来帮助防范跨服务混乱的副手问题。在上面的角色信任策略示例中，ResourceOrgId是一个变量，等于 AWS 账户所属的 AWS 组织的 AWS 组织标识。EKS 将传入一个与担任 EKS Pod Identitions 角色时的值aws:SourceOrgId相等的值。

ABAC 和 EKS Pod 身份

当 EKS Pod 身份担任 IAM 角色时，它会设置以下会话标签：

这些会话标签允许您使用基于属性的访问控制 (ABAC)，仅向特定的 kubernetes 服务账户授予对您的 AWS 资源的访问权限。这样做时，必须明白 kubernetes 服务帐户仅在命名空间中是唯一的，而 kubernetes 命名空间仅在 EKS 集群中是唯一的。可以使用aws:PrincipalTag/<tag-key>全局条件密钥在 AWS 策略中访问这些会话标签，例如 aws:PrincipalTag/eks-cluster-arn

例如，如果您只想向特定的服务账户授予访问权限，以便通过 IAM 或资源策略访问您账户中的 AWS 资源，则需要检查eks-cluster-arn并kubernetes-namespace标记，并确保只有目标集群中的服务账户才能访问该资源，因为其他集群可能具有相同的kubernetes-service-accounts和kubernetes-namespaces。kubernetes-service-account

此示例 S3 存储桶策略仅在eks-cluster-arn所有对象都满足预期值时才授予访问其所连接的 S3 存储桶中的对象的权限，其中 EKS 集群托管在 AWS 账户中111122223333。kubernetes-service-account kubernetes-namespace

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "s3:*",
            "Resource":            [
                "arn:aws:s3:::ExampleBucket/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "s3objectservice",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace"
                }
            }
        }
    ]
}

EKS Pod 身份与 IRSA 的比较

EKS Pod 身份和 IRSA 都是向 EKS 容器提供临时 AWS 证书的首选方式。除非您有 IRSA 的特定用例，否则我们建议您在使用 EKS 时使用 EKS Pod 身份。此表有助于比较这两个功能。

EKS pod 的身份和凭证推荐

更新 aws-node 守护程序集以使用 IRSA

目前，aws-node 守护程序集已配置为使用分配给 EC2 实例的角色来分配给 pod。 IPs 该角色包括多个 AWS 托管策略，例如 Amazoneks_cni_policy，这些策略实际上允许节点上运行的所有 pod 访问EC2ContainerRegistryReadOnly 、IP 地址或从 ECR 中提取映像。 attach/detach ENIs assign/unassign 由于这会给您的集群带来风险，因此建议您更新 aws-node 守护程序集以使用 IRSA。可以在本指南的存储库中找到执行此操作的脚本。

aws-node 守护程序集支持 v1.15.5 及更高版本中的 EKS Pod 身份。

限制访问分配给工作节点的实例配置文件

当你使用 IRSA 或 EKS Pod Identitions 时，它会先更新 Pod 的凭证链以使用 IRSA 或 EKS Pod 身份，但是，Pod 仍然可以继承分配给工作节点的实例配置文件的权限。对于不需要这些权限的 Pod，您可以阻止对实例元数据的访问，以帮助确保您的应用程序仅拥有所需的权限，而不是其节点。

您可以通过要求实例 IMDSv2 仅使用并将跳数更新为 1 来阻止对实例元数据的访问，如下例所示。您也可以将这些设置包含在节点组的启动模板中。请勿禁用实例元数据，因为这将阻止诸如节点终止处理程序之类的组件和其他依赖实例元数据的组件正常运行。

$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1
...

如果您使用 Terraform 创建用于托管节点组的启动模板，请添加元数据块以配置跳数，如以下代码片段所示：

tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" …​ metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …​

你还可以通过操纵节点上的 iptables 来阻止 pod 对 EC2 元数据的访问。有关此方法的更多信息，请参阅限制对实例元数据服务的访问。

如果您的应用程序使用的是不支持 IRSA 或 EKS Pod 身份的旧版 AWS 开发工具包，则应更新软件开发工具包版本。

将 IRSA 角色的 IAM 角色信任策略范围限定为服务账户名称、命名空间和集群

信任策略的范围可以限定为命名空间或命名空间中的特定服务帐号。使用 IRSA 时，最好通过包含服务帐户名称来使角色信任策略尽可能明确。这将有效地防止同一个命名空间中的其他 Pod 担任该角色。当您使用 CLI eksctl 创建服务 accounts/IAM 角色时，它会自动执行此操作。见 https://eksctl。 io/usage/iamserviceaccounts/了解更多信息。

直接使用 IAM 时，这就是在角色的信任策略中添加条件，该策略使用条件来确保:sub声明是您期望的命名空间和服务账号。举个例子，之前我们有一个 IRSA 代币，其子声明为 “system: serviceaccount: default: s3-只读”。这是default命名空间，服务帐号是s3-read-only。你可以使用如下条件来确保只有集群中给定命名空间中的服务账号才能担任该角色：

  "Condition": {
      "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com",
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only"
      }
  }

每个应用程序使用一个 IAM 角色

对于 IRSA 和 EKS Pod Identity，最佳做法是为每个应用程序分配自己的 IAM 角色。这提高了隔离性，因为您可以在不影响另一个应用程序的情况下修改一个应用程序，并且允许您通过仅向应用程序授予所需的权限来应用权限最小的主体。

将 ABAC 与 EKS Pod Identity 配合使用时，您可以在多个服务账户中使用通用 IAM 角色，并依靠其会话属性进行访问控制。这在大规模运营时特别有用，因为 ABAC 允许您使用更少的 IAM 角色进行操作。

当您的应用程序需要访问 IMDS 时，请使用 EC2 实例的跳跃限制 IMDSv2 并将其增加到 2

IMDSv2需要您使用 PUT 请求来获取会话令牌。初始 PUT 请求必须包含会话令牌的 TTL。较新版本的 AWS SDKs 将自动处理此问题以及上述令牌的续订。同样重要的是要注意， EC2 实例的默认跳数限制被故意设置为 1，以防止 IP 转发。因此，请求在 EC2 实例上运行的会话令牌的 Pod 最终可能会超时并回退到使用IMDSv1 数据流。EKS IMDSv2 通过同时启用 v1 和 v2 并将由 eksctl 或官方模板配置的节点上的跳跃限制更改为 2 来增加支持。 CloudFormation

禁用自动挂载服务账号令牌

如果您的应用程序不需要调用 Kubernetes API，请将应用程序的automountServiceAccountToken属性设置为，或者false在每个命名空间中修补默认服务帐户，使其不再自动挂载到 pod 上。 PodSpec例如：

kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'

为每个应用程序使用专用服务帐户

每个应用程序都应有自己的专用服务帐户。这适用于 Kubernetes API 的服务账户以及 IRSA 和 EKS Pod Identity。

以非 root 用户身份运行应用程序

默认情况下，容器以 root 用户身份运行。虽然这允许他们读取 Web 身份令牌文件，但以 root 用户身份运行容器并不是最佳实践。作为替代方案，可以考虑将spec.securityContext.runAsUser属性添加到 PodSpec。的值runAsUser是任意值。

在以下示例中，Pod 中的所有进程都将在runAsUser字段中指定的用户 ID 下运行。

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

当你以非 root 用户身份运行容器时，它会阻止容器读取 IRSA 服务账户令牌，因为默认情况下，该令牌被分配了 0600 [root] 权限。如果你更新容器的 SecurityContext 以包含 fsgroup=65534 [Nobody]，它将允许容器读取令牌。

spec:
  securityContext:
    fsGroup: 65534

在 Kubernetes 1.19 及更高版本中，不再需要进行此更改，应用程序可以读取 IRSA 服务账户令牌，而无需将其添加到 Nobody 组中。

授予对应用程序的最低特权访问权限

Acti@@ on Hero 是一个实用工具，您可以与应用程序一起运行，以识别应用程序正常运行所需的 AWS API 调用和相应的 IAM 权限。它与 IAM Access Advisor 类似，因为它可以帮助您逐步限制分配给应用程序的 IAM 角色的范围。有关更多信息，请参阅有关授予对 AWS 资源的最低权限访问权限的文档。

考虑为与 IRSA 和 Pod 身份一起使用的 IAM 角色设置权限边界。您可以使用权限边界来确保 IRSA 或 Pod Identities 使用的角色不能超过最大权限级别。有关权限边界入门的示例指南以及权限边界策略示例，请参阅此 github 存储库。

查看并撤消对您的 EKS 集群的不必要的匿名访问权限

理想情况下，应禁用所有 API 操作的匿名访问权限。匿名访问权限是通过为 Kubernetes 内置用户ClusterRoleBinding 系统创建 RoleBinding 或来授予的：匿名。你可以使用 rbac-lookup 工具来识别 system: anonymous 用户对你的集群拥有的权限：

./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)'
system:anonymous               cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:public-info-viewer

public-info-viewer 不应将任何角色或 system: 以 ClusterRole 外的角色绑定到 system: anonymous 用户或 system: 未经身份验证的群组。

可能有一些正当理由在特定情况下启用匿名访问 APIs。如果您的集群是这种情况，请确保匿名用户只能访问特定的 APIs 群集，而公开APIs 未经身份验证的群集不会使您的集群容易受到攻击。

在 Kubernetes/EKS 版本 1.14 之前，默认情况下，system: 未经身份验证的组与 system: discovery 和 system: basic-user 相关联。 ClusterRoles 请注意，即使您已将集群更新到 1.14 或更高版本，这些权限仍可能在您的集群上启用，因为集群更新不会撤消这些权限。要检查除了 system: 之外哪些ClusterRoles 有 “system: unautificated”，public-info-viewer 你可以运行以下命令（需要 jq util）：

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'

而且，可以使用：从除 “system:” 之外的所有角色中删除 “system: unauthentified”：public-info-viewer

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -

或者，你可以通过 kubectl describe 和 kubectl edit 手动检查和删除它。要检查 system: 未经身份验证的组是否在您的集群上拥有 system: discovery 权限，请运行以下命令：

kubectl describe clusterrolebindings system:discovery

Name:         system:discovery
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:discovery
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

要检查 system: 未经身份验证的组在您的集群上是否拥有 system: basic-user 权限，请运行以下命令：

kubectl describe clusterrolebindings system:basic-user

Name:         system:basic-user
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:basic-user
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

如果 system: 未经身份验证的组绑定到集群 ClusterRoles 上的 system: discovery 和/或 system: basic-user，则应取消这些角色与 system: 未经身份验证的组的关联。ClusterRoleBinding 使用以下命令编辑 system: discovery：

kubectl edit clusterrolebindings system:discovery

上面的命令将在编辑器中打开 system: discovery ClusterRoleBinding 的当前定义，如下所示：

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2021-06-17T20:50:49Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "24502985"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
  uid: b7936268-5043-431a-a0e1-171a423abeb6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

从上述编辑器屏幕的 “主题” 部分中删除 system: 未认证群组的条目。

对 system: ClusterRoleBinding basic-user 重复相同的步骤。

在 IRSA 中重复使用 AWS 开发工具包会话

当您使用 IRSA 时，使用 AWS 开发工具包编写的应用程序会使用传送到您的 pod 的令牌sts:AssumeRoleWithWebIdentity来调用生成临时 AWS 证书。这与其他 AWS 计算服务不同，在这些服务中，计算服务直接向 AWS 计算资源（例如 lambda 函数）提供临时 AWS 证书。这意味着，每次初始化 AWS 开发工具包会话时，都会调用 AWS STS f AssumeRoleWithWebIdentity or。如果您的应用程序快速扩展并初始化了许多 AWS SDK 会话，则可能会遇到来自 AWS STS 的限制，因为您的代码会发出很多调用。AssumeRoleWithWebIdentity

为避免出现这种情况，我们建议您在应用程序中重复使用 AWS 开发工具包会话，这样就不会对进行AssumeRoleWithWebIdentity不必要的调用。

在以下示例代码中，使用 boto3 python SDK 创建了一个会话，该会话用于创建客户端并与 Amazon S3 和 Amazon SQS 进行交互。 AssumeRoleWithWebIdentity仅调用一次，AWS 开发工具包将自动刷新证书到期my_session时的证书。

import boto3

= Create your own session

my_session = boto3.session.Session()

= Now we can create low-level clients from our session

sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`')

s3response = s3.list_buckets() sqsresponse = sqs.list_queues()

#print the response from the S3 and SQS APIs print("`s3 response:`")
print(s3response) print("`—`") print("`sqs response:`")
print(sqsresponse) ```

如果您要使用 IRSA 将应用程序从其他 AWS 计算服务（例如 EC2）迁移到 EKS，则这是一个特别重要的细节。在其他计算服务上，除非您指示，否则初始化 AWS 开发工具包会话不会调用 AWS STS。

替代方法

虽然 IRSA 和 EKS Pod 身份是向容器分配 AWS 身份的首选方式，但它们要求您在应用程序 SDKs 中包含最新版本的 AWS。有关当前支持 IRSA 的完整列表 SDKs，请参阅 https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html，有关 EKS Pod Identities，请参阅 https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk .html。如果您的应用程序无法使用兼容的 SDK 立即更新，那么有几种社区构建的解决方案可用于向 Kubernetes pod 分配 IAM 角色，包括 kube2iam 和 kiam。尽管 AWS 不认可、宽恕也不支持这些解决方案的使用，但整个社区经常使用它们来实现与 IRSA 和 EKS Pod Identities 相似的结果。

如果您需要使用这些非 AWS 提供的解决方案，请进行尽职调查，并确保您了解这样做带来的安全影响。

工具和资源