AWS IAM Authenticator for Kubernetes

一种使用 AWS IAM 凭据对 Kubernetes 集群进行身份验证的工具。该工具的初始工作由 Heptio 推动。项目接收来自多位社区工程师的贡献，目前由 Heptio 和 Amazon EKS OSS 工程师维护。

我为什么需要它？

如果你是运行在 AWS 上的 Kubernetes 集群的管理员，你本来就需要管理 AWS IAM 凭据来配置和更新集群。通过使用 AWS IAM Authenticator for Kubernetes，你可以避免为 Kubernetes 访问单独管理一套凭据。 AWS IAM 还提供了许多不错的特性，例如带外审计跟踪（通过 CloudTrail）以及 2FA/MFA 强制。

如果你正在 AWS 上构建 Kubernetes 安装程序，AWS IAM Authenticator for Kubernetes 可以简化你的引导过程。你无需费心将初始管理员凭据从新安装的集群中安全地带出来。相反，你可以在集群配置阶段创建一个专用的 KubernetesAdmin 角色，并设置 Authenticator 以允许集群管理员登录。

我该如何使用？

假设你有一个在 AWS 上运行的集群，并且想为其添加 AWS IAM Authenticator for Kubernetes 支持，你需要：

创建一个用于识别用户的 IAM 角色。
将 Authenticator 服务器作为 DaemonSet 运行。
配置你的 API server 与 Authenticator 通信。
设置 kubectl 使用 Authenticator 令牌。

1. 创建一个 IAM 角色

首先，你必须创建一个或多个 IAM 角色，这些角色将映射到 Kubernetes 集群内的用户/组。最简单的方法是登录 AWS 控制台：

选择“用于跨账户访问的角色”/“在你拥有的 AWS 账户之间提供访问”选项。
粘贴你的 AWS 账户 ID 号（可在控制台右上角找到）。
你的角色不需要附加任何额外策略。

这将创建一个没有任何权限的 IAM 角色，该角色可由你账户中的授权用户/角色代入。记下你的角色的 Amazon Resource Name (ARN)，下面你会用到它。

你也可以使用 AWS CLI 而非 AWS 控制台一步完成此操作：```sh

get your account ID

ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

define a role trust policy that opens the role to users in your account (limited by IAM policy)

POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')

create a role named KubernetesAdmin (will print the new role's ARN)

aws iam create-role
--role-name KubernetesAdmin
--description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)."
--assume-role-policy-document "$POLICY"
--output text
--query 'Role.Arn'

你也可以跳过此步骤，直接使用：
 - 现有角色（例如跨账户访问角色）。
 - IAM 用户（参见下面的 `mapUsers`）。
 - EC2 实例或联合角色（参见下面的 `mapRoles`）。

### 2. 运行服务器
该服务器旨在以 DaemonSet 的形式在您的每个主节点上运行，并使用主机网络，以便它可以暴露一个 localhost 端口。

有关示例 ConfigMap 和 DaemonSet 配置，请参阅 [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml)。
在应用之前，请为您的集群更新以下值：
 - 替换 `config.yaml` 中的占位 IAM ARN（`arn:aws:iam::000000000000:...`）。
 - 将 `clusterID` 设置为您的集群的唯一值。
 - 验证 DaemonSet 的调度规则是否与您的控制平面节点标签/污点匹配。

然后部署它：```sh
kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator

一旦 Pod 在控制平面节点上运行，aws-iam-authenticator server 将在宿主机上创建 webhook kubeconfig，路径为 /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml（或通过 --generate-kubeconfig 配置的路径）。

（可选）预生成证书、密钥和 kubeconfig

如果你正在构建自动化安装程序，还可以使用 aws-iam-authenticator init 轻松预生成证书、密钥和 webhook kubeconfig 文件。该命令将生成文件并将其放置到配置的输出目录中。

你可以在每个主节点上启动 API 服务器之前运行此命令。你也可以在配置主节点之前生成这些文件，并将它们安装到相应的宿主机路径中。

如果未预生成文件，aws-iam-authenticator server 将按需生成它们。这也可以工作，但需要在安装后重启你的 Kubernetes API 服务器。

3. 配置你的 API 服务器与服务器通信

Kubernetes API 通过令牌认证 webhook 与 AWS IAM Authenticator for Kubernetes 集成。当你运行 aws-iam-authenticator server 时，它将生成一个 webhook 配置文件并保存到宿主机文件系统。你需要在 API 服务器配置中添加一个额外的标志：``` --authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml

在许多集群中，API 服务器以静态 Pod 形式运行。
你可以将该标志添加到 `/etc/kubernetes/manifests/kube-apiserver.yaml`。
确保宿主机目录 `/etc/kubernetes/aws-iam-authenticator/` 已挂载到你的 API 服务器 Pod 中。
你可能还需要重启主节点上的 kubelet 守护进程，以加载更新后的静态 Pod 定义：```
systemctl restart kubelet.service

4. 创建 IAM 角色/用户到 Kubernetes 用户/组的映射

服务器的默认行为是仅从其配置文件的 mapUsers 和 mapRoles 字段获取映射。详见下文完整配置格式。

使用 --backend-mode 标志，你可以将服务器配置为从另外两个后端获取映射：EKS 风格的 ConfigMap（--backend-mode=EKSConfigMap）或 IAMIdentityMapping 自定义资源（--backend-mode=CRD）。默认后端是由服务器 Pod 挂载的服务器配置文件，对应 --backend-mode=MountedFile。

你可以传递这些后端的逗号分隔列表，让服务器按顺序搜索。例如，使用 --backend-mode=EKSConfigMap,MountedFile 时，服务器会先在 EKS 风格的 ConfigMap 中查找映射，如果找不到给定 IAM 角色/用户的映射，再查找服务器配置文件。如果同一 IAM 角色/用户的映射存在于多个后端，服务器将使用逗号分隔列表中靠前出现的后端的映射。在此示例中，如果在 EKS ConfigMap 中找到映射，那么无论服务器配置文件中是否存在重复或冲突的映射，都将使用该映射。

请注意，当设置单个后端时，服务器将仅从该后端获取映射，即使其他后端存在也会忽略。例如，使用 --backend-mode=CRD 时，服务器将仅从 IAMIdentityMappings 获取映射，并忽略挂载的文件和 EKS ConfigMap。

`MountedFile`

这是映射的默认后端，对大多数用户来说已经足够。详见下文完整配置格式。

`CRD` (alpha)

该后端将每个 IAM 映射建模为一个 IAMIdentityMapping Kubernetes 自定义资源。这种方法使你能够以 Kubernetes 原生的方式通过 kubectl 或 API 维护映射。此外，语法错误（如 YAML 缩进错位）更容易被发现，并且不会影响所有映射。

要设置 IAMIdentityMapping CRD，你首先需要 apply CRD 清单：``` kubectl apply -f deploy/iamidentitymapping.yaml

部署 CRD 后，你就可以创建对你的 IAM 身份进行建模的自定义资源，
请参阅
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example-iamidentitymapping.yaml):```
---
apiVersion: iamauthenticator.k8s.aws/v1alpha1
kind: IAMIdentityMapping
metadata:
  name: kubernetes-admin
spec:
  # Arn of the User or Role to be allowed to authenticate
  arn: arn:aws:iam::XXXXXXXXXXXX:user/KubernetesAdmin
  # Username that Kubernetes will see the user as, this is useful for setting
  # up allowed specific permissions for different users
  username: kubernetes-admin
  # Groups to be attached to your users/roles. For example `system:masters` to
  # create cluster admin, or `system:nodes`, `system:bootstrappers` for nodes to
  # access the API server.
  groups:
  - system:masters

`EKSConfigMap`

EKS 风格的 kube-system/aws-auth ConfigMap 作为后端。该 ConfigMap 的格式需与 EKS 集群中的完全一致： https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html。如果你正在从 EKS 迁移或迁移到 EKS，并希望保留这些映射，或者除了其他 AWS 集群之外还运行 EKS，并希望在每个集群中拥有相同的映射，那么这会很有用。

`DynamicFile`

由 cfg.dynamicfilepath 指定的本地文件可以作为后端。文件内容需与 EKSConfigMap 的格式完全一致。每当此文件内容发生变化时，authenticator 会自动重新加载它。这为管理 ARN 映射提供了更大的灵活性。

请参阅 https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml 了解如何配置 DynamicFile 模式。

运行 make e2e RUNNER=kind 可在启用 DynamicFile 模式的 kind 集群上进行体验。

5. 如何为 Kubernetes 用户名配置 reservedPrefixConfig

aws-iam-authenticator 支持为 k8s 用户名设置保留前缀。如果设置了保留前缀，则带有该保留前缀的用户名将无法通过认证，并报错： "username must not begin with with the following prefixes:"。

请参阅 https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml 了解如何配置保留前缀。

6. 配置 kubectl 使用 AWS IAM Authenticator for Kubernetes 提供的认证令牌

最后，服务器设置完成后，你需要进行认证。你仍然需要一个 kubeconfig，其中包含集群的公开数据（集群 CA 证书、端点地址）。但是，你的配置中的 users 部分应包含一个 exec 部分（请参阅 kubectl 凭据插件文档）：```yaml

[...]

users:

name: kubernetes-admin user: exec: apiVersion: client.authentication.k8s.io/v1beta1 command: aws-iam-authenticator args: - "token" - "-i" - "REPLACE_ME_WITH_YOUR_CLUSTER_ID" - "-r" - "REPLACE_ME_WITH_YOUR_ROLE_ARN"
no client certificate/key needed here!

这意味着 `kubeconfig` 完全是公开数据，可以在所有 Authenticator 用户之间共享。
将其上传到可信的公共位置（如 AWS S3）或许是合理的。

请确保你已安装 `aws-iam-authenticator` 二进制文件。
你可以使用 `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest` 安装它。

要进行身份验证，请运行 `kubectl --kubeconfig /path/to/kubeconfig" [...]`。
kubectl 将使用你的 kubeconfig 中提供的参数 `exec` `aws-iam-authenticator` 二进制文件，该二进制文件将生成一个令牌并将其传递给 apiserver。
该令牌有效期为 15 分钟（AWS 允许的最短时间），可以多次重用。

aws-iam-authenticator v0.7.19

AWS IAM Authenticator for Kubernetes

目录

我为什么需要它？

我该如何使用？

1. 创建一个 IAM 角色

get your account ID

define a role trust policy that opens the role to users in your account (limited by IAM policy)

create a role named KubernetesAdmin (will print the new role's ARN)

（可选）预生成证书、密钥和 kubeconfig

3. 配置你的 API 服务器与服务器通信

4. 创建 IAM 角色/用户到 Kubernetes 用户/组的映射

`MountedFile`

`CRD` (alpha)

`EKSConfigMap`

`DynamicFile`

5. 如何为 Kubernetes 用户名配置 reservedPrefixConfig

6. 配置 kubectl 使用 AWS IAM Authenticator for Kubernetes 提供的认证令牌

[...]

no client certificate/key needed here!

分类

aws-iam-authenticator v0.7.19

AWS IAM Authenticator for Kubernetes

目录

我为什么需要它？

我该如何使用？

1. 创建一个 IAM 角色

get your account ID

define a role trust policy that opens the role to users in your account (limited by IAM policy)

create a role named KubernetesAdmin (will print the new role's ARN)

（可选）预生成证书、密钥和 kubeconfig

3. 配置你的 API 服务器与服务器通信

4. 创建 IAM 角色/用户到 Kubernetes 用户/组的映射

MountedFile

CRD (alpha)

EKSConfigMap

DynamicFile

5. 如何为 Kubernetes 用户名配置 reservedPrefixConfig

6. 配置 kubectl 使用 AWS IAM Authenticator for Kubernetes 提供的认证令牌

[...]

no client certificate/key needed here!

分类

`MountedFile`

`CRD` (alpha)

`EKSConfigMap`

`DynamicFile`