kubernetes-sigs/aws-iam-authenticatorAWS IAM 認証情報を使用して Kubernetes クラスターに認証するためのツール
# Kubernetes 用 AWS IAM Authenticator
AWS IAM 認証情報を使用して Kubernetes クラスターへ認証するためのツールです。
このツールの初期開発は Heptio によって主導されました。本プロジェクトは複数のコミュニティエンジニアからの貢献を受けており、現在は Heptio と Amazon EKS OSS Engineers によってメンテナンスされています。
## 目次
- [なぜこれが必要なのか?](#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 Authenticator を使用することで、Kubernetes アクセスのために別途認証情報を管理する必要がなくなります。
AWS IAM はさらに、帯域外の監査証跡 (CloudTrail 経由) や 2FA/MFA の強制など、数多くの優れた特性を提供します。
AWS 上で Kubernetes インストーラーを構築している場合、Kubernetes 用 AWS IAM Authenticator はブートストラッププロセスを簡素化できます。
新しくインストールしたクラスターから初期管理者認証情報を何とかして安全に持ち出す必要がなくなります。
代わりに、クラスターのプロビジョニング時に専用の `KubernetesAdmin` ロールを作成し、クラスター管理者のログインを許可するように Authenticator を設定できます。
## どのように使うのか?
AWS 上でクラスターが稼働しており、Kubernetes 用 AWS IAM Authenticator のサポートを追加したいと仮定すると、次のことを行う必要があります:
1. ユーザーの識別に使用する IAM ロールを作成します。
2. Authenticator サーバーを DaemonSet として実行します。
3. API サーバーが Authenticator と通信するように設定します。
4. kubectl が Authenticator トークンを使用するように設定します。
### 1. IAM ロールの作成
まず、Kubernetes クラスター内のユーザー/グループにマッピングされる 1 つ以上の IAM ロールを作成する必要があります。
最も簡単な方法は、AWS コンソールにログインすることです:
- 「Role for cross-account access」/「Provide access between AWS accounts you own」オプションを選択します。
- AWS アカウント ID 番号 (コンソールの右上に表示されます) を貼り付けます。
- ロールには追加のポリシーをアタッチする必要はありません。
これにより、アカウント内の認可されたユーザー/ロールが引き受け可能な、権限のない IAM ロールが作成されます。
以下で必要となるため、ロールの Amazon Resource Name (ARN) を控えておいてください。
AWS コンソールの代わりに AWS CLI を使用して、これを 1 ステップで行うこともできます:
```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は、[トークン認証Webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を使用してAWS IAM Authenticator for Kubernetesと統合されます。
`aws-iam-authenticator server` を実行すると、Webhook設定ファイルが生成され、ホストのファイルシステムに保存されます。
APIサーバーの設定に、フラグを1つ追加する必要があります:
```
--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にマウントされていることを確認してください。
また、更新された静的Pod定義を反映するために、マスターノード上でkubeletデーモンを再起動する必要がある場合もあります:
```
systemctl restart kubelet.service
```
### 4. kubernetes ユーザー/グループへの IAM ロール/ユーザーマッピングの作成
サーバーのデフォルトの動作は、設定ファイルの `mapUsers` および `mapRoles` フィールドのみからマッピングを取得することです。詳細は以下の[完全な設定フォーマット](#full-configuration-format)を参照してください。
`--backend-mode` フラグを使用すると、サーバーが追加の 2 つのバックエンドからマッピングを取得するように設定できます。EKS スタイルの ConfigMap (`--backend-mode=EKSConfigMap`) または `IAMIdentityMapping` カスタムリソース (`--backend-mode=CRD`) です。デフォルトのバックエンドである、サーバーポッドによってマウントされるサーバー設定ファイルは、`--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 をセットアップするには、まず CRD マニフェストを `apply` する必要があります:
```
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 との間で移行する際にマッピングを維持したい場合や、他の AWS クラスタに加えて
EKS を運用していて各クラスタで同じマッピングを持ちたい場合に便利です。
#### `DynamicFile`
cfg.dynamicfilepath で指定されたローカルファイルをバックエンドとして機能させることができます。ファイルの
内容は EKSConfigMap とまったく同じ形式であることが想定されています。このファイルの内容が
変更されるたびに、authenticator は自動的にそれを再読み込みします。これにより
ARN マッピングの管理がより柔軟になります。
DynamicFile モードの設定方法については
https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
を確認してください。
DynamicFile モードを有効にした kind クラスタで試すには `make e2e RUNNER=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. AWS IAM Authenticator for Kubernetes が提供する認証トークンを使用するように kubectl を設定する
最後に、サーバーのセットアップが完了したら認証を行う必要があります。
クラスタに関する公開情報（クラスタ 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 で指定されたパラメータを使用して `aws-iam-authenticator` バイナリを `exec` し、トークンを生成して 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`)
Authenticator クライアントがエンドポイントへのリクエストを生成して事前署名することで、この API をやや特殊な方法で使用します。
そのリクエストをトークンにシリアライズし、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 はクラスタごとに一意である必要がありますが、秘密である必要はありません。
適切な選択肢としては、次のようなものがあります：
- `openssl rand 16 -hex` などで生成したランダム ID
- 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 の[名前付きプロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html)は、`AWS_PROFILE` 環境変数を介して `aws-iam-authenticator` でサポートされています。たとえば、_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)直接指定することもできます。たとえば、_dev_ 名前付きプロファイルの認証情報を常に `aws-iam-authenticator` で使用するように指定するには、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 を実行したのは誰か」を素早く関連付けようとする際に役立ちます。
**これは決定的なものと見なすべきではない**ことに注意してください。また、ユーザーがクライアント側でこれを変更する可能性があるため、CloudTrail ログと `role id`（一貫性が保たれる）を相互参照する必要があります。
## クラスタ外部からの API 認可
クラスタの外部にあるクライアントから Kubernetes API へリクエストを行うことが可能です。これは、素の Kubernetes REST API を使用する場合でも、言語固有の Kubernetes クライアント（例: [Python](https://github.com/kubernetes-client/python)）を使用する場合でも同様です。これを行うには、API へのリクエストに含めるベアラートークンを作成する必要があります。このベアラートークンには、STS GetCallerIdentity Query API への署名済み HTTP リクエストを base64 エンコードした文字列に、文字列 `k8s-aws-v1.` を付加する必要があります。そしてこれをリクエストの `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 認証情報がシェルで利用可能であることを確認してください(`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:
```
---
[Read more](https://github.com/kubernetes-sigs/aws-iam-authenticator)