Trusted Cloudに初めてオンボーディングすると、空の新しい組織が提供されます。この組織を使用するには、プロジェクト、ネットワーク、その他のリソースを使用して構成する必要があります。 Trusted Cloudには、組織の構成に複数のオプションが用意されています。たとえば、Terraform モジュールを使用すると、ユーザーが利用を開始するために必要なリソースをすばやく設定できます。
このページは、 Trusted Cloudで新しい組織を構成する必要がある管理者を対象としています。
このガイドを読む前に、次のことを確認してください。
Trusted Cloudの概要で説明されている基本的なコンセプトを理解する。 Trusted Cloud
組織、フォルダ、プロジェクトなど Trusted Cloud のリソース階層を理解する。
Trusted Cloudでの Virtual Private Cloud(VPC)のしくみを確認する。
次の Trusted Cloudプロダクトとサービス、およびそれらの用途を理解する。
Terraform を使用して組織を構成する場合は、Terraform のしくみを理解する。
Google Cloud の同様の設定に精通している場合は、 Trusted Cloud と Google Cloud の違いを確認することをおすすめします。
始める前に
すべての設定オプションで次の点を確認します。
- 組織に ID プロバイダ(IdP)が構成されているおり、管理者 ID でログインできる。
- Trusted Cloudで使用するために Google Cloud CLI を設定してある。Terraform を使用して設定する場合でも、Google Cloud CLI は、コマンドラインから設定を確認したり、追加の管理タスクを実行したりする場合に便利です。
また、企業向けの完全な構成を行う前に、Trusted Cloud by S3NS の設定のガイド付きフローを確認することを強くおすすめします。すべてのセクションがTrusted Cloudに関連しているわけではありません(たとえば、組織を自分で作成することはできません)が、インフラストラクチャの設定に役立つ背景情報、ガイダンス、ベスト プラクティスが記載されています。提供される Terraform モジュールにも同じベスト プラクティスが反映されています。ガイド付きフローを進める際は、 Trusted Cloudでは Trusted Cloud コンソールで企業向けの構成は使用できないことに注意してください。
構成オプション
Trusted Cloudで企業組織を設定するには、次の 3 つの方法があります。
- (推奨)提供さいる Terraform モジュールを使用して組織を設定する。これは、企業に対応する組織を設定する際のベスト プラクティスに沿って、Google Cloud の Cloud の基盤構成を変更したものです。
- (上級ユーザーのみ)Google Cloud で使用した既存の Terraform ランディング ゾーン モジュールがある場合は、それらをベースにして再利用し、 Trusted Cloudで組織を構成できます。このオプションを選択する場合は、2 つのユニバースの違いを、概要レベルと使用するサービスについて慎重に確認する必要があります。
- プロジェクト、ネットワーク、ポリシーなどのリソースは、Google Cloud CLI または Trusted Cloud コンソールを使用して、関連するドキュメントの手順で手動で作成できます。次のセクションで説明する最小限の構成や、Google が推奨する構成または独自のバージョンを使用して、このアプローチを完全な企業向けの設定に使用できます。
最小限の構成
新しい組織を完全に設定する前に試すだけの場合は、1 つのプロジェクトと Virtual Private Cloud(VPC)ネットワークを追加できます。この基本的なデプロイは、利用可能なサービスを確認してクイックスタート チュートリアルを実行するのに十分です。
- 組織にプロジェクトを作成します。
次のコマンドを使用して、プロジェクトに
default
という VPC ネットワークを作成して構成します。gcloud compute networks create default gcloud compute firewall-rules create default-allow-internal --allow=tcp:1-65535,udp:1-65535,icmp --source-ranges 10.128.0.0/9 gcloud compute firewall-rules create default-allow-ssh --allow=tcp:22 gcloud compute firewall-rules create default-allow-rdp --allow=tcp:3389 gcloud compute firewall-rules create default-allow-icmp --allow=icmp
デフォルト ネットワークがない
Google Cloud に精通している場合、ネットワークの作成は必要ないと思われるかもしれませんが、Google Cloud ではプロジェクトごとにデフォルトの VPC ネットワーク(事前設定された IPV4 ファイアウォール ルールを含む)が自動的に作成されます。ただし、 Trusted Cloudプロジェクトにはデフォルト ネットワークがありません。そのため、自分とチームメンバーが使用できるように自分で作成する必要があります。
推奨構成
提供される Terraform でデプロイされる構成は次のとおりです。これは、Google Cloud の Cloud の基盤構成を変更したものです。 Trusted Cloud コンソールまたは Google Cloud CLI を使用して独自のリソースとポリシーを手動で作成する場合は、このセクションをガイドラインとして使用することもできます。
この構成は、ほとんどの組織で機能することが判明した多くのベスト プラクティスを表していますが、組織または技術的な要件をすべて満たすとは限りません。このセクション(および使用している場合は Terraform 自体)をよく確認し、必要に応じて構成をカスタマイズしてください。
以降のセクションでは、推奨構成のさまざまなリソースについて説明します。
組織
組織の最上位レベルでは、推奨される構成に 2 つのフォルダがあります。最初のフォルダには、組織で共有する Cloud KMS リソースや Logging リソースといった共通リソースを含むプロジェクトがあります。もう一つのフォルダは、組織の Cloud DNS ハブや、各環境(開発環境、非本番環境、本番環境)のベース ネットワークと制限付きネットワークの共有 VPC ホスト プロジェクトなど、ネットワーク関連のプロジェクトを保存するために使用されます。
example-organization
└── fldr-common
├── s3ns:prj-c-kms
├── s3ns:prj-c-logging
└── fldr-network
├── s3ns:prj-net-dns
├── s3ns:prj-d-shared-base
├── s3ns:prj-d-shared-restricted
├── s3ns:prj-n-shared-base
├── s3ns:prj-n-shared-restricted
├── s3ns:prj-p-shared-base
└── s3ns:prj-p-shared-restricted
環境
推奨される構成では、本番環境、非本番環境、ステージング環境の環境ごとにフォルダがあります。各フォルダには、この環境に固有の鍵管理リソースに Cloud KMS で使用できるプロジェクトが含まれています。
example-organization
└── fldr-development
├── s3ns:prj-d-kms
└── fldr-nonproduction
├── s3ns:prj-n-kms
└── fldr-production
├── s3ns:prj-p-kms
ネットワーク トポロジ
この構成では、環境(開発環境、非本番環境、本番環境)ごとに共有 VPC ネットワークが標準構成で構成され、適切なセキュリティ ベースラインが設定されています。この構成には、次のものが含まれます。
- (省略可)セカンダリ範囲を含む、開発環境、本番環境以外の環境、本番環境のサブネットの例。
- VM へのリモート アクセスを許可するために作成された階層型ファイアウォール ポリシー。
- ロード バランシングのヘルスチェックを許可するために作成された階層型ファイアウォール ポリシー。
- Windows KMS の有効化を許可するために作成された階層型ファイアウォール ポリシー。
- VM / 暗号化されたディスク
- デフォルトの Cloud DNS ポリシーが適用され、DNS ロギングとインバウンド クエリの転送が有効になっている。
プロジェクト
各環境には、前のセクションで説明した共有 VPC ネットワークに接続されている複数のサービス プロジェクトを含めることができます。変更せずにデプロイすると、提供された Terraform によって次のプロジェクト セットが作成されます。プロジェクトは各環境のフォルダにグループ化され、各フォルダは特定のビジネス ユニットに関連付けられます。ビジネス ユニットごとに、Cloud Build のトリガー、アプリケーション インフラストラクチャ コードの証明書署名リクエスト(CSR)、状態ストレージ用の Cloud Storage バケットのある共有 infra-pipeline
プロジェクトが作成されます。
example-organization/
└── fldr-development
└── fldr-development-bu1
├── s3ns:prj-d-bu1-sample-floating
├── s3ns:prj-d-bu1-sample-base
├── s3ns:prj-d-bu1-sample-restrict
├── s3ns:prj-d-bu1-sample-peering
└── fldr-development-bu2
├── s3ns:prj-d-bu2-sample-floating
├── s3ns:prj-d-bu2-sample-base
├── s3ns:prj-d-bu2-sample-restrict
└── s3ns:prj-d-bu2-sample-peering
└── fldr-nonproduction
└── fldr-nonproduction-bu1
├── s3ns:prj-n-bu1-sample-floating
├── s3ns:prj-n-bu1-sample-base
├── s3ns:prj-n-bu1-sample-restrict
├── s3ns:prj-n-bu1-sample-peering
└── fldr-nonproduction-bu2
├── s3ns:prj-n-bu2-sample-floating
├── s3ns:prj-n-bu2-sample-base
├── s3ns:prj-n-bu2-sample-restrict
└── s3ns:prj-n-bu2-sample-peering
└── fldr-production
└── fldr-production-bu1
├── s3ns:prj-p-bu1-sample-floating
├── s3ns:prj-p-bu1-sample-base
├── s3ns:prj-p-bu1-sample-restrict
├── s3ns:prj-p-bu1-sample-peering
└── fldr-production-bu2
├── s3ns:prj-p-bu2-sample-floating
├── s3ns:prj-p-bu2-sample-base
├── s3ns:prj-p-bu2-sample-restrict
└── s3ns:prj-p-bu2-sample-peering
└── fldr-common
├── s3ns:prj-c-bu1-infra-pipeline
└── s3ns:prj-c-bu2-infra-pipeline
ロギングとモニタリング
推奨される構成の最後のステップでは、組織の共通ロギング プロジェクトにログバケットと Pub/Sub ログシンクを構成します。必要な API が必要に応じて有効になっています。非インターセプト集約シンクは、ログバケットを含む共通プロジェクトにログエントリを転送するように組織レベルで構成されます。このしくみの詳細については、一元的なログ ストレージをご覧ください。
管理者と組織のメンバーは、 Trusted Cloud コンソールのログ エクスプローラでログを確認できます。また、pull モードでサブスクリプションを Pub/Sub トピックに接続してログを表示することもできます。 Trusted Cloud の Cloud Logging は、ログを 30 日間のみ保持します。
Terraform を使用して組織を構成する
組織を構成する方法として、特に Google Cloud で組織を設定したことがない場合は、Terraform を使用することをおすすめします。提供された Terraform は、推奨構成で説明されているように、デフォルトのフォルダ、プロジェクト、一元的なロギングとモニタリング、ネットワーキングなどを自動的に設定します。この構成は、デプロイの前または後に、独自のニーズに合わせて調整できます。
Terraform の構成は、Google Cloud の Cloud 基盤がベースとなっています。Cloud 基盤モジュールの詳細については、リポジトリをご覧ください。ただし、すべての情報がこのTrusted Cloud固有の設定に関連しているわけではありません。
始める前に、Terraform ツールがインストールされていることを確認します。 Trusted Cloudでは Cloud Shell がサポートされていないため、手順に沿って Terraform をローカルにインストールします。
Terraform ファイルをダウンロードする
最新の Terraform アセットをダウンロードするには、サポートまたはアカウント チームにお問い合わせください。近々、GitHub から一般公開 Terraform をダウンロードできるようになります。
構成をデプロイする前に、推奨構成で説明されているように、組織にデプロイされている内容を確認します(必要に応じて編集してください)。提供される Terraform には、構成に加えて、次のものをデプロイするブートストラップ モジュールも含まれています。
- 次のものを含む
s3ns:prj-b-seed
プロジェクト。- Terraform 状態バケット
- Terraform が Trusted Cloudに新しいリソースを作成する際に使用するカスタム サービス アカウント
Terraform を適用する
Terraform を適用する手順は次のとおりです。
- Terraform 構成ファイルのあるディレクトリに移動します。
提供された
terraform.tfvars
ファイルを開いて編集し、次のパラメータに選択した値を指定します。org_id = ORG_ID billing_account = BILLING_ACCOUNT billing_project = moonrise-replace5ee46da7eba742199d747bf5477bed08moonrise-replace:BILLING_PROJECT prefix = FOLDER_PREFIX
次のように置き換えます。
ORG_ID
: 組織の一意の IDBILLING_ACCOUNT
: 請求先アカウントBILLING_PROJECT
: 組織の課金プロジェクト(割り当てプロジェクト)FOLDER_PREFIX
(省略可): 一意のフォルダ名とプロジェクト名すべてに適用する接頭辞
構成をデプロイする
terraform init terraform apply
既存のリソースを使用した Terraform のデプロイのトラブルシューティング
ダウンロードした Terraform 構成がすでに存在するリソースを作成しようとすると、Terraform は 409
エラーコードで終了します。これらのエラーを解決するには、 Trusted Cloud コンソールまたは gcloud CLI を使用してリソースを削除し、Terraform 構成を再適用します。また、これらのリソースが重要であり削除できない場合は、Terraform の状態にリソースをインポートできます。
設定を確認する
設定を確認するには、まず Google Cloud CLI または Trusted Cloud コンソールを使用して、フォルダとプロジェクトの構造が正しく設定されていることを確認することをおすすめします。
次に、任意のワークロードを使用するか、クイックスタート チュートリアルに沿って、いずれかの Service プロジェクトにアプリケーション ワークロードをデプロイしてみます。これらは Trusted Cloudで簡単なサンプルをすばやく実行できるようにする、短いチュートリアルです。詳しくは、次のステップをご覧ください。
次のステップ
クイックスタート チュートリアルを試して、組織の設定を確認します。最初にお試しいただけるヒントをいくつかご紹介します。
- Compute Engine で Linux VM インスタンスを作成する
- GKE クラスタを作成してワークロードをデプロイする
- BigQuery で一般公開データセットに対してクエリを実行する(このチュートリアルでは、事前にデータセットをアップロードする必要があります)
初期設定を拡張してカスタマイズします。たとえば、次のようなことができます。
IAM を使用してユーザーとグループに権限を付与する。