マネージド制約

マネージド制約は、最新のプラットフォーム上に構築された事前定義の組織のポリシーであり、Compute Engine リソースをプログラムによって一元管理できます。これには、Policy Simulator やドライランなどの安全なロールアウト ツールに対する組み込みサポートが含まれます。

マネージド制約は compute.managed.* 接頭辞で識別でき、以前の compute.* 制約の直接的な代替として機能します。

利点

  • 安全なロールアウトとモニタリング: 完全なツールを使用してポリシーを実装し、変更制御を迅速化し、シミュレーションとドライラン機能を使用して段階的にデプロイします。
  • 一貫性のあるロギング: ロギングとエラー メッセージの統一性を強化し、一元化されたモニタリングを簡素化して監査を効率化します。

ポリシーの継承

リソースに設定した組織のポリシーは、リソース階層内のそのリソースの子孫に継承されます。たとえば、フォルダにポリシーを適用した場合、 Google Cloud はそのフォルダ内のすべてのプロジェクトにそのポリシーを適用します。

料金

事前定義(以前の)、マネージド、カスタムの組織のポリシーを含む組織のポリシー サービスは無料です。

始める前に

  • まだ設定していない場合は、認証を設定します。認証では、 Google Cloud サービスと API にアクセスするための ID が確認されます。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Google Cloud CLI をインストールします。 インストール後、次のコマンドを実行して Google Cloud CLI を初期化します。

      gcloud init

      外部 ID プロバイダ(IdP)を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。

    2. Set a default region and zone.

    REST

    このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

      Google Cloud CLI をインストールします。 インストール後、次のコマンドを実行して Google Cloud CLI を初期化します。

      gcloud init

      外部 ID プロバイダ(IdP)を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。

    詳細については、 Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

  • 組織 ID を確認します。
  • まだ行っていない場合は、gcloud CLI をインストールし、gcloud init を実行して初期化します。
  • テスト用のデフォルト プロジェクトを設定します。

必要なロール

マネージド制約を使用して組織のポリシーを管理するために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、マネージド制約を使用して組織のポリシーを管理するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

マネージド制約を使用して組織のポリシーを管理するには、次の権限が必要です。

  • 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 では、次のマネージド組織のポリシーの制約を使用できます。

制約 説明
許可された VLAN アタッチメント暗号化設定

このリスト型制約は、新しい VLAN アタッチメントで許可される暗号化設定を定義します。
デフォルトでは、VLAN アタッチメントで任意の暗号化設定を使用できます。
暗号化された VLAN アタッチメントのみが作成されるようにするには、許可される値として IPSEC を設定します。

constraints/compute.managed.allowedVlanAttachmentEncryption
Compute Engine のプレビュー機能をブロックする

この制約により、この制約が明示的に許可されない限り、プレビュー機能はブロックされます。許可に設定すると、プロジェクトで個別に有効または無効にできるプレビュー機能を制御できます。プロジェクトでアクセスできるのは、有効になっているプレビュー機能のみです。ポリシーを無効にしても、すでに設定されている個々のプレビュー機能のステータスは変更されません。個々のプレビュー機能は個別に無効にできます。この制約は、Compute Alpha API の機能にのみ適用されます。

constraints/compute.managed.blockPreviewFeatures
VM のネストされた仮想化を無効化

[パブリック プレビュー] このブール型制約により、制約が True に設定されている組織、プロジェクト、フォルダに属するすべての Compute Engine VM に対するハードウェア アクセラレーションによりネストされた仮想化は無効になります。
デフォルトでは、Intel Haswell 以降の CPU プラットフォームで実行されているすべての Compute Engine VM に対して、ハードウェア アクセラレーションによりネストされた仮想化は許可されています。

constraints/compute.managed.disableNestedVirtualization
VM シリアルポート アクセス メタデータの有効化を制限する

プレビュー: この制約により、この制約が適用されている組織、プロジェクト、フォルダ内の Compute Engine VM で serial-port-enable メタデータキーを true に設定できなくなります。デフォルトでは、このメタデータキーを使用して、VM 単位、ゾーン単位、プロジェクト単位でシリアルポート アクセスを有効にできます。特定の VM のシリアルポート アクセスを許可するには、タグと条件付きルールを使用して、このポリシーから除外します。
重要: この制約を適用しても、serial-port-enable がすでに true に設定されている既存の VM には影響しません。メタデータが更新されない限り、アクセス権は保持されます。

constraints/compute.managed.disableSerialPortAccess
Stackdriver への VM シリアルポート ロギングを無効化

[一般提供] この制約が適用されると、Compute Engine VM から Stackdriver へのシリアルポート ロギングが無効になります。
デフォルトでは、Compute Engine VM のシリアルポート ロギングは無効になっており、メタデータ属性を使用して VM 単位またはプロジェクト単位で選択して有効にできます。シリアルポート ロギングを無効にすると、この機能に依存する特定のサービス(Google Kubernetes Engine クラスタなど)が正しく機能しなくなるおそれがあります。この制約を適用する前に、プロジェクト内のプロダクトがシリアル ポート ロギングに依存していないことを確認してください。特定の VM インスタンスでシリアルポート ロギングを使用できます。まず、タグを適用してインスタンスをマークし、次にタグ値に基づく条件付きルールを使用して、これらのインスタンスを適用範囲から適切に除外します。

constraints/compute.managed.disableSerialPortLogging
ZonalOnly DNS 設定を持つプロジェクトのグローバル内部 DNS(gDNS)の使用を制限します。

[パブリック プレビュー] この制約を適用すると、gDNS の使用が制限されます。この制限により、gDNS VM の作成と、gDNS を使用するための VM の更新が無効になります。zDNS プロジェクトを gDNS に戻すことはブロックされませんが、後続の Instance API 呼び出しでポリシー違反が適用されます。

constraints/compute.managed.disallowGlobalDns
OS Config が必要

[パブリック プレビュー] この制約を適用すると、すべての新しいプロジェクトで VM Manager(OS Config)を有効にする必要があります。この制約を適用すると、新規および既存のプロジェクトにおいて、プロジェクト、プロジェクト ゾーン、インスタンス レベルで VM Manager を無効にするようなメタデータの更新を行うことができなくなります。特定の VM インスタンスで VM Manager を無効にすることを許可できます。まず、タグを適用してインスタンスをマークし、次にタグ値に基づく条件付きルールを使用して、これらのインスタンスを適用範囲から適切に除外します。

constraints/compute.managed.requireOsConfig
OS ログインが必須

[パブリック プレビュー] この制約を適用すると、新しく作成するすべてのプロジェクトで OS Login を有効にする必要があります。この制約は、新規および既存のプロジェクトについて、プロジェクト、プロジェクト ゾーン、インスタンス レベルで OS Login が無効なメタデータが更新されるのを防ぎます。特定の VM インスタンスで OS Login を無効にすることができます。まず、タグを適用してインスタンスをマークし、次にタグ値に基づく条件付きルールを使用して、これらのインスタンスを適用範囲から適切に除外します。

constraints/compute.managed.requireOsLogin
プロトコル転送の使用を制限する

この制約を使用すると、組織で作成できるプロトコル転送デプロイのタイプ(内部または外部)を制限できます。制約を構成するには、許可するプロトコル転送デプロイメントのタイプの許可リストを指定します。許可リストには、次の値のみを含めることができます。

  • INTERNAL
  • EXTERNAL
。たとえば、許可リストが INTERNAL に設定されている場合、ユーザーは内部プロトコル転送のみを設定できます。つまり、ターゲット インスタンスに関連付けられた転送ルールは、内部ロード バランシング スキームに制限され、内部 IP アドレスのみを使用する必要があります。

constraints/compute.managed.restrictProtocolForwardingCreationForTypes
VM IP 転送を制限する

[パブリック プレビュー] この制約は、Compute Engine VM インスタンスで IP 転送を有効にできるかどうかを定義します。デフォルトでは、ポリシーが指定されていない場合、すべての VM がすべての仮想ネットワークで IP 転送を有効にできます。この制約が適用されると、IP 転送が有効になっている VM インスタンスの作成または更新が拒否されます。特定の VM インスタンスで IP 転送を有効にできます。まず、タグを適用してインスタンスをマークし、次にタグ値に基づく条件付きルールを使用して、これらのインスタンスを適用範囲から適切に除外します。

constraints/compute.managed.vmCanIpForward
VM インスタンスの外部 IP を制限する

[パブリック プレビュー] この制約は、Compute Engine VM インスタンスで IPv4 外部 IP アドレスの使用が許可されているかどうかを定義します。デフォルトでは、すべての VM インスタンスで外部 IP アドレスの使用が許可されます。この制約が適用されると、IPv4 外部 IP アドレスを持つ VM インスタンスの作成または更新が拒否されます。この制約は、IPv6 外部 IP アドレスの使用を制限しません。特定の VM インスタンスで外部 IPv4 IP アドレスを使用できるようにすることができます。まず、タグを適用してインスタンスをマークし、次にタグ値に基づく条件付きルールを使用して、これらのインスタンスを適用範囲から適切に除外します。

constraints/compute.managed.vmExternalIpAccess

階層メタデータの評価

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 を使用して、既存のリソースのうちポリシーに違反しているリソースを確認します。手順は次のとおりです。

  1. Google Cloud コンソールで、[組織のポリシー] ページに移動します。

    [組織のポリシー] に移動

  2. フィルタバーで制約を検索し、制約名をクリックして [ポリシーの詳細] ページに移動します。

  3. [変更をテスト] をクリックして、シミュレーション レポートを生成します。

  4. 階層メタデータの変更が、VM メタデータ設定の制約のシミュレーション レポートに反映されるまでに数時間かかることがあります。

  5. レポートを確認して、準拠していないリソースを再構成するか、例外をリクエストします。

ドライランで検証する

ドライラン モードでは、違反が Cloud Logging に記録されますが、制限は適用されません。

制約をテストするには、次のように gcloud org-policies set-policy コマンドを使用します。

  1. dryRunSpec を含むポリシー YAML ファイル(dry-run-policy.yaml など)を作成します。

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
    dryRunSpec:
      rules:
      - enforce: true
    

    PROJECT_ID は、実際のプロジェクト ID に置き換えます。

  2. ポリシーを適用します。

    gcloud org-policies set-policy dry-run-policy.yaml
    

完全な違反措置

ポリシーをシミュレートしてテストしたら、リソースに適用できます。ポリシーの変更がすべてのGoogle Cloud システムに反映されるまでに、最大 15 分ほどかかることがあります。

制約の適用をテストする

ポリシーを設定したら、gcloud CLI を使用して適用を確認できます。たとえば、compute.managed.requireOsLogin 制約をテストする手順は次のとおりです。

  1. 既存のポリシーを一覧表示して、構成を確認します。

    gcloud org-policies list --project=PROJECT_ID
    
  2. YAML ファイルを使用して適用ポリシーを適用します。

    gcloud org-policies set-policy enforce_managed_constraint.yaml
    
  3. ミューテーション 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)。
  4. エラー メッセージを確認します。違反した特定の制約を示す拒否が表示されます。ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Operation denied by org policy: [constraints/compute.managed.requireOsLogin]

タグを使用した条件付きの除外

タグを使用すると、ビジネスニーズに基づいて特定のリソースに例外を付与できます。この例では、osLoginOptional という名前のタグを使用して、OS Login の要件から除外されるリソースを識別します。このタグを値 true でリソースにバインドすると、組織のポリシーは、環境の残りの部分でポリシーが厳密に適用されたままであっても、OS Login が有効になっていない特定のリソースの存在を許可します。

タグを使用して例外を付与する手順は次のとおりです。

  1. タグを作成する: gcloud CLI を使用して、タグキーとタグ値を作成します。

    1. タグキーを作成します。

      gcloud resource-manager tags keys create osLoginOptional \
          --parent=organizations/ORGANIZATION_ID
      
    2. タグ値を作成します。

      gcloud resource-manager tags values create true \
          --parent=organizations/ORGANIZATION_ID/tagKeys/osLoginOptional
      

    ORGANIZATION_ID は、実際の組織 ID に置き換えます。

  2. タグをリソースにバインドします。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=global
    

    ORGANIZATION_ID は組織 ID に、PROJECT_ID は除外するプロジェクトの ID に置き換えます。

    タグを他のリソースにバインドする方法については、タグをリソースにバインドするをご覧ください。

  3. ポリシーを更新する: 条件付きルールを含めるように、ポリシー 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。
  4. ポリシーを適用する: 次の gcloud CLI コマンドを使用して、構成を有効にします。

    gcloud org-policies set-policy policy.yaml
    

以前の制約からの移行

移行の際は、マネージド制約は以前のポリシーの動作を改善するものであり、完全に複製するものではないことに注意してください。マネージド制約は、リソースの作成または変更を行う API リクエスト中にのみ違反をチェックするため、予測可能性が高くなります。リクエストが制約に違反している場合、API 呼び出しは明確なエラーで失敗します。これは、オペレーションのさまざまな段階で適用されたり、リソース属性として使用されたりして、適用動作の予測が難しくなる従来のポリシーとは異なります。

以前の compute.* 制約から最新の compute.managed.* 相当に移行する場合は、次の手順に沿って、意図しない制限の強化を防ぎます。

  1. おすすめ: 新しいマネージド制約の代替案を特定する。
  2. 分析と検証: 前述のように、Policy Simulator とドライランを使用します。
  3. マネージド制約を適用する: 新しいマネージド制約を以前の制約とともに適用します。
  4. 以前のポリシーを削除します。
    • Google Cloud コンソールでアセット インベントリに移動し、orgpolicy.Policy と以前の制約名でフィルタして、以前の制約を使用するすべてのポリシーを特定します。
    • 以前の制約を使用するポリシーをすべて削除します。ポリシーを削除すると、そのポリシーは、その制約に対する Google 管理のデフォルトの動作にリセットされます。

次のステップ