読者対象
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へアクセスできる
課題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
この2つは別にクレデンシャルでもなんでもないので、特権を持たないユーザがActionsに記述してしまうと、かんたんにProduction環境アクセスできてしまう
→折角Environmentで保護したのに、意図的にアクセスできてしまう。
対策
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権限が必要。
でも、そうなると、インフラの操作もできてしまったり、、、答えは、、、なし、、、