AWS IAM Authenticator for Kubernetes

AWS IAM 認証情報を使用して Kubernetes クラスターに認証するためのツールです。このツールの初期開発は Heptio によって推進されました。このプロジェクトは複数のコミュニティエンジニアからの貢献を受けており、現在は Heptio と Amazon EKS OSS エンジニアによってメンテナンスされています。

なぜこれが必要なのか?
どう使うのか?
Kops の使い方
どう動作するのか?
クラスター ID とは何か?
認証情報の指定と AWS プロファイルの使用
クラスター外部からの API 認可
トラブルシューティング
完全な設定形式
開発
コミュニティ、議論、貢献、サポート

なぜこれが必要なのか?

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 サーバーが Authenticator と通信するように設定します。
kubectl が Authenticator トークンを使用するように設定します。

1. IAM ロールを作成する

まず、Kubernetes クラスター内のユーザー/グループにマッピングされる 1 つ以上の IAM ロールを作成する必要があります。これを行う最も簡単な方法は、AWS コンソールにログインすることです:

「クロスアカウントアクセス用のロール」/「自分が所有する AWS アカウント間のアクセスを提供」オプションを選択します。
AWS アカウント ID 番号を貼り付けます(コンソールの右上に表示されます)。
ロールには追加のポリシーをアタッチする必要はありません。

これにより、アカウント内の承認されたユーザー/ロールが引き受けることができる、権限のない IAM ロールが作成されます。以下の手順で必要になるため、ロールの Amazon リソースネーム (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 を使用して 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. IAM ロール/ユーザーから Kubernetes ユーザー/グループへのマッピングを作成する

サーバーのデフォルトの動作は、設定ファイルの mapUsers フィールドと mapRoles フィールドからのみマッピングを取得することです。詳細については、下記の完全な設定形式を参照してください。

--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`

これはマッピングのデフォルトのバックエンドであり、ほとんどのユーザーにとって十分です。詳細については、下記の完全な設定形式を参照してください。

`CRD` (アルファ)

このバックエンドは、各 IAM マッピングを IAMIdentityMapping Kubernetes カスタムリソースとしてモデル化します。このアプローチにより、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 を確認してください。

aws-iam-authenticator v0.7.19

AWS IAM Authenticator for Kubernetes

Table of Contents

なぜこれが必要なのか?

どう使うのか?

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` (アルファ)

`EKSConfigMap`

`DynamicFile`

カテゴリ

aws-iam-authenticator v0.7.19

AWS IAM Authenticator for Kubernetes

Table of Contents

なぜこれが必要なのか?

どう使うのか?

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 (アルファ)

EKSConfigMap

DynamicFile

カテゴリ

`MountedFile`

`CRD` (アルファ)

`EKSConfigMap`

`DynamicFile`