セキュリティ基盤ブループリントの自動化リポジトリの使用方法

※この投稿は米国時間 2021 年 11 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

読者の皆様の中には、セキュリティ基盤のブループリントを取り上げた以前のブログ投稿をすでに読み、セキュリティ基盤ガイドに目を通した方もおられることと思います。そのような方は次にこう問いかけるでしょう。「これらのブループリントを Google Cloud インフラストラクチャに活用し、セキュリティに焦点を合わせたベスト プラクティスの恩恵を受けるにはどうすればよいか？」

幸いにも、セキュリティ基盤ブループリントの 2 つ目の部分は Terraform 自動化リポジトリです。そこでは、このガイドで説明されているベスト プラクティスのキュレートされた安全な実装が Terraform コードの形で提供されています。このブログでは、皆様がこのリポジトリを最大限に活用できるように、Terraform コードとその使い方、およびこれらのコードによって作成されるインフラストラクチャに習熟するための追加のガイダンスを提供します。

詳しい説明に進む前に

自動化リポジトリの使い方を説明する前に、Terraform について簡単に説明します。Terraform は、クラウド上のリソースを管理するための代表的なオープンソースの Infrastructure as Code（IaC）ソリューションです。Terraform は Google Cloud API を使用して、仮想マシン、VPC、ロードバランサ、IAM ポリシーなどのありとあらゆるタイプの Google Cloud リソースを作成、更新、構成します。Infrastructure as Code アプローチの利点は、インフラストラクチャをコードとして扱うことができ、バージョン管理とコードレビューも可能であるという点です。

この自動化リポジトリを最初から最後まで使用するには、Terraform の基本的な理解に加えて、Google Cloud 組織と Google Cloud 請求先アカウントをセットアップすることも必要です。IAM 権限については、Terraform をステップ 0 から実行するユーザーには、組織リソースに対する次の IAM ロールが付与されている必要があります。

• roles/resourcemanager.projectCreator

• roles/resourcemanager.organizationAdmin

• roles/billing.admin

• roles/resourcemanager.folderCreator

最後に、この Terraform コードが基本的に何を作成するのかを思い出すため、セキュリティ基盤ガイドのパート II のセクション 3 と 4 を読み返してください。設計上の決定事項や Terraform 自動化リポジトリのコードについて不明な点があるときは、このガイドを必ず参照してください。

サンプル基盤の内容

ディレクトリと重要なファイル

Terraform 自動化リポジトリ（またはサンプル基盤）は、Google Cloud セキュリティ基盤ガイドに準拠する方法を示す体系化されたデモンストレーションであり、デプロイ可能なランディング ゾーン インスタンスです。事前構成済みの Terraform リソースが 6 つのレイヤに整理されており、これらのレイヤが 1 つずつ順に作成されます。このリポジトリのルートには連番が振られたディレクトリがあり、各ディレクトリがそれぞれ 1 つのレイヤを表します。各ディレクトリには、個々の Terraform 構成と、それに対応する固有の状態ファイルが含まれています。

番号 1～5 のディレクトリに含まれる Terraform コードは、それぞれ固有の Google Source リポジトリにコピーされます。そこから、Cloud Build または任意の CI / CD パイプラインを使用して Terraform 構成をデプロイできます。0-bootstrap はそのパイプライン（Google Source リポジトリを含む）をデプロイするものなので、このディレクトリだけは手動でデプロイします。   

これらの番号付きディレクトリのほかに、build ディレクトリと policy-library ディレクトリがあります。これらには、デプロイの各段階で Terraform コードの検証に使用される Cloud Build 構成ファイルとポリシーが含まれています。これらのディレクトリ内のファイルは、サンプル基盤全体を通して Google Source リポジトリにコピーされます。  

リポジトリのルート ディレクトリにある ERRATA.md ファイルについても説明しておきます。このファイルには、サンプル基盤のランディング ゾーン インスタンスと基盤ガイドの間の差分が記載されており、将来のリリースでこれらの差分が変更されるかどうかを示しています。

Cloud Foundation Toolkit モジュール

サンプル基盤レイヤで使用されている Terraform コードを見ると、スタンドアロンのリソースに加えて Terraform モジュールもあることがわかります。これらの Terraform モジュールのソースは Cloud Foundation Toolkit（CFT）です。CFT の目標は、コードで実装されたベスト プラクティスによって Google Cloud Platform コンポーネントの共通のベースライン ライブラリを提供することです。これらのモジュールはセキュリティ基盤ブループリントを念頭に置いて作成されており、リソースとデフォルト値のキュレートされた安全な組み合わせを提供します。これによって作成される追加の抽象レベルは、サンプル基盤の各レイヤを単純化し、インフラストラクチャ デプロイメント全体の整合性を保ちます。  

たとえば、プロジェクトの作成が必要な場合は常に、プロジェクト ファクトリ モジュールが使用されます。このモジュールは、単にプロジェクトをプロビジョニングするだけでなく、API の有効化、デフォルト サービス アカウントの無効化、最小権限 IAM ポリシーの構成などのセキュリティ基盤ブループリントに準拠したプロジェクト関連リソースの構成も行います。CFT モジュールの詳細なリストについては、こちらをご覧ください。このページに示す各モジュールは、それぞれの対応する Git リポジトリにリンクされています。各リポジトリは Terraform レジストリから直接取り込まれるので、フォークまたはクローンを作成する必要はありません。これらは、次のように Terraform レジストリのパスとバージョン番号を含むモジュール ブロックで参照されています。

ご使用のインフラストラクチャをビジネス ユースケースに合わせてカスタマイズするためにサンプル基盤ランディング ゾーンを超えて拡張および増強する際も、引き続き CFT モジュールを使用することをおすすめします。

覚えておくべきこと

サンプル基盤に目を通すと、いくつかのプロジェクトやフォルダにわたって数多くのリソースが含まれていることがわかります。作業を進める際は、各レイヤのディレクトリにある README.md ファイルに注意を払ってください。このファイルには、Cloud Build またはその代用の Jenkins を使用してインフラストラクチャをデプロイするためのステップごとの指示が記載されています。Terraform コードを見るときは、各 CFT モジュールのソースとドキュメントを読み、セキュリティ基盤ガイドで背景情報を読み返すことをおすすめします。そうすると、コードの適用後に作成されるリソースをより深く理解できます。また、モジュールの使い方にも習熟するため、後でリソースをデプロイしてサンプル基盤を拡張またはカスタマイズするときにモジュールを利用できるようになります。各 CFT モジュールの対応するリポジトリに加えて、Terraform Registry ウェブサイトにそれぞれのモジュールのドキュメントや使用情報も掲載されています。  

基盤コードの実装に関して問題が生じた場合は、サンプル基盤リポジトリの docs ディレクトリにある FAQ.md ファイルと TROUBLESHOOTING.md ファイルを参照してください。これらのファイルは定期的に更新され、トラブルシューティングのヒントやよくある問題に関する情報が追加されます。  

レイヤについて

ブートストラップ ステップでは、bootstrap モジュールとその cloudbuild サブモジュールを使用して、組織に必要なリソースと権限、および Cloud Build CI / CD パイプラインに関連するリソースを作成します。その中でも特に、ブートストラップ ステップでは次のものがプロビジョニングされます。

• 請求および組織管理者とプロジェクト作成者に関する組織全体の IAM ポリシー バインディング

• シードと CI / CD プロジェクトを含む組織用のブートストラップ フォルダ

• シード プロジェクトと Terraform 関連リソース（Terraform サービス アカウント、関連する IAM ポリシー、状態ファイル用の Google Cloud Storage バケットなど）

• Cloud Build パイプラインとインフラストラクチャの各レイヤ用の Google Source リポジトリを含む CI / CD プロジェクト

ブートストラップ ステップは、前述の IAM 権限を持つユーザーが行います。このステップより後の Terraform コードはすべて、Cloud Build と Terraform サービス アカウントを通じて自動的に実行されます。一般に、残りの各ステップでは以下のことを行います。

1. そのレイヤに対応する空のリポジトリのクローンをローカルの作業ディレクトリに作成します（gcp-environments、gcp-networks、gcp-org、gcp-project）。これらは、ブートストラップ ステップで cloudbuild bootstrap モジュールによって作成されたものです。  

2. 新しいブランチで、README.md で指定されたすべてのファイルをサンプル基盤から空のリポジトリにコピーします。

3. ファイルと変数を編集します。これらも README.md ファイルに記載されています。

4. ブランチで加えた変更を commit し、リポジトリに push します。

ここで自動化のマジックが起こります。このマジックの正体は、Cloud Build ブートストラップで作成されたトリガーです。これらのトリガーは、CI / CD プロジェクトの Cloud Build トリガーページで確認できます。名前が「development」、「production」、「non-production」以外のブランチに push すると、作成または変更されるリソースのプレビューを提供する terraform plan コマンドがトリガーされます。さらに、terraform-validator を使用して Terraform コードが検証されます。このツールは、制約違反をチェックして警告を出し、無効なデプロイメントが本番環境に到達するのを防ぎます。制約は、policy-library ディレクトリ内のファイルで定義されています。

ビルドが成功すると、プランが出力され、Terraform コードが有効であることが証明されます。変更内容を環境の間で昇格させるには、まず「development」ブランチに結合し、次に「non-production」ブランチに結合して、最後に「production」ブランチに結合します。これらのブランチのいずれかに結合すると、terraform plan と terraform-validator に加えて terraform apply もトリガーされます。  

次のステップ

インフラストラクチャの各レイヤを理解することで、その後リソースをどこにプロビジョニングすればよいかがわかります。組織のビジネス ユニットで新しいサービスをリリースする準備ができたら、gcp-networks リポジトリにネットワーキング リソースを追加できます。そのサービスに関連する新しいテナント プロジェクトは、gcp-projects リポジトリにプロビジョニングできます。次に、app-infra パイプラインを使用して、そのサービスのホスティングに必要な新しいリソースをそれらのプロジェクトにプロビジョニングします。また、Google Cloud の今後も拡大を続ける他のキュレートされたセキュリティ ブループリントのポートフォリオ（AI Notebook の機密データの保護ブループリントやその他のワークロード セキュリティ体制ブループリントなど）を利用することもできます。これらのブループリントはすべて、この基盤のランディング ゾーンとの適合性と相互運用性についてテスト済みです。さらに、必要に応じて CFT モジュールも使用できます。たとえば、対応する Terraform のベアリソースの代わりに、プロジェクトに対してプロジェクト ファクトリ モジュールを使用し、コンピューティング インスタンスに対して VM モジュールを使用します。  

基盤ガイドに基づいて構築するクラウド インフラストラクチャは、インフラストラクチャの基盤となるランディング ゾーンにすぎません。このランディング ゾーンを実装した後、引き続きインフラストラクチャを必要に応じて増強してください。ただし、ここで重要となるのは、継続的に実践するセキュリティ プラクティスを検討することです。セキュリティ基盤ガイドが、サンプル基盤リポジトリの Terraform コードとその大部分を構成する CFT モジュールの基礎であるのと同様に、このセキュリティ プラクティスは、これらのベスト プラクティスを維持しながらインフラストラクチャとクラウド リソースを拡張していくための基礎となります。これには、これらのベスト プラクティスをコードで適用するプロセス、パイプライン、テストを設計することが含まれます。最も重要なのは強固な基盤を築くことであり、幸いにも、このサンプル基盤のおかげで初期に必要な重労働は大幅に軽減されます。

- Cloud デベロッパー アドボケイト Roger Martinez