🤔

Github Actions Environmentにおける注意点

2023/04/23に公開

GitHub Environmentとは

Github Actionsでは、Yamlファイル外から参照できる変数(secretとvariable)が提供されてます。

Actions内で頻繁に再利用される変数はここでまとめよう、という便利機能です。

しかし、例えば、開発環境と検証環境で同じCIを回す場合、異なる変数をさす必要があるが､変数名だけが違う同じYamlを量産するのはDRYじゃないですね｡

そこで､CIの起動時にどの環境(environment)の変数を指すか指定することで､クールなCIが可能になる｡

正式名称がEnvironmentっていうふわっとした名前なのでここではActions変数と呼称します｡

例えば､本番環境の操作をリリースブランチでのActionsのみ許可している､といったことはよくあると思います｡
(CIは条件が整えば勝手にキックされてしまうので､もしもの安全バーは大事ですね)

terraform planを実行する際ProductionのActions変数にアクセスし､認証情報を取得する必要があります｡
しかし､PRの段階(開発ブランチ)でPlanの結果を

などで参照できる仕組みを実現したい場合､変数アクセスする必要があり､矛盾が生じます｡

正直､スマートな解決策はあまりなく､妥協案として
Github Environmentに

を作りましょう｡

ただ､実際TerraformなどAWSやGCPに読み取りでアクセスするし､本番環境に影響がないことを保証することは難しく､CIで使用するIAMを作り込む必要があります｡

最近の認証方法としてトークンを介さないWorkload Identity認証が主流になりつつあります｡
簡単に言うと､認証側がホワイトリスト的にドメインなどを指定して､許可する方法で､アクセスする側(CI)は非認証情報であるIDをもとに認証する仕組みです｡

これを使うと､CI全体として許可されるため､
IDを知ってしまえば､どのブランチでも認証できてしまう｡

(とはいえ､過剰に気にしすぎているきもしますが)

Workload Identityはドメインだけでなく､Gitのリポジトリ､ブランチ､Actionsワークフローなどを指定できます｡
厳密にやる or モノリポでやる､などの要件でやる場合は検討しましょ

Github Environment 微妙じゃない？