EKSの管理者権限の管理方法について
はじめに
EKSクラスターの構築初期状態では、適切な権限を持つIAMロール、ユーザーであっても、クラスターの作成者以外はEKSの操作(eksctl、kubectlなど)が行うことができません。これはEKSクラスターのロールベースアクセス制御 (RBAC) によって対象のIAMが承認されていないことによって発生します。
EKSクラスタ作成者以外の管理者にクラスタの操作権限を付与するためにはこちらのページにある通りに実施すれば良いのですが、どのように管理するか、という話が別にあります。一管理手法としての例を紹介しますので参考になれば幸いです。
クラスタ管理者をどう管理するか
上記のリンクにあるサンプルファイルを編集し、適用することで記載されたIAMロールやIAMユーザーからのEKSクラスタへの操作が可能となります。
IAMユーザーをそのまま記載する場合、単体のマニフェストファイルを適用する運用方法であれば問題は起きませんが、kustomizeなどのツールを使用して、複数のマニフェストファイルをマージした状態で適用する運用の場合、ユーザー追加ごとにマニフェストの適用が走ることになるため、ただ管理者を更新したいだけなのにkubernetesの定義を更新しなければなりません。
そこで、EKS管理用のIAMロールを用意し、そのIAMロールにAssumeRoleしたユーザーのみEKSの操作を許可することで、管理者権限の付与、削除をIAMで完結できるようにしました。
次のようなイメージです。
登場人物
IAMユーザー | 説明 |
---|---|
A | EKSクラスタの作成者、EKS管理用ロールにAssumeRole可能 |
B | EKS管理用の権限は持っていないが、EKS管理用ロールにAssumeRoleできる |
C | EKS管理用の権限は持っているが、EKS管理用ロールにAssumeRoleできない |
EKS管理用ロールにAssumeRoleしてEKSにアクセスする場合
ポイント1:IAMUserAとBはAssumeRoleしてEKSを操作することができる。
ポイント2:IAMUserCはAssumeRoleができないため、EKSを操作することができない。
EKS管理用ロールにAssumeRoleせずに直接EKSにアクセスする場合
ポイント1:IAMUserAはクラスタ作成者のため、自身の認証情報でEKSを操作することができる。
ポイント2:IAMUserBとCは自身の認証情報でEKSを操作することができない。
手順
上のイメージを実現する各定義と手順は以下のようになります。
手順1 IAMロールの作成
EKS管理用のIAMロールを作成します。以下のCFnテンプレートを作成し、スタックを作成します。
IAMRoleEKSOperator:
Type: 'AWS::IAM::Role'
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
-
Effect: Allow
Principal:
AWS:
### ここにAssumeRoleを許可するIAMユーザーを追加する
- !Sub 'arn:aws:iam::${AWS::AccountId}:user/A'
- !Sub 'arn:aws:iam::${AWS::AccountId}:user/B'
Action:
- 'sts:AssumeRole'
Condition:
Bool:
aws:MultiFactorAuthPresent: true
MaxSessionDuration: 43200
ManagedPolicyArns:
- 'arn:aws:iam::aws:policy/AmazonEKSServicePolicy'
Policies:
- PolicyDocument:
Statement:
- Effect: 'Allow'
Action:
- 'eks:ListClusters'
- 'eks:ListNodegroups'
- 'eks:ListTagsForResource'
- 'eks:DescribeCluster'
- 'eks:DescribeNodegroup'
- 'eks:DescribeUpdate'
Resource: '*'
PolicyName: 'allow-eks-access'
RoleName: 'eks-operator'
手順2 aws-authの更新
手順1で作成したIAMロールからの操作を許可するマニフェストファイルを作成し、適用します。
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::000000000000:role/eks-operator
username: eks-operator
groups:
- system:masters
手順3 aws configにAssumeRole定義を追加
IAMユーザーのクレデンシャルを基に手順1で作成したIAMロールにAssumeRoleを行う定義を~/.aws/configに追加します。
[profile profileA]
region = ap-northeast-1
output = json
[profile profileA-eks-operator]
source_profile = profileA
role_arn = arn:aws:iam::000000000000:role/eks-operator
region = ap-northeast-1
output = json
mfa_serial = arn:aws:iam::000000000000:mfa/A
duration_seconds = 43200
手順4 kubeconfigへクラスタの登録
下記のコマンドを実行し、kubeconfigファイルにクラスタ情報を登録します。
$ aws eks update-kubeconfig --name [eks cluster name] --profile profileA-eks-operator
手順は以上の4ステップになります。
EKSのクラスタ管理者を更新したい場合は手順1で作成したCFnテンプレートの「ここにAssumeRoleを許可するIAMユーザーを追加する」と記載した箇所を更新し、スタックを更新すれば完了です。
最後に
EKSは最近触り始めたのですが、AWSの機構にk8sをうまく乗っけて作ってあるな、という印象を抱きました。ようやく慣れてきつつありますが、今回取り上げたRBACとIAMのようにAWSとkubernetesの概念が交錯してわかりにくいと感じる点も多々あります。今後も何か壁に当たっても焦らずに理解するように努めたいと思いました。
Author And Source
この問題について(EKSの管理者権限の管理方法について), 我々は、より多くの情報をここで見つけました https://qiita.com/Ichi0124/items/8e9325f7bb0305cfe843著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .