開発チームと運用チームの一貫したワークフローを構築する方法

GitHubが最近発表した「2022 State of the Octoverse」レポートにおいて、HashiCorp Configuration Language（HCL）がGitHubで最も成長したプログラミング言語となりました。HashiCorpは、クラウドコンピューティングのためのInfrastructure as Code (IaC) 自動化のリーディングプロバイダーです。HCLは、Terraformや Vaultなどのツールと共に使用されるHashiCorpの設定言語で、マルチクラウドやオンプレミス環境において、人間が読みやすい設定ファイルでIaC機能を提供することができます。 HCLの成長は、インフラ、運用、開発者の世界を一つにすることの重要性を示しています。これは常にDevOpsの目標でした。しかし、現実には、多くの企業でこれらの世界がサイロ化したままになっています。この記事では、開発チームと運用チーム、そしてセキュリティ、ガバナンス、ネットワーク・チームを結びつけるビジネスと文化の影響について見ていきます。そして、GitHubとHashiCorpがCI/CDパイプライン全体を通して一貫したワークフローとガードレールをどのように実現できるかを探ります。従来の運用（Ops）の世界 HashiCorpの共同創業者であるArmon Dadgar氏は、従来のOpsの世界を「木」に例えて説明しています。トランクには、物事を成し遂げるために企業で必要な、共有され一貫性のあるサービスがすべて含まれています。セキュリティ要件、Active Directory、ネットワーク構成などを考えてみてください。ブランチは、企業内のさまざまなビジネスラインを表し、社内または社外にサービスや製品を提供します。葉は、ソフトウェアやサービスが展開されるさまざまな環境と技術を表します。クラウド、オンプレミス、コンテナ環境などです。多くの企業では、これらの異なるビジネス領域間のコミュニケーション・チャネルやプロセスが煩雑で、コストがかかる場合があります。インフラやアーキテクチャに大きな変更があった場合、通常、複数のチケットが複数のチームに提出され、企業内のさまざまな部署でレビューと承認が行われます。組織を保護するために、変更諮問委員会が一般的に使用されます。通常、文書化が完了しない限り、変更を進めることはできません。一般的に、将来の監査に必要な一連のガバナンスログと監査可能な成果物が存在します。もし、チームが最適化された自動化されたワークフローを持ち、それを使って納期を早め、安全なガードレールのセットで仕事を終わらせることができるようになったら、企業にとってより有益ではないでしょうか？これは、時間とコストの大幅な節約につながり、ビジネス価値の向上につながる可能性があります。最近のForresterのレポートでは、GitHubを使うことで3年間で433%のROIを達成したという結果が出ています。もちろん、時間の節約や効率の向上は言うまでもなく、一貫性と作業の合理化によってもたらされるその他の質的なメリットもあります。あなたの製品やサービスは、遅々として進まない、手作業でエラーが起こりやすいプロセスではなく、セキュリティとガバナンスが組み込まれた最適化された経路でデプロイされることになるでしょう。これこそ、DevOps、GitOps、Cloud Nativeの夢ではないでしょうか？ IaCの導入別の例えを使いましょう。IaCは、ソフトウェアやサービスをホストするリソース（サーバー、データベース、ネットワークコンポーネント、PaaSサービスなど）の設計図だと考えてください。病院と学校を設計する場合、両シナリオで同じ全体的な設計図を使用することはないでしょう。なぜなら、両シナリオはまったく異なる目的を持ち、要件も大きく異なるからです。しかし、2つの設計にまたがって再利用できる構成要素や基礎があるはずです。 HCLのようなIaCソリューションでは、ソフトウェア開発でメソッド、モジュール、パッケージライブラリを再利用するのと同様に、これらのビルディングブロックを定義して再利用することができます。IaCであるため、アプリケーションでコラボレーションやデプロイを行う際に使用するのと同じ推奨プラクティスをインフラに採用することができます。結局のところ、DevOpsの方法論を採用するチームは、生産性、クラウド対応のスケーラビリティ、コラボレーション、およびセキュリティが向上することが分かっているのです。より良いデリバリー方法このような背景から、インフラストラクチャをコード化することで得られる具体的なメリットと、それが従来の運用文化の変革にどのように役立つかを探ってみましょう。リポジトリにコードを保存するまずは、最も低いところにある果実から始めましょう。IaCであれば、GitHubなどのソースコード・リポジトリにインフラストラクチャやアーキテクチャ・パターンを保存することができます。これにより、完全なバージョン履歴を持つ単一のソース・オブ・トゥルースを手に入れることができる。これにより、必要に応じて変更をロールバックしたり、履歴から特定のバージョンの真実をデプロイしたりすることが容易にできるようになります。企業内のチームは、Git リポジトリ内の個別のブランチでコラボレーションを行うことができます。ブランチを使うことで、チームや個人は「自分のスペース」で生産的になり、「本番」の真実のソース（通常はメインブランチ）から離れて、他のチームの進行中の作業に悪影響を与えることを心配する必要がなくなります。前節で述べた再利用可能なビルディングブロックであるTerraformモジュールも、Gitリポジトリに保存されバージョン管理されています。そこからTerraform Cloudのプライベートレジストリにインポートすることで、全チームが簡単にモジュールを発見できるようになります。GitHubで新しいリリースバージョンのタグが付けられると、レジストリにも自動的に更新されます。早期かつ頻繁にコラボレーションする上で説明したように、チームは現在の状態に影響を与えないように、別々のブランチで変更を加えることができます。しかし、その変更を本番環境のコードベースに反映させたい場合はどうすればいいのでしょうか。もしあなたが Git に慣れていないのなら、プルリクエストという言葉を聞いたことがないかもしれません。その名のとおり、あるブランチから別のブランチに変更を「引き込む」ことができます。 GitHub のプルリクエストは、チーム内の他のユーザーとコラボレーションするためのすばらしい方法です。ピアレビューを受けることで、フィードバックを自分の作業に反映させることができます。プルリクエストのプロセスは、チーム全体のコラボレーションを促進するために意図的に非常にソーシャルになっています。 GitHub では、ブランチ保護ルールを設定してメインブランチへの直接の変更を不可とすることもできます。そうすれば、すべてのユーザーがコードを実運用に移すにはプルリクエストを経由しなければならなくなります。ブランチ保護ルールには、最低限必要なレビュアーの人数を指定することもできます。ヒント:GitHub のCODEOWNERS ファイルという特殊なファイルを使えば、編集中のファイルに基づいてプルリクエストにレビュアーを自動的に追加することができます。例えば、すべてのHCLファイルは、コアインフラストラクチャチームによるレビューが必要かもしれません。あるいは、勘定系システムのIaC設定には、コンプライアンスチームによるレビューが必要かもしれません。通常、特定の周期で行われる変更諮問委員会とは異なり、プルリクエストはコードを本番環境に導入するためのプロセスの自然な一部となります。また、意思決定や議論の質も向上します。外部システムで推奨される「イエス/ノー」の決定ではなく、プルリクエストで直接コンテキストと推奨を確認することができます。プロビジョニングプロセスではコラボレーションも重要です。GitHubとTerraform Cloudの統合により、これらのプロセスを複数のチーム間でスケールさせることができます。Terraform Cloud は Terraform の状態を安全に保存し、GitHub リポジトリと直接統合することで、プルリクエストとマージのライフサイクルをターンキーで体験できるようなワークフロー機能を提供します。自動化された品質レビューをプロセスに取り入れる前節の続きですが、プルリクエストでは、提案された変更の品質を自動的にチェックすることもできます。ソフトウェアでは、アプリケーションが正しくコンパイルされているか、ユニットテストは合格しているか、セキュリティの脆弱性はないかなどをチェックするのが一般的です。 IaCの観点からは、同様の自動チェックを我々のプロセスに取り入れることができます。GitHub のステータスチェックを使えば、特定の条件を満たしているかどうかを明確に把握することができます。 GitHub Actions は、GitHub のプルリクエストでこうした自動チェックを実行するためによく使われるものです。IaCの品質を判断するために、以下のようなチェックを入れることができます。コードが構文的に正しいかどうかを検証する（例えばTerraform validate）。コードが特定の標準に従っていることを確認するためのLinting（例えば、TFLintや Terraform format）。静的コード解析により、「設計時」にインフラストラクチャの設定ミスを特定します (たとえば、tfsecやterrascan など)。関連するユニットテストまたは統合テスト（Terratest などのツールを使用）。インフラストラクチャを「スモークテスト」環境にデプロイし、インフラストラクチャの構成が（既知のパラメータセットと共に）望ましい状態にデプロイされることを検証します。 Terraform on GitHubを使い始めるのは簡単です。TerraformのバージョンはLinuxベースのGitHubでホストされたランナーにインストールされていますし、HashiCorpには公式のGitHub Actionがあり、指定したTerraformバージョンを使ってランナーにTerraformをセットアップしてくれます。

すべての公開リポジトリでシークレットスキャンアラートが無料で利用可能になりました！

Published at February 28, 2023
Category: Open Source,Security,Secret Scanning
Author: Zain Malik

Summary

GitHubのシークレットスキャンは現在、すべての公開リポジトリを対象に無料で提供されており、ユーザーが数千件の流出シークレットを発見し、トリアージするのに役立っています。

シークレットスキャンアラートが、すべての公開リポジトリで一般に利用できるようになりました。管理者はワンクリックでアラート体験をオンにできるようになりました。

12月、私たちは公開リポジトリ全体で無料の秘密スキャンアラートを提供するパブリックベータを発表しました。リリース以来、7万ものパブリックリポジトリがシークレットスキャンアラートを有効にし、あなたのようなユーザーが何千もの流出した秘密をトリアージするのに役立っています。

本日より、GitHubのシークレットスキャンのアラート機能は、すべてのパブリックリポジトリで無料でご利用いただけるようになりました。所有するすべてのリポジトリでシークレットスキャンのアラートを有効にすると、コード、課題、説明、コメントなどリポジトリの全履歴にわたって流出した秘密を通知することができます。

GitHubの秘密スキャンは、GitHubパートナープログラムに参加している100社以上のサービスプロバイダーと連携しています。ユーザーへのアラートに加え、パートナーの秘密が流出した際にも引き続き通知します。しかし、シークレットスキャンアラートを有効にすると、パートナーに通知することができないシークレット（例えば、セルフホスティングのキーが公開された場合）についても、アラートに対するアクションの完全な監査ログと一緒にアラートを受け取ることができるようになりました。

これにより、大規模なリスクを完全に可視化することができます。DevOpsコンサルタント兼トレーナーの@rajbosは、約14,000のリポジトリで秘密スキャンを有効にし、1,000以上の秘密を発見しました。Rob は次のように述べています。「私の調査は、誰もが秘密スキャンを有効にすべき理由を証明しています。私は14,000の公開GitHub Actionリポジトリを調査し、その中から1,000以上の秘密を発見しました！" と述べています。

"GitHub Advanced Securityの使い方について多くの人にトレーニングしているにもかかわらず、私はこれを通じて自分のリポジトリに秘密を発見してしまいました。"

複数年の経験があるにもかかわらず、自分自身にも起こることです。それくらい、間違ってシークレットを入れてしまうことは簡単なことなのです。

"シークレットスキャンを有効にすると、シークレットが通知され、パートナーはすでにそれを自動的に取り消すことができるので、コードの世界をもう少し安全にすることができます。"Robの体験談は、彼のブログ記事でお読みください。

ワンクリックで開始

公開リポジトリの所有者または管理者であれば、誰でも秘密スキャンアラートを有効にすることができます。企業管理者と組織の所有者は、複数のリポジトリに対して一括してアラートを有効にすることもできます。これを行うには、「設定」タブに移動し、「セキュリティ」の「コードセキュリティと分析」をクリックします。Secret scanning」を見つけて、「Enable」をクリックします。

Gif demonstrating how to enable secret scanning on the "Settings" menu under the section labeled "Security."

リポジトリに対してシークレットスキャンの警告を有効にする方法については、ドキュメントで詳しく説明しています。

GitHub のシークレットスキャンパートナーになる

もしあなたがサービスプロバイダーで、共有ユーザーを秘密の漏洩から守ることに興味があるなら、秘密スキャンパートナープログラムに参加することをおすすめします。現在、200以上のパターンと100以上のパートナーをサポートしています。まずは、secret-scanning@github.com までメールをお送りください。

Source

Secret scanning alerts are now available (and free) for all public repositories

In December, we announced the public beta for free secret scanning alerts across public repositories . Since its release, 70 thousand public repositories have turned on secret scanning alerts, helping users like you to triage thousands of leaked secrets. As of today, GitHub secret scanning’s alert …

GitHub Blog | 非公式日本語