0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

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

Last updated at Posted at 2022-07-17

読者対象

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権限が必要。
でも、そうなると、インフラの操作もできてしまったり、、、答えは、、、なし、、、

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?