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にアクセスする場合

ポイント１：IAMUserAとBはAssumeRoleしてEKSを操作することができる。
ポイント２：IAMUserCはAssumeRoleができないため、EKSを操作することができない。

EKS管理用ロールにAssumeRoleせずに直接EKSにアクセスする場合

ポイント１：IAMUserAはクラスタ作成者のため、自身の認証情報でEKSを操作することができる。
ポイント２：IAMUserBとCは自身の認証情報でEKSを操作することができない。

手順

　上のイメージを実現する各定義と手順は以下のようになります。

手順１ 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'

手順２　aws-authの更新

　手順１で作成した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

手順３　aws configにAssumeRole定義を追加

　IAMユーザーのクレデンシャルを基に手順１で作成した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

手順４　kubeconfigへクラスタの登録

下記のコマンドを実行し、kubeconfigファイルにクラスタ情報を登録します。

$ aws eks update-kubeconfig --name [eks cluster name] --profile profileA-eks-operator

　手順は以上の４ステップになります。
　EKSのクラスタ管理者を更新したい場合は手順１で作成したCFnテンプレートの「ここにAssumeRoleを許可するIAMユーザーを追加する」と記載した箇所を更新し、スタックを更新すれば完了です。

最後に

　EKSは最近触り始めたのですが、AWSの機構にk8sをうまく乗っけて作ってあるな、という印象を抱きました。ようやく慣れてきつつありますが、今回取り上げたRBACとIAMのようにAWSとkubernetesの概念が交錯してわかりにくいと感じる点も多々あります。今後も何か壁に当たっても焦らずに理解するように努めたいと思いました。