⚙️
Github EnvironmentのススメとWorkload Identityの問題
読者対象
GtihubActionsを軸にCI/CDやDevOpsの起点を作っているプロダクトチーム
Github Actions Secretのイケてないところ
- Github ActionsはDefaultブランチにactionsの定義ファイルがある場合、任意のFeatureブランチで、そのactions定義ファイルを編集し、commitするだけで、任意のActionsが実行できてしまう。
- 環境別で処理を記述する場合、
if: env.environment == "decelopment"
といった条件分岐が必要で、記述する必要のあるstepが環境分増えてしまい冗長になりがち。
Github Actions Environmentのメリット
Secretではブランチの作成権限を持つ全てのユーザに等しくセキュア情報へのアクセス・利用を可能にしていた。
Environment
を導入し、Branch Protectionを有効にすることで、Secret情報へのアクセスをBranch単位で制限をかけることができる。
課題1:Github Actions EnvironmentとWorkload Identity Providerとの相性の悪さ
Workload Identityとは
例えば、GithubでGoogleCloudの認証を突破し、何らかのAPIを叩きたいとき、
従来の事前合意したキーを用いた認証と異なり認証側(例えばGoogleCloud側)で、どのドメイン、どのユーザ、リポジトリetc(トークンが持つ属性)を指定して、それに合致するトークンだけを認証する方式。
キーレスなためセキュアで、サービス連携の際に推奨されている。
Actions側からの指定方法
すでに、Google側でトークンの指定が完了しており、
Github側でWIP(=Workload Provider Identity)を利用するには
以下の2つだけで良い。
projects/{プロジェクト番号}/locations/global/workloadIdentityPools/my-pool/providers/my-provider
my-service-account@{プロジェクトID}.iam.gserviceaccount.com
対策
Google側でカスタムトークンの属性を指定できるので、
- リポジトリ(repo)
- ワークフロー(workflow)
- ブランチ(ref)
- 実行ユーザ(actor)
などを指定して縛る
ref == ref/heads/main
workflow == MyWorkflow
とか指定してみると、セキュアになる
課題2:Github Actions Environment でTerraform Planしづらい
Environmentを導入することで、mainブランチ以外はProduction Secretにアクセスできなくなってしまう。
Plan用のEnvironmentを追加してやればいいのですが、実際に付与する権限が難しい。
IAMをViewer権限でざっくり付与してやるだけではうまくいかず、一部サービスに対してはWrite権限が必要。
でも、そうなると、インフラの操作もできてしまったり、、、答えは、、、なし、、、
Discussion