マネージド制約は、最新のプラットフォーム上に構築された事前定義の組織のポリシーであり、Compute Engine リソースをプログラムによって一元管理できます。これには、Policy Simulator やドライランなどの安全なロールアウト ツールに対する組み込みサポートが含まれます。
マネージド制約は compute.managed.* 接頭辞で識別でき、以前の compute.* 制約の直接的な代替として機能します。
利点
- 安全なロールアウトとモニタリング: ツールをフル活用してポリシーを実装し、変更管理を迅速化します。シミュレーションとドライラン機能を使用して、段階的にデプロイします。
- 一貫性のあるロギング: ロギングとエラー メッセージの統一性を強化し、一元化されたモニタリングを簡素化して監査を効率化します。
ポリシーの継承
リソースに設定した組織のポリシーは、リソース階層内のそのリソースの子孫に継承されます。たとえば、フォルダにポリシーを適用した場合、 Cloud de Confiance by S3NS はそのフォルダ内のすべてのプロジェクトにそのポリシーを適用します。
料金
事前定義(以前の)、マネージド、カスタムの組織のポリシーを含め、組織のポリシー サービスは無料です。
始める前に
-
まだ設定していない場合は、認証を設定します。認証では、 Cloud de Confiance by S3NS サービスと API にアクセスするための ID が確認されます。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。
このページのサンプルをどのように使うかに応じて、タブを選択してください。
コンソール
Cloud de Confiance コンソールを使用して Cloud de Confiance by S3NS サービスと API にアクセスする場合、認証を設定する必要はありません。
gcloud
-
Google Cloud CLI をインストールし、 フェデレーション ID を使用して gcloud CLI にログインします。ログイン後、次のコマンドを実行して Google Cloud CLI を初期化します。
gcloud init
-
- デフォルトのリージョンとゾーンを設定します。
REST
このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。
Google Cloud CLI をインストールし、 フェデレーション ID を使用して gcloud CLI にログインします。
詳細については、 Cloud de Confiance 認証ドキュメントの REST を使用して認証するをご覧ください。
- 組織 ID を確認します。
- まだ行っていない場合は、gcloud CLI をインストールし、
gcloud initを実行して初期化します。 - テスト用のデフォルト プロジェクトを設定します。
必要なロール
マネージド制約を使用して組織のポリシーを管理するために必要な権限を取得するには、次の IAM ロールを付与するように管理者に依頼してください。
- 組織リソースに対する組織のポリシー管理者(
roles/orgpolicy.policyAdmin) -
制約をテストする場合: プロジェクトに対する Compute インスタンス管理者(v1) (
roles/compute.instanceAdmin.v1)
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
これらの事前定義ロールには、マネージド制約を使用して組織のポリシーを管理するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。
必要な権限
マネージド制約を使用して組織のポリシーを管理するには、次の権限が必要です。
-
orgpolicy.constraints.list -
orgpolicy.policies.create -
orgpolicy.policies.delete -
orgpolicy.policies.list -
orgpolicy.policies.update -
orgpolicy.policy.get -
orgpolicy.policy.set -
制約をテストするには:
- プロジェクトに対する
compute.instances.create - カスタム イメージを使用して VM を作成する: イメージに対する
compute.images.useReadOnly - スナップショットを使用して VM を作成する: スナップショットに対する
compute.snapshots.useReadOnly - インスタンス テンプレートを使用して VM を作成する: インスタンス テンプレートに対する
compute.instanceTemplates.useReadOnly - 以前のネットワークを VM に割り当てる: プロジェクトに対する
compute.networks.use - VM の静的 IP アドレスを指定する: プロジェクトに対する
compute.addresses.use - 以前のネットワークの使用時に VM に外部 IP アドレスを割り当てる: プロジェクトに対する
compute.networks.useExternalIp - VM のサブネットを指定する: プロジェクトまたは選択したサブネットに対する
compute.subnetworks.use - VPC ネットワークの使用時に VM に外部 IP アドレスを割り当てる: プロジェクトまたは選択したサブネットに対する
compute.subnetworks.useExternalIp - VM の VM インスタンス メタデータを設定する: プロジェクトに対する
compute.instances.setMetadata - VM にタグを設定する: VM に対する
compute.instances.setTags - VM にラベルを設定する: VM に対する
compute.instances.setLabels - VM が使用するサービス アカウントを設定する: VM に対する
compute.instances.setServiceAccount - VM に新しいディスクを作成する: プロジェクトに対する
compute.disks.create - 既存のディスクを読み取り専用モードまたは読み取り / 書き込みモードでアタッチする: ディスクに対する
compute.disks.use - 既存のディスクを読み取り専用モードでアタッチする: ディスクに対する
compute.disks.useReadOnly
- プロジェクトに対する
カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。
使用可能なマネージド制約
Compute Engine では、次のマネージド組織のポリシーの制約を使用できます。
階層型メタデータの評価
OS Login やシリアルポート アクセスなどの事前定義されたメタデータキーに依存するマネージド制約は、階層評価をサポートしています。Compute Engine がこれらの制約を評価するときに、VM インスタンス、プロジェクト、ゾーンレベルで設定されたメタデータ値がチェックされます。
プロジェクト レベルまたはゾーンレベルでメタデータ値を設定すると、VM インスタンスを大規模に管理できます。ただし、制約の適用は、VM インスタンスの作成または更新の API 呼び出しでのみ行われます。したがって、プロジェクトまたはゾーン メタデータの変更は、インスタンスの作成または更新時にのみ VM インスタンスの制約コンプライアンスに影響します。
メタデータ ベースの制約とレベル
| 制約 | メタデータキー | メタデータ階層レベル |
|---|---|---|
compute.managed.disableSerialPortAccess |
serial-port-enable |
プロジェクト、ゾーン、インスタンス |
compute.managed.requireOsLogin |
enable-oslogin |
プロジェクト、ゾーン、インスタンス |
compute.managed.disableGuestAttributesAccess |
enable-guest-attributes |
プロジェクト、ゾーン、インスタンス |
compute.managed.requireOsConfig |
enable-osconfig |
プロジェクト、ゾーン、インスタンス |
compute.managed.disallowGlobalDns |
VmDnsSetting |
プロジェクト、インスタンス |
安全なロールアウト: ポリシーのライフサイクル
新しい制約を段階的に実装する際にサービスが中断しないようにするには、次の手順に沿ってマネージド制約を実装することをおすすめします。
Policy Simulator で分析する
ポリシーを適用する前に、Policy Simulator を使用して、既存のリソースのうちポリシーに違反しているリソースを確認します。手順は次のとおりです。
Cloud de Confiance コンソールで、[組織のポリシー] ページに移動します。
フィルタバーで制約を検索し、制約名をクリックして [ポリシーの詳細] ページに移動します。
[変更をテスト] をクリックして、シミュレーション レポートを生成します。
階層メタデータの変更が、VM メタデータ設定の制約のシミュレーション レポートに反映されるまでに数時間かかることがあります。
レポートを確認して、準拠していないリソースを再構成するか、例外をリクエストします。
ドライランで検証する
ドライラン モードでは、違反は Cloud Logging に記録されますが、制限は適用されません。
制約をテストするには、次のように gcloud org-policies set-policy コマンドを使用します。
dryRunSpecを含むポリシー YAML ファイル(dry-run-policy.yamlなど)を作成します。name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin dryRunSpec: rules: - enforce: truePROJECT_IDは、実際のプロジェクト ID に置き換えます。ポリシーを適用します。
gcloud org-policies set-policy dry-run-policy.yaml
完全な違反措置
ポリシーをシミュレートしてテストしたら、リソースに適用できます。ポリシーの変更がすべてのCloud de Confiance by S3NS システムに反映されるまでに、最大 15 分ほどかかることがあります。
制約の適用をテストする
ポリシーを設定したら、gcloud CLI を使用して適用を確認できます。たとえば、compute.managed.requireOsLogin 制約をテストする手順は次のとおりです。
既存のポリシーを一覧表示して、構成を確認します。
gcloud org-policies list --project=PROJECT_IDYAML ファイルを使用して適用ポリシーを適用します。
gcloud org-policies set-policy enforce_managed_constraint.yamlミューテーション API を呼び出して、適用を確認します。準拠していないメタデータを使用して VM インスタンスを作成しようとすると、失敗するはずです。
gcloud compute instances create VM_NAME \ --machine-type=MACHINE_TYPE \ --image-family=IMAGE_FAMILY \ --image-project=IMAGE_PROJECT \ --metadata=enable-oslogin=false次のように置き換えます。
VM_NAME: 新しい VM インスタンスの名前。MACHINE_TYPE: 有効なマシンタイプ(例:e2-micro)。IMAGE_FAMILY: 有効なイメージ ファミリー(例:debian-11)。IMAGE_PROJECT: イメージ ファミリーのプロジェクト(例:debian-cloud)。
エラー メッセージを確認します。違反した特定の制約を示す拒否が表示されます。
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Operation denied by org policy: [constraints/compute.managed.requireOsLogin]
タグを使用した条件付き除外
タグを使用すると、ビジネスニーズに基づいて特定のリソースに例外を付与できます。この例では、osLoginOptional という名前のタグを使用して、OS Login の要件から除外されるリソースを識別します。このタグを値 true でリソースにバインドすると、組織のポリシーは、環境の残りの部分でポリシーが厳密に適用されたままであっても、OS Login が有効になっていない特定のリソースの存在を許可します。
タグを使用して例外を付与する手順は次のとおりです。
タグを作成する: gcloud CLI を使用して、タグキーとタグ値を作成します。
タグキーを作成します。
gcloud resource-manager tags keys create osLoginOptional \ --parent=organizations/ORGANIZATION_IDタグ値を作成します。
gcloud resource-manager tags values create true \ --parent=organizations/ORGANIZATION_ID/tagKeys/osLoginOptional
ORGANIZATION_IDは、実際の組織 ID に置き換えます。タグをリソースにバインドします。
compute.managed.requireOsLogin制約からプロジェクトを除外するには、gcloud resource-manager tags bindings createコマンドを使用してosLoginOptional=trueタグをプロジェクトにバインドします。gcloud resource-manager tags bindings create \ --tag-value=ORGANIZATION_ID/osLoginOptional/true \ --parent=//cloudresourcemanager.googleapis.com/projects/PROJECT_ID \ --location=globalORGANIZATION_IDは組織 ID に、PROJECT_IDは除外するプロジェクトの ID に置き換えます。タグを他のリソースにバインドする方法については、タグをリソースにバインドするをご覧ください。
ポリシーを更新する: 条件付きルールを含めるように、ポリシー YAML ファイル(
policy.yamlなど)を作成または更新します。name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin spec: rules: - condition: expression: "resource.matchTag('ORGANIZATION_ID/osLoginOptional', 'true')" enforce: false - enforce: true次のように置き換えます。
PROJECT_ID: プロジェクト ID。ORGANIZATION_ID: 組織 ID。
ポリシーを適用する: 次の gcloud CLI コマンドを使用して、構成を有効にします。
gcloud org-policies set-policy policy.yaml
以前の制約からの移行
移行の際は、マネージド制約は以前のポリシーの動作を改善するものであり、完全に複製するものではないことに注意してください。マネージド制約は、リソースの作成または変更を行う API リクエスト中にのみ違反をチェックするため、予測可能性が高くなります。リクエストが制約に違反している場合、API 呼び出しは明確なエラーで失敗します。これは、オペレーションのさまざまな段階で適用されたり、リソース属性として使用されたりして、適用動作の予測が難しくなる従来のポリシーとは異なります。
以前の compute.* 制約から最新の compute.managed.* 相当に移行する場合は、次の手順に沿って、意図しない制限の強化を防ぎます。
- 検出: 新しいマネージド制約の代替案を特定します。
- 分析と検証: 前述のように、Policy Simulator とドライランを使用します。
- マネージド制約を適用する: 新しいマネージド制約を以前の制約とともに適用します。
- 以前のポリシーを削除します。
- Cloud de Confiance コンソールの [アセット インベントリ] に移動し、
orgpolicy.Policyと以前の制約名でフィルタして、以前の制約を使用するすべてのポリシーを特定します。 - 以前の制約を使用するポリシーをすべて削除します。ポリシーを削除すると、そのポリシーは、その制約の Google 管理のデフォルトの動作にリセットされます。
- Cloud de Confiance コンソールの [アセット インベントリ] に移動し、
次のステップ
- サービスの基本的なコンセプトとメリットについては、組織のポリシー サービスの概要をご覧ください。
- ポリシーの作成と管理の詳細な手順については、Resource Manager のドキュメントをご覧ください。
- すべての Cloud de Confiance by S3NS サービスで使用可能な制約の全リストをご覧ください。
- 組織のポリシーの詳細な影響分析に Policy Simulator を使用する方法について学習します。