EKSのRBACによる認証にAWS SSOで発行されるIAMRoleを使用する #AWS

はじめに

　社内でAWS SSOが導入されたことで、EKSの管理者権限の管理方法についての記事を見てくださった社内の方から、SSOで発行されるIAMロールでRBACの認証をすることはできますか、と問い合わせをもらったので調べました。
　結論としてはできます、むしろすごく運用が楽になったので是非ともやるべき、とお勧めできるのですが、ハマりポイントがあったので備忘を兼ねて記事にします。

やったこと（うまくいかなかったパターン）

成功したパターンを書く前にうまくいかなかったパターンから紹介します。

手順1 aws-authにIAMRoleを追加

　AWS SSOから発行されたIAMRoleをRBACで認証するためにConfigMapのaws-authを更新するためのマニフェストファイルを作成します。作成後、kubectl applyコマンドで適用します。


apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::000000000000:role/hogehoge
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::000000000000:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_0123456789abcdefg
      username: sso-eks-operator
      groups:
        - system:masters

手順2 AWS Profileのセットアップ

　AWSCLIv2を利用している場合はaws configure ssoコマンドでProfileをセットアップします。今回は sso-profile という名前で作成しました。
　余談ですが、AWSCLIv2は最近使い始めたのですが、最初はインターフェースがかなり変わっていて驚いたのですが、補完機能やSSO連携など機能が充実していてかなり良いですね。
　SSO連携時のProfileはどうやって発行するの？？という方もいるかと思いますので、発行時のキャプチャを貼っておきます。

　AWSCLIv1の場合は、AWS SSOのコンソールからアクセスキー、シークレットキーを取得し、従来の方法でProfileを設定します。こちらの記事が参考になるかと思います。

手順3 kube configの更新

　以下のコマンドを実行し、 ~/.kube/config を更新します。


$ aws eks update-kubeconfig --name [cluster_name] --profile sso-profile

手順4 アクセス確認

　ここまでくればあとはEKSを操作するだけとなります。kubectlコマンドを実行し、操作できるかを確認します。


$ kubectl get pod
error: You must be logged in to the server (Unauthorized)

　k8sを触ったことがある人は全員目にしたことがある（はずの）RBACで弾かれてそうなエラーが出ました。設定を見直してもおかしそうなところはなく、原因がわからなかったのでサポートケースを起票することにしました。

ハマりポイント

　サポートケースをチャット形式で起票し、状況を伝えるなど対話を重ねる中で、一つのブログ記事を紹介していただきました。ブログ記事はこちらになります。
　この記事を読み進めると、以下のように言及されています。

For the rolearn be sure to remove the /aws-reserved/sso.amazonaws.com/ from the rolearn url, otherwise the arn will not be able to authorize as a valid user.

　かいつまんで直訳すると、 rolearnから「/aws-reserved/sso.amazonaws.com/」を削除する です。

　早速やってみました。
　上記の「手順１ aws-authにIAMRoleを追加」で作成したConfigMapを編集し、 /aws-reserved/sso.amazonaws.com/を削除 し、kubectl applyします。


apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::000000000000:role/hogehoge
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::000000000000:role/AWSReservedSSO_AdministratorAccess_0123456789abcdefg
      username: sso-eks-operator
      groups:
        - system:masters

　これを適用したことで、無事にEKSを操作できるようになりました。

さいごに

　AWS SSOやAWSCLIv2のSSO連携など、SREとして運用負荷の下がる機能のリリースが次々とあり、ありがたいと感じている一方で、私自身AWSCLIv2がリリースされてから実際に利用するまでにラグがあったように、使ってみればすごくいいものでも、キャッチアップして使うまでが大変ということをつくづく感じました。
　ただ、今回はサポートケースを頼らせてもらいましたが、最近ではサポートケースをチャット形式で利用させてもらっており、対話形式の中で状況確認を適切に行なって頂いているためか、短時間で芯を食った回答を得られることが増えており非常に助かっています。

　今回この件を調べることになったきっかけは別チームの方からの問い合わせでしたが、良いアイデアをもらったので、感謝しつつ弊チームでも利用させていただくこととします。