aws-iam-authenticator

# 适用于 Kubernetes 的 AWS IAM 认证器

一个使用 AWS IAM 凭证向 Kubernetes 集群进行身份认证的工具。
该工具的初始工作由 Heptio 推动。该项目获得了众多社区工程师的贡献，目前由 Heptio 和 Amazon EKS OSS 工程师维护。

## 目录

- [我为什么需要它？](#why-do-i-want-this)
- [我如何使用它？](#how-do-i-use-it)
- [Kops 用法](#kops-usage)
- [它是如何工作的？](#how-does-it-work)
- [什么是集群 ID？](#what-is-a-cluster-id)
- [指定凭证与使用 AWS 配置文件](#specifying-credentials--using-aws-profiles)
- [从集群外部进行 API 授权](#api-authorization-from-outside-a-cluster)
- [故障排查](#troubleshooting)
- [完整配置格式](#full-configuration-format)
- [开发](#development)
- [社区、讨论、贡献与支持](#community-discussion-contribution-and-support)

## 我为什么需要它？
如果你是在 AWS 上运行 Kubernetes 集群的管理员，你本来就需要管理 AWS IAM 凭证来配置和更新集群。
通过使用适用于 Kubernetes 的 AWS IAM 认证器，你可以避免为 Kubernetes 访问单独管理一套凭证。
AWS IAM 还提供了许多出色的特性，例如带外审计跟踪（通过 CloudTrail）以及 2FA/MFA 强制实施。

如果你正在 AWS 上构建 Kubernetes 安装程序，适用于 Kubernetes 的 AWS IAM 认证器可以简化你的引导过程。
你无需设法将初始管理员凭证安全地从新安装的集群中偷运出来。
相反，你可以在集群配置时创建一个专用的 `KubernetesAdmin` 角色，并设置认证器以允许集群管理员登录。

## 我如何使用它？
假设你有一个在 AWS 中运行的集群，并且想要添加适用于 Kubernetes 的 AWS IAM 认证器支持，你需要：
 1. 创建一个用于识别用户的 IAM 角色。
 2. 以 DaemonSet 方式运行认证器服务器。
 3. 配置你的 API 服务器与认证器通信。
 4. 设置 kubectl 以使用认证器令牌。

### 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` 将在主机上的 `/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml`（或通过 `--generate-kubeconfig` 配置的路径）创建 webhook kubeconfig。

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

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

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

### 3. 配置你的 API 服务器以与服务器通信
Kubernetes API 通过 [token authentication webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 与 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` 字段获取映射。详情请参阅下方的[完整配置格式](#full-configuration-format)。

使用 `--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`
这是默认的映射后端，对大多数用户来说已经足够。详情请参阅下方的[完整配置格式](#full-configuration-format)。

#### `CRD`（alpha）
此后端将每个 IAM 映射建模为一个 `IAMIdentityMapping` [Kubernetes 自定义资源](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。这种方法使你能够使用 kubectl 或 API 以 Kubernetes 原生方式维护映射。此外，语法错误（如 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 并希望保留映射，或者你在运行 EKS 的同时还运行其他 AWS 集群并希望在每个集群中使用相同的映射，这会很有用。

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

关于如何配置 DynamicFile 模式，请查看 https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml。

运行 `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 提供的身份验证令牌

最后，服务器设置完成后，你需要进行身份验证。
你仍然需要一个包含集群公共数据（集群 CA 证书、端点地址）的 `kubeconfig`。
不过，配置中的 `users` 部分应包含一个 exec 部分（[参阅 kubectl 凭据插件文档](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)）：
```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 允许的最短值），并且可以多次重复使用。

你还可以在生成令牌时通过包含 `--session-name 或 -s` 参数来指定会话名称。此参数不能与 `--forward-session-name` 一起使用。

你也可以省略 `-r ROLE_ARN`，使用你现有的凭证对令牌进行签名，而无需代入专用角色。
如果你希望直接以 IAM 用户身份进行身份验证，或者希望使用 EC2 实例角色或联合角色进行身份验证，这会很有用。

## Kops 用法
由 [Kops](https://github.com/kubernetes/kops) 管理的集群可以配置为使用 Authenticator。有关用法说明，请参阅 [Kops 文档](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator)。

## 工作原理
它使用 AWS [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html) API 端点工作。
该端点会返回你用于连接它的任何 AWS IAM 凭证的相关信息。

#### 客户端（`aws-iam-authenticator token`）
我们以一种略显不寻常的方式使用此 API：让 Authenticator 客户端生成并预先签名一个对该端点的请求。
我们将该请求序列化为一个令牌，该令牌可以通过 Kubernetes 身份验证系统。

#### 服务端（`aws-iam-authenticator server`）
该令牌通过 Kubernetes API 服务器传递，并通过 webhook 配置进入 Authenticator 服务器的 `/authenticate` 端点。
Authenticator 服务器会验证预签名请求的所有参数，以确保没有任何异常。
然后它会将该请求提交给真实的 `https://sts.amazonaws.com` 服务器，该服务器会验证客户端的 HMAC 签名并返回用户信息。
现在服务器知道了客户端的 AWS 身份，它会通过简单的静态映射将该身份转换为 Kubernetes 用户和组。

此机制借鉴自 [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method)，并做了一些改动。

## 什么是集群 ID？
Authenticator 集群 ID 是一个每个集群唯一的标识符，用于防止某些重放攻击。
具体来说，它可以防止一个 Authenticator 服务器（例如开发环境中的服务器）使用客户端的令牌向另一个集群中的另一个 Authenticator 服务器进行身份验证。

集群 ID 确实需要每个集群唯一，但不需要保密。
一些好的选择包括：
 - 随机 ID，例如通过 `openssl rand 16 -hex` 生成
 - 你的 Kubernetes API 服务器的域名

[Vault 文档](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method)也解释了这种攻击（参见 `X-Vault-AWS-IAM-Server-ID`）。

## 指定凭证与使用 AWS 配置文件
可以通过 [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) 可用的任何方法为 `aws-iam-authenticator` 指定凭证。
这包括使用环境变量指定 AWS 凭证，或使用凭证文件。

`aws-iam-authenticator` 通过 `AWS_PROFILE` 环境变量支持 AWS [命名配置文件](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html)。例如，要使用 _dev_ 配置文件中指定的凭证进行身份验证，可以导出 `AWS_PROFILE` 或显式指定它（例如 `AWS_PROFILE=dev kubectl get all`）。如果未设置 `AWS_PROFILE`，则使用 _default_ 配置文件。

`AWS_PROFILE` 也可以直接在 kubeconfig 文件中[作为 `exec` 流程的一部分](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration)指定。例如，要指定 `aws-iam-authenticator` 始终使用 _dev_ 命名配置文件中的凭证，你的 kubeconfig 需要包含一个设置该配置文件的 `env` 键：

```yaml
apiVersion: v1
clusters:
- cluster:
    server: ${server}
    certificate-authority-data: ${cert}
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws-iam-authenticator
      env:
      - name: "AWS_PROFILE"
        value: "dev"
      args:
        - "token"
        - "-i"
        - "mycluster"
```

此方法允许隐式使用适当的配置文件。请注意，作为 `exec` 流程一部分设置的任何环境变量将优先于您环境中已设置的内容。

#### 联邦用户注意事项：
联邦 AWS 用户通常通过账户的 AWS 配置，将“有意义的”属性（例如电子邮件地址）映射到其代入的角色上。
这些代入的会话包含[几个部分](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable)，即 `role id`
和 `caller-specified-role-name`。默认情况下，当联邦用户使用 `aws-iam-authenticator` 的 `--role` 选项代入新角色时，
`caller-specified-role-name` 将被转换为随机令牌，而 `role id` 会延续到新代入的角色中。

使用 `aws-iam-authenticator token ... --forward-session-name` 会将原始的 `caller-specified-role-name` 属性映射到新的 STS 代入会话上。
这有助于快速尝试关联“是谁在 K8 集群上执行了操作 X”。

请注意，**这不应被视为确定性的依据**，需要通过 `role id`（其保持一致）与 CloudTrail 日志进行交叉引用，
因为用户有可能在客户端侧更改此值。

## 从集群外部进行 API 授权

可以从集群外部的客户端向 Kubernetes API 发起请求，无论是使用
裸 Kubernetes REST API 还是使用某种特定语言的 Kubernetes 客户端
（例如 [Python](https://github.com/kubernetes-client/python)）。为此，您必须创建一个随 API 请求一起发送的
bearer token。此 bearer token 需要您将字符串 `k8s-aws-v1.` 与
对 STS GetCallerIdentity Query API 的签名 HTTP 请求的 base64 编码字符串拼接在一起。然后将其放入请求的
`Authorization` 头中发送。不过需要注意的是，IAM Authenticator 显式省略了
base64 填充以避免出现任何 `=` 字符，从而保证该字符串可安全用于 URL。以下是一个
Python 示例，展示如何构造此令牌：

```python
import base64
import boto3
import re
from botocore.signers import RequestSigner

def get_bearer_token(cluster_id, region):
    STS_TOKEN_EXPIRES_IN = 60
    session = boto3.session.Session()

    client = session.client('sts', region_name=region)
    service_id = client.meta.service_model.service_id

    signer = RequestSigner(
        service_id,
        region,
        'sts',
        'v4',
        session.get_credentials(),
        session.events
    )

    params = {
        'method': 'GET',
        'url': 'https://sts.{}.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15'.format(region),
        'body': {},
        'headers': {
            'x-k8s-aws-id': cluster_id
        },
        'context': {}
    }

    signed_url = signer.generate_presigned_url(
        params,
        region_name=region,
        expires_in=STS_TOKEN_EXPIRES_IN,
        operation_name=''
    )

    base64_url = base64.urlsafe_b64encode(signed_url.encode('utf-8')).decode('utf-8')

    # remove any base64 encoding padding:
    return 'k8s-aws-v1.' + re.sub(r'=*', '', base64_url)

# If making a HTTP request you would create the authorization headers as follows:

headers = {'Authorization': 'Bearer ' + get_bearer_token('my_cluster', 'us-east-1')}

```


## 故障排查

如果你的客户端失败并报错 `could not get token: AccessDenied [...]`，你可以尝试直接使用 AWS CLI 来代入该角色：

```sh
# AWS CLI version of `aws-iam-authenticator token -r arn:aws:iam::ACCOUNT:role/ROLE`:
$ aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/ROLE --role-session-name test
```

如果仍然失败，有几个可能的问题需要检查：

 - 确保你的基础 AWS 凭证在 shell 中可用（`aws sts get-caller-identity` 可以帮助排查此问题）。

 - 确保目标角色允许你的源账户访问（在角色信任策略中）。

 - 确保你的源主体（用户/角色/组）具有允许对目标角色执行 `sts:AssumeRole` 的 IAM 策略。

 - 确保你的用户、组或 AWS Organizations 中没有附加任何会阻止 `sts:AssumeRole` 的显式拒绝策略。

 - 尝试在 [Policy Simulator](https://policysim.aws.amazon.com/home/index.jsp) 中模拟 `sts:AssumeRole` 调用。

## 完整配置格式
客户端和服务器具有相同的配置格式。
它们可以共享完全相同的配置文件，因为配置中不存储任何机密信息。

```yaml
# a unique-per-cluster identifier to prevent replay attacks (see above)
clusterID: my-dev-cluster.example.com

# default IAM role to assume for `aws-iam-authenticator token`
defaultRole: arn:aws:iam::000000000000:role/KubernetesAdmin

# server listener configuration
server:
  # localhost port where the server will serve the /authenticate endpoint
  port: 21362 # (default)

  # state directory for generated TLS certificate and private keys
  stateDir: /var/aws-iam-authenticator # (default)

  # output `path` where a generated webhook kubeconfig will be stored.
  generateKubeconfig: /etc/kubernetes/aws-iam-authenticator.kubeconfig # (default)

  # role to assume before querying EC2 API in order to discover metadata like EC2 private DNS Name
  ec2DescribeInstancesRoleARN: arn:aws:iam::000000000000:role/DescribeInstancesRole

  # AWS region for EC2 DescribeInstances and token verification. If unset, the region is looked
  # up from the EC2 Instance Metadata Service (IMDS) at startup. Also settable with `--region`.
  region: us-west-2

  # AWS Account IDs to scrub from server logs. (Defaults to empty list)
  scrubbedAccounts:
  - "111122223333"
  - "222233334444"

  # each mapRoles entry maps an IAM role to a username and set of groups
  # Each username and group can optionally contain template parameters:
  #  1) "{{AccountID}}" is the 12 digit AWS ID.
  #  2) "{{SessionName}}" is the role session name, with `@` characters
  #     transliterated to `-` characters.
  #  3) "{{SessionNameRaw}}" is the role session name, without character
  #     transliteration (available in version >= 0.5).
  mapRoles:
  # statically map arn:aws:iam::000000000000:role/KubernetesAdmin to cluster admin
  - rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin
    username: kubernetes-admin
    groups:
    - system:masters

  # map EC2 instances in my "KubernetesNode" role to users like
  # "aws:000000000000:instance:i-0123456789abcdef0". Only use this if you
  # trust that the role can only be assumed by EC2 instances. If an IAM user
  # can assume this role directly (with sts:AssumeRole) they can control
  # SessionName.
  - rolearn: arn:aws:iam::000000000000:role/KubernetesNode
    username: aws:{{AccountID}}:instance:{{SessionName}}
    groups:
    - system:bootstrappers
    - aws:instances

  # map nodes that should conform to the username "system:node:<private-DNS>".  This
  # requires the authenticator to query the EC2 API in order to discover the private
  # DNS of the EC2 instance originating the authentication request.
  # {{EC2PrivateDNSName}} is resolved by using the session name as an EC2 instance
  # ID and calling ec2:DescribeInstances. Note that if this role is assumed directly
  # by an IAM User (not via federation), the user can set the session name to any
  # instance ID, resolving another instance's private DNS and impersonating that node.
  # Optionally, you may specify a role that should be assumed before querying the EC2 API with the
  # key "server.ec2DescribeInstancesRoleARN" (see above).
  - rolearn: arn:aws:iam::000000000000:role/KubernetesNode
    username: system:node:{{EC2PrivateDNSName}}
    groups:
    - system:nodes
    - system:bootstrappers

  # map federated users in my "KubernetesAdmin" role to users like
  # "admin:alice-example.com". The SessionName is an arbitrary role name
  # like an e-mail address passed by the identity provider. Note that if this
  # role is assumed directly by an IAM User (not via federation), the user
  # can control the SessionName.
  - rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin
    username: admin:{{SessionName}}
    groups:
    - system:masters

  # map federated users in my "KubernetesOtherAdmin" role to users like
  # "alice-example.com". The SessionName is an arbitrary role name
  # like an e-mail address passed by the identity provider. Note that if this
  # role is assumed directly by an IAM User (not via federation), the user
  # can control the SessionName.  Note that the "{{SessionName}}" macro is
  # quoted to ensure it is properly parsed as a string.
  - rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin
    username: "{{SessionName}}"
    groups:
    - system:masters

  # If unalterable identification of an IAM User is desirable, you can map against
  # AccessKeyID.
  - rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin
    username: "admin:{{AccessKeyID}}"
    groups:
    - system:masters

  # each mapUsers entry maps an IAM user to a static username and set of groups
  mapUsers:
  # map user IAM user Alice in 000000000000 to user "alice" in group "system:masters"
  - userarn: arn:aws:iam::000000000000:user/Alice
    username: alice
    groups:
    - system:masters

  # automatically map IAM ARN from these accounts to username.
  # NOTE: Always use quotes to avoid the account numbers being recognized as numbers
  # instead of strings by the yaml parser.
  mapAccounts:
  - "012345678901"
  - "456789012345"

  # source mappings from this file (mapUsers, mapRoles, & mapAccounts)
  backendMode:
  - MountedFile
```

## 开发

请参阅[开发](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/docs/development.md)页面。


## 社区、讨论、贡献与支持

在[社区页面](http://kubernetes.io/community/)了解如何参与 Kubernetes 社区。

您可以通过以下方式联系本项目的维护者：

- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)

### 行为准则

参与 Kubernetes 社区须遵守 [Kubernetes 行为准则](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/code-of-conduct.md)。