🐅

pull_request_targetでのActions改ざん防止など:Productivity Weekly (2023-10-25号)

2023/11/06に公開

こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。

僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。

2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2023-10-25 単独号です。

今回が第 130 回目です。過去の記事はこちら

news 📺

Actions - Prevent self-reviews for secure deployments across Actions environments - The GitHub Blog

https://github.blog/changelog/2023-10-16-actions-prevent-self-reviews-for-secure-deployments-across-actions-environments/

GitHub Actions は environment へのデプロイに対してレビューを必要とする設定が以前から可能でした。レビュワーには個人やチームを設定可能で、実はジョブをトリガーした本人がレビュワーに含まれていた場合はセルフレビューで通すことも可能だったのですが、今回それを禁止するオプションが追加されました。

デプロイ実行時に必ず本人とは別人による確認が必要と考える場合には、今回追加された Prevent self-review のオプションを追加すると良いでしょう。

本項の執筆者: @Kesin11

Rate limits for /rate_limit REST API endpoint - The GitHub Blog

https://github.blog/changelog/2023-10-18-rate-limits-for-rate_limit-rest-api-endpoint/

GitHub において、API のレートリミットを確認するための GET /rate_limit エンドポイントがレートリミットの対象になりました。これまでは GET /rate_limit はレートリミットの対象外でした。

GitHub のレートリミットにはプライマリとセカンダリの二種類があります。今回 GET /rate_limit がレートリミットの対象となるのはセカンダリレートリミットになります。プライマリレートリミットの制限は引き続きありません。

この変更の目的は悪用されるパターンを防ぐためとのことです。GET /rate_limit をめちゃくちゃ呼び出して GitHub API に負荷をかけるようなことをされたんですかね?(想像)

今回の変更で GET /rate_limit はセカンダリレートリミットの制限がかかるようになりましたが、常識的な使い方をしている人々には影響しないと思います。不安な方は Best practices for using the REST API に則れているか確認しましょう。

本項の執筆者: @korosuke613

Rotate Your SSL/TLS Certificates Now – Amazon RDS and Amazon Aurora Expire in 2024 | AWS News Blog

https://aws.amazon.com/jp/blogs/aws/rotate-your-ssl-tls-certificates-now-amazon-rds-and-amazon-aurora-expire-in-2024/

Amazon RDS の SSL/TLS 証明書更新に関する通知です。

DB インスタンス用 SSL/TLS 証明書(rds-ca-2019)は、2020 年の証明書更新後、2024 年に失効されます。
これは、Amazon RDS for MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, および Amazon Aurora のデータベースインスタンスに SSL または TLS で証明書検証を用いて接続するユーザーに影響します。
そこで、2022 年 12 月にリリースされた、40 年間有効(rds-ca-rsa2048-g1)と 100 年間有効(rds-ca-rsa4096-g1, rds-ca-ec384-g1)の証明書に更新することを推奨しています。

具体的な失効期限はリージョンごとに異なるので確認しておきましょう。

本項の執筆者: @r4mimu

know-how 🎓

pull_request_target で GitHub Actions の改竄を防ぐ

https://zenn.dev/shunsuke_suzuki/articles/secure-github-actions-by-pull-request-target

pull_request_target イベントを用いて、仮に workflow ファイルへの悪意ある変更を含むプルリクエストが送られたとしても、CI を安全に実行したいという記事。

プライベートリポジトリで複数人で開発している状況で、仮に bot、もしくは開発メンバーのアカウントが侵害されてしまった状況といったかなり高度なセキュリティを想定しているように感じられます。記事にもあるように、試しに検証した後に、Terraform のモノレポで terraform plan/apply をしているような強い権限を扱うリポジトリに対して検討すると良いでしょう。pull_request から pull_request_target に変更する流れに関しても実例を交えて丁寧に解説されています。

記事を書かれた Shunsuke Suzuki さんの GitHub Actions の Workflow の改変を防ぐ の記事も併せて読むと、便利な GitHub Actions を使いたい気持ちと、Terraform のモノレポのような強い権限を渡す CI をどうセキュアに実行するかという 2 点の両立は工夫しないと結構難しいのだろうと感じます。

本項の執筆者: @uta8a

Goの自動テスト高速化のための調査と改善手法 - Cluster Tech Blog

https://tech-blog.cluster.mu/entry/2023/10/19

CircleCI 上で回る Go の自動テストが 10 分ほどかかっていたのを 5 分ほどに改善する過程が書かれています。

CircleCI の TIMING タブを活用して実行時間の割合の大部分を占める make test ステップから順に対処していき、結果としてどのステップがどの程度短縮されたか書かれています。計測、改善の効果の評価、改善を加えるかどうか決定、という一連の流れが参考になります。

具体的には、以下のように Go のテストコードに直接手を加えず CI レベルでの改善を入れる方針でした。

  • go generate の生成物のコミットを行って CI の go generate を行う過程を省略する。
  • gotesplit を用いて CircleCI レベルでの並列化を入れる。

本項の執筆者: @uta8a

AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ

https://blog.engineer.adways.net/entry/2023/10/20/140000

IPA がまとめている関連する法令・ガイドラインを参考に、監査ログとアクセスログの保持期間を決め、AWS 上でログの保存と分析ができるように実装する流れが書かれています。

記事では以下のログを S3 に保管します。

  • AWS で取得できるログ(CloudTrail、VPC フローログ、ALB・NLB のアクセスログ)
  • OS のログ( /var/log/messages, /var/log/secure )
  • アプリケーションのログ(監査ログ、アクセスログ)

さらに、OS やアプリケーションのログを fluentbit を用いて S3 に転送する方法と、AWS で取得できるログを S3 へ保管するための設定について説明されています。
どういったログを残せばいいか、ログの保持期間をどう決めたらいいか悩むことがあれば参考にしていきましょう。

本項の執筆者: @uta8a

【書き起こし】社内用GitHub Actionsのセキュリティガイドラインを作成した話 – Toshiki Kawamura【Merpay & Mercoin Tech Fest 2023】 | メルカリエンジニアリング

https://engineering.mercari.com/blog/entry/20231023-mmtf2023-day2-11/

メルペイ・メルコインさんのカンファレンスを書き起こしたものがブログ記事として公開されていました。

発表内容はおそらくメルカリさんのブログ 社内用GitHub Actionsのセキュリティガイドラインを公開します に基づいたものだと思います。
こちらのブログ記事については、Productivity Weekly (2023-06-14号) で紹介しています。

ブログ記事との違いとして、ガイドラインの活用状況やガイドライン策定の裏話が共有されていました。
個人的に印象に残ったのは、ガイドライン策定における「気をつけた点」です。

  • 小さく始める、無理をしない
  • 絶対完成させるという強い意志を持つ
  • 適切な量のフィードバックをもらえるように意識する
  • 正式版を公開してから育てていく

という 4 点が紹介されていました。これらのポイントはガイドライン策定に限らず社内ツールや社内ルールを作る際などにも参考になる大事な考えかと思いました。

本項の執筆者: @r4mimu

Hatamoto 〜モバイルアプリに関する情報を一元管理するためのWebアプリケーション〜 - クックパッド開発者ブログ

https://techlife.cookpad.com/entry/hatamoto

iOS の開発時に必要な各種証明書の有効期限の管理と、アプリで使われているライブラリのバージョンを Web アプリケーションで一元管理するというノウハウの紹介記事です。

開発規模が小さいうちは証明書の期限管理はチームのカレンダーに登録するだけで十分だと思いますが、万が一見逃してしまった場合の影響範囲は大きいため、開発規模が大きい組織ではこのように一元管理して運用をなるべく自動化するメリットがあるのだろうと思います。

記事中で紹介されている Hatamoto という Web アプリケーションは公開されていないようですが、内部の仕組みは紹介されているので興味を持った方は似たようなツールを自前で作成するのも良いかもしれません。

本項の執筆者: @Kesin11

OpenTelemetryのここ4年の流れ / OpenTelemetry in last 4+ years - Speaker Deck

https://speakerdeck.com/ymotongpoo/opentelemetry-in-last-4-plus-years

10/19 に開催された OpenTelemetry Meetup 2023-10 で発表された内容のスライドです。

https://opentelemetry.connpass.com/event/296353/

OpenTelemetry は、分散トレーシング、メトリクス、ログ、プロファイルの計装とログの標準仕様および実装を提供するプロジェクトです。複数の領域を扱うプロジェクトであることから成り立ちが少々複雑なのですが、この発表では、OpenTelemetry の歴史と現在の状況、そして今後の展望について解説されているのでこの発表を見ることで大まかな状況を把握できると思います。

自分自身、OpenTelemetry を過去に調査した際に Jaeger, OpenTracing, OpenCensus などの様々な OSS やプロジェクト名が登場してきたので、どれがどのように関係していて今現在でも有効な話なのかどうかを整理するのに苦労した経験があります。これから OpenTelemetry について調べる予定がある方はまずこの発表で歴史と全体像を把握しておくと混乱せずに済むのでオススメです。

本項の執筆者: @Kesin11

【コードリーディング】Terraform が Core と Provider との間で RPC 通信するところを覗いてみた👀 - サーバーワークスエンジニアブログ

https://blog.serverworks.co.jp/2023/10/20/153424

サーバーワークスさんによる Terraform のコードリーディング記事です。コア部分とプロバイダ部分が行なっている gRPC による通信について、ソースコードを読んだまとめが書かれています。

どのようにサーバが構成されているか、どう起動されるか、どういう経路でメソッドが呼び出されるかなどがコードと共に説明されています。

僕はカスタムプロバイダを作ったことがなかったのですが、プロバイダ部分が gRPC のサーバ、コア部分が gRPC のクライアントという構成だったのですね。
こういうふうにプロバイダがどのように動くかをなんとなく知ることでカスタムプロバイダを作る心理的ハードルが下がって良いですね。
Terraform の中を知りたい方やカスタムプロバイダを作りたい方に参考になると思います。

本項の執筆者: @korosuke613

あとがき

今週号から @uta8a さんが共同著者として参加してくれました!嬉しいですね。
しかし、今年はめちゃ日本シリーズ見てたんですけど、阪神もオリックスも熱い戦いを繰り広げてくれてめちゃ面白かったですね。
タイガースは日本一おめでとうございます 🎉

ホークスは来年がんばろう!

サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック!
https://note.com/cybozu_dev/n/n1c1b44bf72f6

GitHubで編集を提案
サイボウズ 生産性向上チーム 💪

Discussion