先日2024/04/16にタイミーさんのオフィスで開催された、AWS知見共有会というイベントで発表してきました。この会のテーマは「運用のスケーラビリティとセキュリティ」ということで、私は「コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える」というタイトルで発表してきています。
イベントの動画もあります。
私の発表は 1:43 ぐらいからです。
この発表については資料と動画を見ていただければ！という感じで特に付け加えることもなかったのですが、イベントの開催後にGitHubから発表された新機能Push rulesがとても便利で、新たなベストプラクティスとなるインパクトがあると思ったので、この記事で紹介します。
Push rulesとは
つい昨日発表された機能で、現在はpublic betaという状態です。なので、仕様変更とかはあるかもしれません。
機能としては、git pushする際に、ファイルに関して以下の制約を設けられるという物です。
- fnmatch形式でのファイルパスの指定
- ファイル名の長さ
- ファイル拡張子
- ファイルサイズの大きさ
これらの条件に合致するものについて、pushをエラーにすることができます。
また、ルールはブランチに関係なく適用されるようです。
これらのルールを適用除外する対象として、Bypass listにOrganization adminやRepository adminといったRole、またはOrganization内のTeamを指定することができます。
GitHub Appも指定可能なので、RenovateにはActionのアップデートを許可させる、といったこともできます。
機能の詳細については、以下の記事とドキュメントを参照してください。
Push rulesのユースケース
今回の発表の文脈で考えられるユースケースとしては、「GitHub Actions Workflowの変更は管理者のみに許可する」です。
インフラへの破壊的権限を持つInfrastructure as CodeツールのためのCI/CDパイプラインにおいて、Workflowへの変更権限を社内とはいえ広く与えることは、セキュリティ上のリスクになり得ます。 (スライドの24ページを参照)
Push rulesとこれまでのやり方の関係性を考える
on: pull_request_target
on: pull_requestではなくon: pull_request_targetを使うことで、default branch上のレビュー済みのWorkflowから実行させない、というやり方です。
これを使うと、セキュリティ上のメリットは大きいものの、Workflowのデバッグが難しくなるという問題もあります。 (変更をマージしてからPull Requestを作り直して初めて動作確認できるため)
Push rulesでRepository adminにしかWorkflowを変更できないようにすれば、on: pull_request_targetは不要なのでは？と考えることもできるでしょう。
とはいえ、それでもやはり仮にRepository ownerのアカウントが攻撃者に奪取された場合、Repository ownerになりすましてWorkflowに攻撃ロジックを仕込むことは可能となってしまいます。
その場合もレビューを必須としておくことでリスクは低減できるので、これを許容するかどうかは、組織の状況や管理している対象・Workflowに持たせている権限などによって変わってくるでしょう。
Push rulesを利用したとしても、想定されるリスクに基づいて多層的な防御戦略を検討することが必要です。
