Erstellung von VMs verhindern, die die Containermetadaten verwenden

Damit Ressourcen in Ihrer Organisation nicht den eingestellten Container-Start-Agent und die zugehörigen gce-container-declaration-Metadaten verwenden, empfiehlt Google, eine Organisationsrichtlinie zu erzwingen. Die verwaltete Einschränkung compute.managed.disableVmsWithContainerStartupAgent verhindert bei der Durchsetzung die Erstellung von Ressourcen, die die eingestellten Metadaten verwenden.

In diesem Dokument wird Folgendes beschrieben:

  • Erzwingen Sie eine Organisationsrichtlinie, um das Erstellen von Compute Engine-Instanzen zu deaktivieren, die den Container-Start-Agent verwenden.
  • Überwachen Sie die Auswirkungen der Organisationsrichtlinie, indem Sie sie im Probelaufmodus erzwingen.
  • Projekte, in denen versucht wird, den verworfenen Agenten zu verwenden, mit dem Log-Explorer identifizieren

Organisationsrichtlinie erzwingen, um die Erstellung von VMs zu deaktivieren, die die Containermetadaten verwenden

Damit keine Ressourcen erstellt werden, die den eingestellten Container-Start-Agent verwenden, empfiehlt Google, eine Organisationsrichtlinie zu erzwingen. Die Einschränkung constraints/compute.managed.disableVmsWithContainerStartupAgent verhindert, dass neue Ressourcen mit dem Metadatenschlüssel gce-container-declaration erstellt werden. Diese Einschränkung hat keine Auswirkungen auf vorhandene Instanzen oder Instanzvorlagen.

Sie können diese Einschränkung über die Google Cloud Console, die Google Cloud CLI oder die Compute Engine API erzwingen.

Console

So legen Sie die Organisationsrichtlinie mit der Console fest:

  1. Wechseln Sie in der Google Cloud Console zur Seite Organisationsrichtlinien.

    Zu den Organisationsrichtlinien

  2. Wählen Sie in der Projektauswahl das Projekt, den Ordner oder die Organisation aus, für die Sie Organisationsrichtlinien bearbeiten möchten.

    Auf der Seite Organisationsrichtlinien wird eine Liste der verfügbaren Einschränkungen für Organisationsrichtlinien angezeigt.

  3. Wählen Sie aus der Liste der Einschränkungen die Einschränkung Disable creation of Compute Engine instances that use the deprecated container startup agent (konlet) (Erstellung von Compute Engine-Instanzen, die den eingestellten Container-Start-Agent (konlet) verwenden, deaktivieren) aus. Auf der Seite Richtliniendetails finden Sie eine Beschreibung der Einschränkung und Informationen darüber, wie die Einschränkung angewendet wird.

  4. Zum Konfigurieren der Organisationsrichtlinie für diese Ressource klicken Sie auf Richtlinie verwalten.

  5. Klicken Sie auf der Seite Richtlinie bearbeiten auf Richtlinie der übergeordneten Ressource überschreiben.

  6. Wählen Sie Regel hinzufügen aus.

  7. Wählen Sie unter Erzwingung die Option An aus.

  8. Optional: Wenn Sie die Auswirkungen der Änderung der Organisationsrichtlinie vor der Erzwingung ansehen möchten, klicken Sie auf Änderungen testen. Weitere Informationen zum Testen von Änderungen an Organisationsrichtlinien finden Sie unter Änderungen an Organisationsrichtlinien mit dem Policy Simulator testen.

  9. Klicken Sie auf Probelaufrichtlinie festlegen, um die Organisationsrichtlinie im Probelaufmodus zu erzwingen. Weitere Informationen finden Sie unter Organisationsrichtlinie im Probelaufmodus aus einer aktiven Richtlinie erstellen.

  10. Nachdem Sie überprüft haben, ob die Organisationsrichtlinie im Probelaufmodus wie vorgesehen funktioniert, legen Sie die aktive Richtlinie fest, indem Sie auf Richtlinie festlegen klicken.

gcloud

  1. Erstellen Sie eine YAML-Datei, um die Organisationsrichtlinie zu definieren.

    name: RESOURCE_TYPE/RESOURCE_ID/policies/CONSTRAINT_NAME
    spec:
    rules:
        - enforce: ENFORCEMENT_STATE
    dryRunSpec:
      rules:
      - enforce: ENFORCEMENT_STATE
    

    Ersetzen Sie Folgendes:

    • RESOURCE_TYPE mit organizations, folders oder projects.

    • RESOURCE_ID mit Ihrer Organisations-ID, Ordner-ID, Projekt-ID oder Projektnummer, je nach Ressourcentyp, der in RESOURCE_TYPE angegeben ist.

    • CONSTRAINT_NAME durch den Namen der Einschränkung, die Sie festlegen möchten.

    • ENFORCEMENT_STATE mit true, um diese Organisationsrichtlinie zu erzwingen, wenn sie festgelegt ist, oder false, um sie zu deaktivieren, wenn sie festgelegt ist.

    Optional können Sie die Organisationsrichtlinie von einem Tag abhängig machen, indem Sie der rules einen condition-Block hinzufügen. Wenn Sie einer Organisationsrichtlinie eine bedingte Regel hinzufügen, müssen Sie mindestens eine bedingungsfreie Regel hinzufügen oder die Richtlinie kann nicht gespeichert werden. Weitere Informationen finden Sie unter Organisationsrichtlinie mit Tags festlegen.

  2. Führen Sie den Befehl org-policies set-policy mit dem Flag dryRunSpec aus, um die Organisationsrichtlinie im Probebetriebsmodus festzulegen:

     gcloud org-policies set-policy POLICY_PATH \
       --update-mask=dryRunSpec
    

    Ersetzen Sie POLICY_PATH durch den vollständigen Pfad zur YAML-Datei Ihrer Organisationsrichtlinie.

    Weitere Informationen zu Organisationsrichtlinien im Probelaufmodus finden Sie unter Organisationsrichtlinie im Probelaufmodus erstellen.

  3. Verwenden Sie den Befehl policy-intelligence simulate orgpolicy, um eine Vorschau der Auswirkungen der Änderung der Organisationsrichtlinie zu sehen, bevor sie erzwungen wird:

    gcloud policy-intelligence simulate orgpolicy \
      --organization=ORGANIZATION_ID \
      --policies=POLICY_PATH
    

    Ersetzen Sie Folgendes:

    • ORGANIZATION_ID durch Ihre Organisations-ID, z. B. 1234567890123. Das Simulieren von Änderungen in mehreren Organisationen wird nicht unterstützt.

    • POLICY_PATH durch den vollständigen Pfad zur YAML-Datei Ihrer Organisationsrichtlinie.

    Weitere Informationen zum Testen von Änderungen an Organisationsrichtlinien finden Sie unter Änderungen an Organisationsrichtlinien mit dem Policy Simulator testen.

  4. Nachdem Sie überprüft haben, ob die Organisationsrichtlinie im Probelaufmodus wie vorgesehen funktioniert, legen Sie die aktive Richtlinie mit dem Befehl org-policies set-policy und dem Flag spec fest:

    gcloud org-policies set-policy POLICY_PATH \
      --update-mask=spec
    

    Ersetzen Sie POLICY_PATH durch den vollständigen Pfad zur YAML-Datei Ihrer Organisationsrichtlinie.

REST

Verwenden Sie die Methode organizations.policies.create, um die Organisationsrichtlinie festzulegen.

POST https://orgpolicy.googleapis.com/v2/{parent=organizations/ORGANIZATION_ID}/policies

Der JSON-Text der Anfrage enthält die Definition einer Organisationsrichtlinie. Wenn diese Einschränkung keine Parameter unterstützt, lassen Sie den parameters-Block unter rules weg.

{
  "name": "RESOURCE_TYPE/RESOURCE_ID/policies/CONSTRAINT_NAME",
  "spec": {
    "rules": [
      {
        "enforce": ["ENFORCEMENT_STATE"],
      }
    ]
  }
  "dryRunSpec": {
    "rules": [
      {
        "enforce": ["ENFORCEMENT_STATE"],
      }
    ]
  }
}

Ersetzen Sie Folgendes:

  • RESOURCE_TYPE mit organizations, folders oder projects.

  • RESOURCE_ID mit Ihrer Organisations-ID, Ordner-ID, Projekt-ID oder Projektnummer, je nach Ressourcentyp, der in RESOURCE_TYPE angegeben ist.

  • CONSTRAINT_NAME durch den Namen der Einschränkung, die Sie festlegen möchten.

  • ENFORCEMENT_STATE mit true, um diese Organisationsrichtlinie zu erzwingen, wenn sie festgelegt ist, oder false, um sie zu deaktivieren, wenn sie festgelegt ist.

Optional können Sie die Organisationsrichtlinie von einem Tag abhängig machen, indem Sie der rules einen condition-Block hinzufügen. Wenn Sie einer Organisationsrichtlinie eine bedingte Regel hinzufügen, müssen Sie mindestens eine bedingungsfreie Regel hinzufügen oder die Richtlinie kann nicht gespeichert werden. Weitere Informationen finden Sie unter Organisationsrichtlinie mit Tags festlegen.

Weitere Informationen zu Organisationsrichtlinien im Probelaufmodus finden Sie unter Organisationsrichtlinie im Probelaufmodus erstellen.

Nutzung der eingestellten Metadaten überwachen, indem die Richtlinie im Probelaufmodus erzwungen wird

Anstatt die Richtlinie direkt zu erzwingen, wodurch die Erstellung von Instanzen blockiert wird, die die Metadaten der Containerdeklaration verwenden, können Sie die Richtlinie im Testlaufmodus anwenden. Mit dieser Einstellung können Sie alle Aktionen überwachen und protokollieren, die durch die Richtlinie blockiert werden können, ohne tatsächlich in den Betrieb einzugreifen. Weitere Informationen finden Sie unter Organisationsrichtlinie im Probelaufmodus erstellen.

Wenn eine Aktion die Probelaufrichtlinie auslöst (z. B. wenn Sie versuchen, eine Instanz mit dem Metadatenschlüssel gce-container-declaration zu erstellen), wird in Cloud-Audit-Logs ein Logeintrag generiert.

So ermitteln Sie Projekte, in denen versucht wird, den eingestellten Agent zu verwenden:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Geben Sie im Bereich Abfrage die folgende Abfrage ein:

    protoPayload.metadata.dryRun="true"
    protoPayload.methodName="CheckOrgPolicy"
    protoPayload.resourceName =~ "/compute.managed.disableVmsWithContainerStartupAgent"
    
  3. Klicken Sie auf Abfrage ausführen.

  4. Ermitteln Sie die Projekte, in denen versucht wird, den eingestellten Agent zu verwenden, indem Sie die Logeinträge prüfen. Die Logs für Testlauf-Verstöße haben die folgenden Merkmale:

    • Sie beziehen sich auf orgpolicy.googleapis.com.
    • Das Feld protoPayload.metadata.dryRun ist auf true gesetzt.
    • Die Einschränkung constraints/compute.managed.disableVmsWithContainerStartupAgent ist in den Details zum Verstoß enthalten.
  5. Sehen Sie sich die Informationen in den Audit-Logs an, um zu verstehen, wo und warum der eingestellte Agent weiterhin verwendet wird. Diese Informationen können Ihnen helfen, diese Arbeitslasten zu unterstützten Alternativen zu migrieren.

  6. Nachdem Sie überprüft haben, ob die Organisationsrichtlinie im Probelaufmodus wie erwartet funktioniert, können Sie die Richtlinie erzwingen, indem Sie den Erzwingungsstatus vom Probelaufmodus in den Live-Modus ändern.

Weitere Informationen zur Verwendung des Log-Explorers finden Sie unter Logs mit dem Log-Explorer ansehen.

Nächste Schritte