見出し画像

GitHub Actionsの利用遍歴と認証情報管理の検討(電通デジタル自社開発部門 2021年版)

Dentsu Digital Tech Blog

電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。

本記事は電通デジタルアドベントカレンダー2021 8日目の記事になります。

本記事ではGitHub Actionsの利用遍歴と認証情報管理について、弊社の自社開発部門で検討した内容をご紹介させていただきます。

2021年末時点のGitHub Actionsパブリッククラウド認証情報管理ベストプラクティス

結論から書くと本記事執筆時点(2021年11月)では弊社が検討した内容は横に置いて、多くのケースで2021年10月末のGitHub社のイベントで公表されたGitHub Actions Open ID Connect(プレスリリース, ドキュメント)を利用するのがよいと思います。

公式から図を引用すると

GitHub Actions Open ID Connect Flow

  1. GitHub OIDC providerをID providerに指定したロールをクラウドインフラ側に作成する

  2. GitHub Actions側で前項で設定したロールの一時アクセストークン払い出しリクエストを実施する

  3. クラウドインフラ側の一時アクセストークン払い出しサービスが一時アクセストークンを返却する

  4. 一時アクセストークンを利用してGitHub Actionsでクラウドインフラに対する操作を実行する

というフローになっています。

これにより

  • クラウドインフラ側で認証情報を発行(してGitHub Secretsに保存)する必要がない

  • 取得する認証情報は短期間で無効になる

という状態になります。

強い権限を持つGitHubアカウントの乗っ取りなどの重度のセキュリティ問題には当然対応できませんが(そちらはMFAの有効化など、Enterpriseプランでの対応になるかと思います)、弊社のようにプライベートリポジトリのみの組織を利用しているケースであればかなりのユースケースを満たせると考えています。

以降が2020年からの弊社のGitHub Actions利用の歴史と検討した内容になります。

GitHub Actions利用遍歴と認証情報管理の検討

2020年：GitHub Actions導入黎明期

現バージョンのGitHub Actionsが公式リリースされたのが2019年末。2020年は利便性を高める機能追加や機能改善も多くあり、あれもこれも「GitHub Actionsでやりたい......」という気持ちがSREにとどまらず、開発チーム内で高まっていました。

最初に着手したのは3rd PartyのCIツール(CircleCI)からの乗り換えでした。切り替え前には以下の課題がありました。

  • プロダクトも増えてきてCall Rate Limitに引っかかるようになっていた。それに対応するためにCI起動の制御をしようとしていたが、それなりに面倒だった

  • (利点であり、後の罠になるのですが)開発サイドでも特にGitHub内の認証情報や権限設定がやりやすい

その後、社内のライブラリも対応している言語のものはGitHub Packagesで配布するようになったので、リリースパッケージの作成などもGitHub Actionsで実施するようになりました。

この時期はせいぜいGitHubの他リポジトリをチェックアウト(といっても対象がプライベートリポジトリなのでそこそこ権限が必要ですが)するためのGitHubのトークンくらいが認証情報でした。そのため牧歌的に便利なツールとして使っていた状態でした。

2021年年初：GitHub ActionsでBigQuery周りのプロビジョニングを実行

さて、年は変わって2021年。2020年末からデータ基盤のデータストアとデータパイプラインををBigQueryと一部Google Cloud Platform(以下GCP)に移行するプロジェクトを進めており、2021年年初には大量かつ、都度のプロビジョニングや更新作業が必要になりました。

移行の対向のサービスや担当者に対してSREの手数が絶対的に足りませんでした。とはいえ、移行の進捗に悪影響を及ぼすわけにはいきません。そこで、充分な検討や検証ができないものの暫定処置として認証情報 をGitHub Secretsに保存し、GitHubのPull Request(以下PR)ベースでプロビジョニングが行えるようにGitHub Actions Workflowを作成しました。

下図にプロビジョニングツールにTerraformを使った場合のフローを示します(説明の簡便化のため、多重実行の制御などは今回省略します)。

GCP Provisioning with GitHub Actions (GitHub Secrets ver.)

概要を説明すると以下の流れになります。

  • PRがオープンされたタイミングで、Terraformファイルの変更を検知して対象環境のWorkflowを起動 (図中1, 2)

  • terraform plan を実行し、結果をPRのコメントにPOST (図中3)

  • PRがマージされたタイミングで開発環境に terraform apply し、結果をPRのコメントにPOST(図中4, 5, 6)

  • 本番環境への反映はGitHubでリリースを作成ないしは手動で terraform apply し、結果をリリース管理チケットにPOST(図中7, 8, 9)

さらに各対向のサービスに対して申請を用意し、定型のものは申請にもとづいて特定の箇所に設定を追加すればよいだけのテンプレートを作りました。これによってSREが確認・対応しなければいけない箇所が減り、場合によってはSRE外にヘルプを求めることができるようになりました。

GCPに対してかなり強い権限を持つサービスアカウントの認証情報をGitHub Secretsに保存している点が懸念点として上がったのですが、こうでもしないと対応が間に合わなかったのでやむなしといったところです。

2021年上期：GitHub周りでのインシデントと対応方針の変更

GitHub Actoinsの利用が広まったからというわけではありませんが、2021年上期(1〜6月)にはフィッシングからのアカウントジャックや、GitHubと連携した3rd Partyツールの脆弱性によってGitHubに保存されたツール利用者の認証情報が悪用されるインシデントが報告されました。

これらを受けてか他社でも

のように直接GitHubに認証情報を保存しなくても済む対応の検討がされていました。

前項に記載した通り、暫定的なものとはいえプロビジョニング作業が可能な権限のある認証情報を保存していました。SREチーム内で相談した結果、アプリケーションのデプロイパイプラインと同様にプロビジョニングをクラウドインフラ内で行い、その結果をGitHubに連携して認証情報はクラウドインフラから外に出さない方式をとることにしました。

(AWSのアプリケーションデプロイについては去年のアドベントカレンダーの「ECS Fargate 楽々構築テンプレート」にアプリケーション構成やデプロイパイプラインをCloud Formationのサンプルを記載してありますので、そちらをご参照ください)

2021年下期：クラウドインフラ側でのプロビジョニングの仕組みの構築とGitHub Actions Open ID Connectの発表

AWSアプリケーションがGitHubの変更をトリガーにしてAWS内でCodePipeline/CodeBuildを使って実現していたので、それなりにできるかと思っていたのですが、以下の理由で意外に時間がかかってしまいました。

  • GitHub連携アプリケーション必要な方法が多い(コーポレート部門のGitHub Organization管理者との調整が必要)

  • AWS側は仕組みを作って2年程度経過していたので、サービスのアップデートで方式を変えた方がいいものが出てきていた(キャッチアップ不足)

その他諸々詰まったところはありながらも、どうにか形になりました。試験リポジトリからの展開を考えていると10月末にGitHub ActionsがOpen ID Connectに正式対応したと発表がありました。9月あたりから情報が出ていたのでリリースされることは認識していたのですが、正式リリースがこの時期になるとは思っていませんでした。

結果、クラウド環境側でのプロビジョニングシステムは作ったものの撤退方向。GCPで構築したPRベースのワークフローで認証情報管理部分をGitHub Actions Open ID Connectに差し替えて現在試験稼働中です。

前述したGCP+Terraformの場合、変更後は以下のフローになっています。GCPの場合はIAMのWorkload Identityサービスがサービスアカウントとのフェデレーションと一時認証情報の発行を担っています。

GCP Provisioning with GitHub Actions (GCP Workload Identity ver.)

試験稼働中なのは

  • 公式ドキュメントで紹介されているActionsやPluginがまだリリースから日が浅い(AWSはOpen ID Connect対応後のActionsの正式バージョンがなく、GCPはTerraformのプラグインがメジャーバージョンが上がっている)

  • 権限やスコープの適切な範囲を探っている

というのが理由です。

アプリケーションの方も同様にGitHub Actionsに載せたいという外部からのプレッシャーを感じますが(現在の仕組みだと定型から外れた箇所の柔軟性がそこまでないので)、そこはまだ手を出せずにいます。

おわりに

今回のGitHub Actionsの話はスケジュールに間に合わせるためにやや危険な判断をしたり、時流とあと一歩ずれていて余分に時間を使ってしまったりというトホホなエピソードではあります。

AWSアカウント シングルサインオン構成のご紹介(電通デジタル自社開発部門 2020年上期版)のときにも「これ以上何か対応しないので詳しくなくても大丈夫だろう」という気持ちで使っていたSimpleADもユーザ数が爆発的に増えてサイズアップのメンテナンスも実施しました。2021年の時点でADに登録したパスワードを変更せずにAWS利用者側でサイズ変更メンテナンスする方法がないなどSimpleADに詳しくなりました。

私の場合は予測の精度を上げる努力が必要なのかもしれないと思います。しかし、先のことは得てして予測できないものなので、そのタイミングで対応できるだけの能力を付けていくしかないのかもしれないなと思った1年でした。

文中でも手数の話をしましたが、電通デジタルでは変化し続ける自社開発システムを支えるSREを募集しています。社内システムがメインの仕事で特にインフラ・バックエンドは思い切った構成を取れるのがよいところだと思います。SREに興味がある方はご検討のほどよろしくお願いいたします。

みんなにも読んでほしいですか？

オススメした記事はフォロワーのタイムラインに表示されます！