マネージド制約

マネージド制約は、最新のプラットフォーム上に構築された事前定義の組織のポリシーであり、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

    1. 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 ロールを付与するように管理者に依頼してください。

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

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

必要な権限

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

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

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

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

  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
    

完全な違反措置

ポリシーをシミュレートしてテストしたら、リソースに適用できます。ポリシーの変更がすべてのCloud de Confiance by S3NS システムに反映されるまでに、最大 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. 以前のポリシーを削除します。
    • Cloud de Confiance コンソールの [アセット インベントリ] に移動し、orgpolicy.Policy と以前の制約名でフィルタして、以前の制約を使用するすべてのポリシーを特定します。
    • 以前の制約を使用するポリシーをすべて削除します。ポリシーを削除すると、そのポリシーは、その制約の Google 管理のデフォルトの動作にリセットされます。

次のステップ