AWSとGitHub ActionsのWeb ID federationでの連携周りの実験とか
ベースはこのへん
見た感じ、そのうちconfigure-aws-credentialsが公式になんらかの対応をしそうな感じ
ここを見ると、cliでトークン読んで明示的にAssumeRoleするともう少し設定はできそう
で、昨日試してみたところweb-identity-token-file:
に取得したトークンのパスを渡してやれば問題なく使えそう。
持続期間やセッション名もどうやら合わせて指定できそう。
この辺をあとでちゃんと記事にします。
ついでに、AWS側に作成が必要なリソースをTerraformで書いてみたりしました(これについては他の方がほぼどうようなことをやっていたのであまり細かくは説明しないつもり)
元の紹介記事では
AWS_WEB_IDENTITY_TOKEN_FILE
にGitHubから取得するトークンのファイルパスを
AWS_ROLE_ARN
には使いたいロールのarnを
それぞれ指定することによって、どうやら暗黙的にAssumeRoleしてくれるらしい(この辺の挙動がよく分かっていなくてドキュメント見てもよくわからないので誰か分かる人に説明して欲しい…。ソースのここを見ればわかる、とかでもありがたいです。)
ただこれだと細かいオプション(セッションの期限やセッション名)が渡せないので、できればどこかで明示的にAssumeRoleしたかった。
以下のエントリではassume-roleして呼び出した一時キーや一時トークンを渡しているが、最初に書いた方法で問題なければこんなめんどくさいことはしなくても良さそう。
そのほかに設定可能な項目はこちら。
こういうのはReadMeに書いておいて欲しいもんだけど…。AssumeRoleさえしてしまえばあとはその権限を期限の間に使えればいい、という認識だったけど、
自分の認識ではGitHubのトークンの方の期限が切れてもそれはAssumeRoleするときだけあれば良い、なんだけど果たしてそれが正しいか。
bitbucketでは似たような感じのことがドキュメントに載っている
oidc: true
という見慣れないオプションがある…。
トークンを呼び出すURLが変数に追加されたのはごく最近?
実験の跡はこちら。
ActionsはWorkflow Dispatchで手動実行してるけど、アカウントIDは変数化している。ただ、Actionsを実行したらアカウントIDがログに残っちゃうので実験したログは毎度消しています。
最初は自分で作ったけどぶっちゃけここでほぼやりたいことをやっていたので参考にさせていただいた。
記事にしました。