翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
EKS アクセスエントリ
eksctl を使用して EKS アクセスエントリを管理できます。アクセスエントリを使用して、AWS IAM ID に Kubernetes アクセス許可を付与します。たとえば、クラスター内の Kubernetes リソースを読み取るアクセス許可を開発者ロールに付与できます。
このトピックでは、eksctl を使用してアクセスエントリを管理する方法について説明します。アクセスエントリの一般的な情報については、「EKS アクセスエントリを使用して Kubernetes へのアクセス権を IAM ユーザーに付与する」を参照してください。
AWS で定義された Kubernetes アクセスポリシーをアタッチすることも、IAM アイデンティティを Kubernetes グループと関連付けることもできます。
使用可能な事前定義ポリシーの詳細については、「アクセスポリシーをアクセスエントリに関連付ける」を参照してください。
顧客の Kubernetes ポリシーを定義する必要がある場合は、IAM Identity を Kubernetes グループに関連付け、そのグループにアクセス許可を付与します。
クラスター認証モード
アクセスエントリは、クラスターの認証モードが許可する場合にのみ使用できます。
詳細については、「クラスター認証モードの設定」を参照してください。
YAML ファイルを使用して認証モードを設定する
eksctl は ClusterConfig に新しいaccessConfig.authenticationModeフィールドを追加しました。これは、次の 3 つの値のいずれかに設定できます。
-
CONFIG_MAP- EKS API のデフォルト -aws-authConfigMap のみが使用されます -
API- アクセスエントリ API のみが使用されます -
API_AND_CONFIG_MAP- default ineksctl-aws-authConfigMap とアクセスエントリ API の両方を使用できます
ClusterConfig YAML で認証モードを設定します。
accessConfig: authenticationMode: <>
コマンドを使用して認証モードを更新する
既存の eksctl 以外の作成済みクラスターでアクセスエントリを使用する場合、 CONFIG_MAPオプションを使用するときは、ユーザーはまず authenticationMode を に設定する必要がありますAPI_AND_CONFIG_MAP。そのために、 eksctl はクラスター認証モードを更新するための新しいコマンドを導入しました。これは、 などの CLI フラグの両方で機能します。
eksctl utils update-authentication-mode --cluster my-cluster --authentication-mode API_AND_CONFIG_MAP
アクセスエントリリソース
アクセスエントリには、 STANDARDや などのタイプがありますEC2_LINUX。タイプは、アクセスエントリの使用方法によって異なります。
-
standardタイプは、IAM ユーザーと IAM ロールに Kubernetes アクセス許可を付与するためのものです。-
たとえば、コンソールへのアクセスに使用するロールまたはユーザーにアクセスポリシーをアタッチすることで、AWS コンソールで Kubernetes リソースを表示できます。
-
-
EC2_LINUXおよびEC2_WINDOWSタイプは、EC2 インスタンスに Kubernetes アクセス許可を付与するためのものです。インスタンスは、これらのアクセス許可を使用してクラスターに参加します。
アクセスエントリのタイプの詳細については、「アクセスエントリの作成」を参照してください。
IAM エンティティ
アクセスエントリを使用して、IAM ユーザーや IAM ロールなどの IAM ID に Kubernetes アクセス許可を付与できます。
accessConfig.accessEntries フィールドを使用して、IAM リソースの ARN を Access Entries EKS API に関連付けます。例えば、次のようになります。
accessConfig: authenticationMode: API_AND_CONFIG_MAP accessEntries: - principalARN: arn:aws:iam::111122223333:user/my-user-name type: STANDARD kubernetesGroups: # optional Kubernetes groups - group1 # groups can used to give permissions via RBAC - group2 - principalARN: arn:aws:iam::111122223333:role/role-name-1 accessPolicies: # optional access polices - policyARN: arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy accessScope: type: namespace namespaces: - default - my-namespace - dev-* - principalARN: arn:aws:iam::111122223333:role/admin-role accessPolicies: # optional access polices - policyARN: arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy accessScope: type: cluster - principalARN: arn:aws:iam::111122223333:role/role-name-2 type: EC2_LINUX
EKS ポリシーの関連付けに加えて、IAM エンティティが属する Kubernetes グループを指定して、RBAC 経由でアクセス許可を付与することもできます。
マネージド型ノードグループと Fargate
これらのリソースのアクセスエントリとの統合は、EKS API によってバックグラウンドで実現されます。新しく作成されたマネージド型ノードグループと Fargate ポッドは、事前にロードされた RBAC リソースを使用するのではなく、API アクセスエントリを作成します。既存のノードグループと Fargate ポッドは変更されず、aws-auth 設定マップのエントリに引き続き依存します。
セルフマネージド型ノードグループ
各アクセスエントリにはタイプがあります。セルフマネージド型ノードグループを承認するために、 eksctlは、プリンシパル ARN をノードロール ARN に設定し、タイプをノードグループの amiFamily EC2_WINDOWSに応じて EC2_LINUXまたは に設定して、各ノードグループに一意のアクセスエントリを作成します。
独自のアクセスエントリを作成するときは、 EC2_LINUX (Linux または Bottlerocket セルフマネージドノードで使用される IAM ロールの場合)、 EC2_WINDOWS (Windows セルフマネージドノードで使用される IAM ロールの場合)、 FARGATE_LINUX (AWS Fargate (Fargate) で使用される IAM ロールの場合)、またはタイプSTANDARDとして を指定することもできます。タイプを指定しない場合、デフォルトのタイプは に設定されますSTANDARD。
注記
既存の で作成されたノードグループを削除する場合instanceRoleARN、ノードグループがそれ以上関連付けられていない場合、対応するアクセスエントリを削除するのはユーザーの責任です。これは、eksctl は複雑なプロセスであるため、eksctl が作成していないセルフマネージド型ノードグループによってアクセスエントリがまだ使用されているかどうかを調べようとしないためです。
アクセスエントリを作成する
これは、クラスターの作成時に、設定ファイルの一部として目的のアクセスエントリを指定して実行するという 2 つの異なる方法で行うことができます。
eksctl create cluster -f config.yaml
以下を実行して、クラスターの作成後に または を実行します。
eksctl create accessentry -f config.yaml
アクセスエントリを作成するための設定ファイルの例については、eksctl GitHub リポジトリの「40-access-entries.yaml
アクセスエントリの取得
ユーザーは、次のいずれかを実行して、特定のクラスターに関連付けられているすべてのアクセスエントリを取得できます。
eksctl get accessentry -f config.yaml
OR
eksctl get accessentry --cluster my-cluster
または、特定の IAM エンティティに対応するアクセスエントリのみを取得するには、 --principal-arnフラグを使用します。例:
eksctl get accessentry --cluster my-cluster --principal-arn arn:aws:iam::111122223333:user/admin
アクセスエントリを削除する
一度に 1 つのアクセスエントリを削除するには、以下を使用します。
eksctl delete accessentry --cluster my-cluster --principal-arn arn:aws:iam::111122223333:user/admin
複数のアクセスエントリを削除するには、 --config-fileフラグを使用して、最上位accessEntryフィールドで、アクセスエントリprincipalARN’sに対応するすべての を指定します。例:
... accessEntry: - principalARN: arn:aws:iam::111122223333:user/my-user-name - principalARN: arn:aws:iam::111122223333:role/role-name-1 - principalARN: arn:aws:iam::111122223333:role/admin-role
eksctl delete accessentry -f config.yaml
aws-auth ConfigMap から移行する
ユーザーは、以下を実行して、既存の IAM ID を configmap aws-auth からアクセスエントリに移行できます。
eksctl utils migrate-to-access-entry --cluster my-cluster --target-authentication-mode <API or API_AND_CONFIG_MAP>
--target-authentication-mode フラグが に設定されている場合API、認証モードは API モードに切り替えられ (既に API モードになっている場合はスキップされます)、IAM ID マッピングはアクセスエントリに移行され、aws-auth設定マップはクラスターから削除されます。
--target-authentication-mode フラグが に設定されている場合API_AND_CONFIG_MAP、認証モードは API_AND_CONFIG_MAP モード (既に API_AND_CONFIG_MAP モードの場合はスキップ) aws-auth に切り替わり、IAM ID マッピングはアクセスエントリに移行されますが、設定マップは保持されます。
注記
--target-authentication-mode フラグが に設定されている場合API、configmap aws-auth に次のいずれかの制約がある場合、このコマンドは認証モードを API モードに更新しません。
-
アカウントレベルの ID マッピングがあります。
-
1 つ以上のロール/ユーザーは、プレフィックス (、
system:bootstrapperssystem:nodesなどの EKS 固有のグループsystem:を除く) で始まる kubernetessystem:mastersグループにマッピングされます。 -
1 つ以上の IAM ID マッピング (複数可) が [サービスにリンクされたロール](link:IAM/latest/UserGuide/using-service-linked-roles.html) 用です。
クラスター作成者の管理者権限を無効にする
eksctl はaccessConfig.bootstrapClusterCreatorAdminPermissions: boolean、false に設定すると、クラスターを作成する IAM ID への cluster-admin アクセス許可の付与を無効にする新しいフィールドを追加しました。つまり、
設定ファイルに オプションを追加します。
accessConfig: bootstrapClusterCreatorAdminPermissions: false
と を実行します。
eksctl create cluster -f config.yaml