Github Actions から AWS を操作する場合の権限設計
yuto_engはじめに
Github Actions は、Github でソースコードを管理している場合、気軽に利用できる CI/CD ツールです。
気軽に使えるのですが、Githubで完結しないような操作の自動化を考たときに、
お試しで使ってみるだけな場合と、長期的に運用することを見込んでいる場合では、
設計が大きく異なることが分かってきました。
例えば、ECSへのデプロイや、コード化されているインフラの変更でGithub Actions を利用する場合などがこれに当たります。
そこで、どのような場合にどのような設計を行えば良いのか、
いくつかパターンを挙げてどのような特徴があるのかを挙げていくことにしました。
※
この記事は基本的に Github Actions 経由で AWS を操作することに焦点を当てています。
ただし、別のクラウドサービスについても似たような思想で展開可能なのではと考えています。
基本方針
Github Actions から AWS を操作は、IAM User のアクセスキーを利用する方法が公式から提供されています。こちらを利用します。
設計パターン
以下の4つを考えました。
- 環境適用の権限
- 環境適用の権限を引き受ける権限
- 環境適用するツールを実行する権限
- 環境適用するツールを実行する権限を引き受ける権限
1 -> 2 -> 3 -> 4 の順にGithub上に実装コストが上がります。
また、3,4に関しては既存の仕組みがある場合は実装コストを抑えられます。
これらを、利用用途、リスク回避について求められるレベルなどなど個別の事情でどの設計を
採用するのが最適かが変わってきます。
これらの設計パターンについて、以下の観点で細かく特徴の説明やメリット・デメリットの比較をしていきます。
- 実装工数
- 運用する中でのリスク
- 拡張性
1. 環境適用の権限を持つアクセスキーを発行する
Github Actions から行う操作を許可するポリシーを、IAM User に付与したものです。
この IAM User のアクセスキーを Github Actions に登録します。
この設計の大きなメリットは、圧倒的に実装工数が低いことにあります。
そのため、フラッシュアイデアを実現したり、プロトタイプで工数をかけずにものを作る場合に適した方法です。
しかし、この設計で作られたものを運用したり、新しく Workflow を増やすことを考えたときなど、
長い目で見ると様々なデメリットが見えてきます。
新しい Workflow を増やすときに、この設計を展開する方法として、2つ考えられます。
- 複数の Workflow でアクセスキーを共有する
- アクセスキーを新しく発行し新しく登録する
1の方法で展開したとき、一つのアクセスキーで操作できる範囲が増えることになります。
機能拡張が増えるたびにその範囲は Admin 権限に近づいていきます。
これは、Workflow の実装にミスがあったとき、意図しない操作を AWS に行うことを誘発するデメリットがあります。
また、アクセスキーが万が一流出し悪用されるリスクはどんどん高まるというデメリットもあります。
2の方法で展開した時、登録するアクセスキーが多くなってしまい、管理コストが高くなるというデメリットがあります。
長く運用することを考えるのであれば、Github Actions が利用するアクセスキーの権限は必要最小限に抑えるほうがよく、
管理コストも低いほうが良いので、この設計パターンは採用しないほうが良いと言えます。
2. 環境適用の権限を引き受ける権限を持つアクセスキーを発行する
Github Actions から行う操作を許可されている IAM role を Assume するポリシーを IAM User に付与したものです。
この IAM User のアクセスキーを Github Actions に登録します。
この設計を採用した場合、 Workflow ごとに IAM role を準備することで、
どの Workflow からどのような権限が利用されているのかを管理しやすくなります。
IAM role, policy が必要最低限の権限に絞られており、Workflow から Assume する IAM role の選択を誤らなければ、
Workflowに実装ミスがあっても、意図しない意図しない操作を AWS に行うことを防げます。
長く運用したり拡張したりすることを見据えたときに、最も実装工数の低い設計がこの方式です。
この方法の1の設計に比べたデメリットは、以下の実装工数が増えることです。
- Github に登録したアクセスキーを利用して Assume される IAM role の準備
- Workflow 内部から Assume 操作の実装
後者については、公式のプラグインで簡単に実装する方法が提供されているので、それほど工数のかかるものではありません。
Github Actions に登録するアクセスキーは、IAM role を Assume ことのみ許可されており、1の設計に比べるとかなり権限を絞れています。
万が一漏れ出した場合、悪用されるリスクはありますが、1の設計ほど高くはありません。
3. 環境適用するツールを実行する権限を持つアクセスキーを登録する
Github Actions から AWS を操作するツールを呼び出すことを許可するポリシーを IAM User に付与したものです。
この IAM User のアクセスキーを Github Actions に登録します。
この方式は、Github Actions が Codebuild などの AWS を操作する別のツールを呼び出す方法です。
1の設計に比べ、AWSを操作する別のツールを準備する分の工数がかかります。
その分、アクセスキーで許可されている操作はツールを呼び出すことだけです。
直接AWS内部を操作されるわけではなく、かなり絞り込まれています。
ただし、1の設計で述べたような運用のしづらさがあるため、
AWSを操作する別の仕組みがもともとある状態でプロトタイプするときにしか適していません。
4. 環境適用するツールを実行する権限を引き受ける権限を持つシークレットを登録する
Github Actions からAWS を操作する仕組みを呼び出すこと許可されている IAM role を Assume するポリシーを IAM User に付与したものです。
この IAM User のアクセスキーを Github Actions に登録します。
この方法は、3の設計に比べて更に以下の実装が増えます。（設計2にあるものと同じ）
- Github に登録したアクセスキーを利用して Assume される IAM role の準備
- Workflow 内部から Assume 操作の実装
Github Actions に登録するアクセスキーで許可されている権限が最も絞り込まれた状態です。
AWSを操作する別の仕組みがもともとある状態で Github Actions を利用したい場合や、
できるだけアクセスキーで許可されている権限を絞り込みたい要件がある場合に適しています。
まとめ
Github Actions でプロトタイピングをするときは1の設計、新規で仕組みを作成する場合は2の設計、
既存に仕組みがある程度ある状態で Github Actions に移行する場合は 4の設計が良さそうです。
また、極力 Github に登録するアクセスキーの権限を絞り込みたいときは 4の設計が良さそうです。