読者対象
GtihubActionsを軸にCI/CDやDevOpsの起点を作っているプロダクトチーム
Github Actions Secretのイケてないところ
- Github ActionsはDefaultブランチにactionsの定義ファイルがある場合､任意のFeatureブランチで､そのactions定義ファイルを編集し､commitするだけで､任意のActionsが実行できてしまう｡
- 環境別で処理を記述する場合､
if: env.environment == "development"といった条件分岐が必要で､記述する必要のあるstepが環境分増えてしまい冗長になりがち｡
つまるところ
- ブランチの作成権限をもつ全てのユーザは任意のActionsを実行できてしまう
- ブランチの作成権限をもつ全てのユーザは任意のSecretにアクセスできてしまう
- 大量のif分岐が発生する
- インフラ構成などに関するActionsのデバッグを試しづらい
(.yamlファイルの書き間違いや分岐処理のミスで､Production環境のSecretを利用してしまう恐れがある｡)
Github Actions Environmentのメリット
Secretではブランチの作成権限を持つ全てのユーザに等しくセキュア情報へのアクセス・利用を可能にしていた｡
Environmentを導入し､Branch Protectionを有効にすることで､Secret情報へのアクセスをBranch単位で制限をかけることができる｡
- 指定したブランチでしかProductionのSecretへアクセスできなくなり､積極的なDeploy検証がしやすくなる
- if分岐を記述せずに､stepに
environment: hogehogeを加えるだけでhogehoge環境のsecretへアクセスできる
課題１：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-providermy-service-account@{プロジェクトID}.iam.gserviceaccount.com
この２つは別にクレデンシャルでもなんでもないので､特権を持たないユーザがActionsに記述してしまうと､かんたんにProduction環境アクセスできてしまう
→折角Environmentで保護したのに､意図的にアクセスできてしまう｡
対策
Google側でカスタムトークンの属性を指定できるので､
- リポジトリ(repo)
- ワークフロー(workflow)
- ブランチ(ref)
- 実行ユーザ(actor)
などを指定して縛る
ref == ref/heads/main
workflow == MyWorkflow
とか指定してみると､セキュアになる
課題２：Github Actions Environment でTerraform Planしづらい
Environmentを導入することで､mainブランチ以外はProduction Secretにアクセスできなくなってしまう｡
Plan用のEnvironmentを追加してやればいいのですが､実際に付与する権限が難しい｡
IAMをViewer権限でざっくり付与してやるだけではうまくいかず､一部サービスに対してはWrite権限が必要｡
でも､そうなると､インフラの操作もできてしまったり､､､答えは､､､なし､､､