kubernetes-sigs/aws-iam-authenticatorAWS IAM 認証情報を使用して Kubernetes クラスターに認証するためのツール
AWS IAM 認証情報を使用して Kubernetes クラスターへ認証するためのツールです。 このツールの初期開発は Heptio によって主導されました。本プロジェクトは複数のコミュニティエンジニアからの貢献を受けており、現在は Heptio と Amazon EKS OSS Engineers によってメンテナンスされています。
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 のサポートを追加したいと仮定すると、次のことを行う必要があります:
まず、Kubernetes クラスター内のユーザー/グループにマッピングされる 1 つ以上の IAM ロールを作成する必要があります。 最も簡単な方法は、AWS コンソールにログインすることです:
これにより、アカウント内の認可されたユーザー/ロールが引き受け可能な、権限のない IAM ロールが作成されます。 以下で必要となるため、ロールの Amazon Resource Name (ARN) を控えておいてください。
AWS コンソールの代わりに AWS CLI を使用して、これを 1 ステップで行うこともできます:
# 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'
次の手順をスキップして、以下を使用することもできます:
mapUsers を参照）。mapRoles を参照）。このサーバーは、各マスターノード上で DaemonSet としてホストネットワーキングを使用して実行され、localhost ポートを公開することを想定しています。
ConfigMap と DaemonSet の設定例については、deploy/example.yaml を参照してください。
適用する前に、クラスタに合わせて以下の値を更新してください:
config.yaml 内のプレースホルダー IAM ARN（arn:aws:iam::000000000000:...）を置き換えます。clusterID をクラスタ固有の一意な値に設定します。その後、デプロイします:
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を作成します。
自動インストーラーを構築している場合は、aws-iam-authenticator init を使用して証明書、鍵、Webhook kubeconfigファイルを簡単に事前生成することもできます。
このコマンドはファイルを生成し、設定された出力ディレクトリに配置します。
APIサーバーを起動する前に、各マスターノードでこれを実行できます。 また、マスターノードをプロビジョニングする前に生成し、適切なホストパスにインストールすることもできます。
ファイルを事前生成しない場合、aws-iam-authenticator server がオンデマンドで生成します。
これは動作しますが、インストール後にKubernetes 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
サーバーのデフォルトの動作は、設定ファイルの 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 (alpha)このバックエンドは、各 IAM マッピングを IAMIdentityMapping Kubernetes カスタムリソースとしてモデル化します。このアプローチにより、kubectl または API を使用して Kubernetes ネイティブな方法でマッピングを維持できます。さらに、構文エラー (YAML のずれなど) をより簡単に検出でき、すべてのマッピングに影響を与えることはありません。
IAMIdentityMapping CRD をセットアップするには、まず CRD マニフェストを apply する必要があります:
kubectl apply -f deploy/iamidentitymapping.yaml
CRD をデプロイしたら、IAM アイデンティティをモデル化するカスタムリソースを作成できます。./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
EKSConfigMapEKS 形式の kube-system/aws-auth ConfigMap がバックエンドとして機能します。この
ConfigMap は EKS クラスタとまったく同じ形式であることが想定されています:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html。これは
EKS との間で移行する際にマッピングを維持したい場合や、他の AWS クラスタに加えて
EKS を運用していて各クラスタで同じマッピングを持ちたい場合に便利です。
DynamicFilecfg.dynamicfilepath で指定されたローカルファイルをバックエンドとして機能させることができます。ファイルの 内容は EKSConfigMap とまったく同じ形式であることが想定されています。このファイルの内容が 変更されるたびに、authenticator は自動的にそれを再読み込みします。これにより ARN マッピングの管理がより柔軟になります。
DynamicFile モードの設定方法については https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml を確認してください。