⚙️

Github EnvironmentのススメとWorkload Identityの問題

2022/07/17に公開

読者対象

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