1クール続けるブログ読者になる1クール続けるブログとりあえず1クール続けるソフトウェアエンジニアの備忘録この広告は、90日以上更新していないブログに表示しています。下記の記事で、k8s内のリソースからAWSのリソースを操作する時の権限のマッピングについて書いたけど、今回はIAMロールorユーザがk8sのリソースを操作する時の権限のマッピングについての話です。k8sのwebhook認証を利用して、EKSはaws-iam-authentificatorとやり取りしてIAMの情報からk8sのsubjectを取得しています。そのフローの中で利用されるのがkube-system/aws-authのConfigMap。k8sのRoleBindingで定義されるユーザやグループにIAMロール/ユーザをマッピングできます。44smkn.hatenadiary.comEKSにおけるAuthentification(認証)参考にさせていただいたのは下記の記事です。Containers」に記載されている図がとてもわかり易いので、そちらを引用させていただきます。起点となるのはkubectlとなります。APIを叩くとしても流れとして大きくは変わらないのでkubectlで話を勧めていきます。pluginsという機能があります。k8s.io/client-goがネイティブにサポートしていない認証プロトコルとクライアントを統合してくれるものです。サービスアカウントトークン等とは違い、IAMでの認証はネイティブにサポートされていないので、このプラグインを利用することになります。EKSの場合に用いるプラグインはaws-iam-authenticatorとなります。kubeconfigには下記のように宣言します。<ROLE_ARN>が実行され、標準出力に下記のように出力します。Tokenとして、AuthorizationHTTPヘッダとして付与され、k8sのAPIサーバにリクエストされます。このトークンの中身は署名付きURLをbase64エンコードされたものになっています(該当コード)。URLを署名するためにはもちろん認証情報が必要になります。ARNを指定した場合には、そのロールにAssumeRoleを行うことになります。この辺の流れは、Pythonのコードの方が分かりやすいかも。ここまでが冒頭で引用させていただいた図の1より前の部分になります。Tokenの付与されたリクエストはk8sのAPIサーバに到達します。APIサーバではそのトークンが正しいかどうかを検証する必要があります。IAMの認証情報であるため、k8sだけでは検証することは不可能です。Tokenを検証するためにWebhook認証という機能があります。別のコンポーネントにPOSTリクエストを投げて、下記のようなレスポンスを返却してもらうことで、k8sでのユーザ/グループを特定します。}トークンを検証する別のコンポーネントというのがaws-iam-authenticatorのサーバです。serverのサブコマンドで起動します。EKSの(おそらく)マスターノードで動いています。k8sのAPIサーバはこのエンドポイントをどう知りうるのかというと、aws-iam-authenticatorサーバ起動時に生成される設定ファイルを--authentication-token-webhook-config-fileの引数に渡してあげることで認識できます。冒頭で引用した1に当たる部分で、k8sのAPIサーバからトークンがaws-iam-authenticatorのエンドポイント/authenticateにPOSTリクエストで渡されます。2に当たる部分でトークンの有効性を確認します(該当コード)。その後は、3に当たる部分で、ユーザ名とグループ名をaws-authというConfigMapと照らし合わせてAPIサーバに返す(該当コード)。k8sのAPIサーバは渡されたユーザ名とグループ名に基づいて、Authorization(認可)を行うという流れになります。aws-authの定義の仕方ほとんどこのドキュメントに書いてあること。k8sが扱うときの名前になる(※1)。subjectのkindがUserのものと名称が一致すれば、その権限を得る(※2)。opsというユーザが既に存在。3はてなブログをはじめよう!jrywm121さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。