VM Manager organisationsweit mit Terraform einrichten

Wenn Sie einheitliche Betriebssystemkonfigurationen erzwingen und die Compliance in der gesamten Google Cloud -Ressourcenhierarchie automatisieren möchten, können Sie mit Terraform VM Manager auf Organisationsebene konfigurieren.

In diesem Dokument wird beschrieben, wie Sie mit Terraform VM Manager (OS Config API) automatisch aktivieren, allgemeine Instanzmetadaten festlegen und Betriebssystemrichtlinien für alle Zielprojekte in Ihrer Ressourcenhierarchie zuweisen.

Eine Übersicht über die für VM Manager verfügbaren Terraform-Ressourcen finden Sie unter VM Manager-Ressourcen mit Terraform bereitstellen.

Hinweis

  • Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren:

    Wenn Sie die Terraform-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung verwenden möchten, installieren und initialisieren Sie die gcloud CLI und richten Sie dann die Standardanmeldedaten für Anwendungen mit Ihren Nutzeranmeldedaten ein.

    1. Installieren Sie die Google Cloud CLI.

    2. Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

    3. Wenn Sie eine lokale Shell verwenden, erstellen Sie lokale Authentifizierungsdaten für Ihr Nutzerkonto: 

      gcloud auth application-default login

      Wenn Sie Cloud Shell verwenden, müssen Sie das nicht tun.

      Wenn ein Authentifizierungsfehler zurückgegeben wird und Sie einen externen Identitätsanbieter (IdP) verwenden, prüfen Sie, ob Sie sich mit Ihrer föderierten Identität in der gcloud CLI angemeldet haben.

    Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.

Hinweis

Erforderliche IAM-Berechtigungen

Damit VM Manager automatisch aktiviert und Betriebssystemrichtlinien mehreren Projekten zugewiesen werden können, benötigt das Hauptkonto oder Dienstkonto, mit dem Terraform ausgeführt wird, bestimmte IAM-Berechtigungen (Identity and Access Management).

Berechtigungen für das Zielprojekt

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für jedes Zielprojekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aktivieren des VM Manager-Dienstes und zum Festlegen von Projektmetadaten benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Aktivieren des VM Manager-Dienstes und zum Festlegen von Projektmetadaten erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um den VM Manager-Dienst zu aktivieren und Projektmetadaten festzulegen:

  • serviceusage.services.enable
  • compute.projects.setCommonInstanceMetadata

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Dienstkonto und benutzerdefinierte Rolle einrichten

Google empfiehlt, ein dediziertes Dienstkonto für die Ausführung Ihrer zentralisierten Terraform-Automatisierung zu erstellen.

Wenn Sie diesem Dienstkonto die erforderlichen Berechtigungen für mehrere Projekte gewähren möchten, erstellen Sie auf Organisationsebene eine benutzerdefinierte IAM-Rolle:

  1. Erstellen Sie eine benutzerdefinierte Rolle auf Organisationsebene, die serviceusage.services.enable und compute.projects.setCommonInstanceMetadata enthält.
  2. Weisen Sie Ihrem Dienstkonto die benutzerdefinierte Rolle auf der niedrigsten anwendbaren Ebene zu, z. B. auf Organisations- oder Ordnerebene. Wenn sich Ihre Zielprojekte beispielsweise alle in einem bestimmten Ordner befinden, weisen Sie die Rolle auf Ordnerebene zu.

VM-Manager mit Terraform aktivieren

Wenn Sie VM Manager aktivieren und Betriebssystemrichtlinien für mehrere Projekte zuweisen möchten, verwenden Sie einen der folgenden automatisierten Ansätze: Golden-Project-Blueprints oder zentralisierte Projektverwaltung.

Goldene Projekt-Blueprints verwenden

Wenn Ihre Organisation ein standardisiertes Terraform-Projektmodul (einen Golden Blueprint) oder einen zentral erzwungenen Mechanismus zum Bereitstellen von Projekten verwendet, fügen Sie Ihrem Projekt-Blueprint die folgenden Ressourcendefinitionen hinzu:

Wenn Sie VM Manager aktivieren möchten, fügen Sie die folgenden Dienst- und Metadatenressourcen hinzu:

# Enable the OS Config API
resource "google_project_service" "osconfig" {
  service            = "osconfig.googleapis.com"
  disable_on_destroy = false
}

# Explicitly provision the OS Config Service Agent
resource "google_project_service_identity" "osconfig_identity" {
  provider = google-beta
  project  = google_project_service.osconfig.project
  service  = "osconfig.googleapis.com"
}

# Grant the required role to the explicitly provisioned Service Agent
resource "google_project_iam_member" "osconfig_service_agent_binding" {
  project = google_project_service.osconfig.project
  role    = "roles/osconfig.serviceAgent"
  member  = "serviceAccount:${google_project_service_identity.osconfig_identity.email}"
}

# Set project metadata to enable VM Manager
resource "google_compute_project_metadata_item" "enable_osconfig" {
  key   = "enable-osconfig"
  value = "TRUE"
}

Wenn Sie Betriebssystemrichtlinien-Zuweisungen für alle VMs bereitstellen möchten, die vom Blueprint bereitgestellt werden, hängen Sie die folgende Ressource für die Richtlinienzuweisung an:

resource "google_os_config_os_policy_assignment" "base_security_policy" {
  name        = "base-security-ospolicy"
  description = "Ensure baseline security agent is installed and operational"
  location    = var.zone

  os_policies {
    id   = "no-op-policy"
    mode = "ENFORCEMENT"

    resource_groups {
      resources {
        id = "sample"
        exec {
          validate {
            interpreter = "SHELL"
            script      = "exit 100"
          }
          enforce {
            interpreter = "SHELL"
            script      = "exit 100"
          }
        }
      }
    }
  }

  os_policies {
    id   = "install-security-agent"
    mode = "ENFORCEMENT"

    resource_groups {
      resources {
        id = "install-agent"
        pkg {
          desired_state = "INSTALLED"
          apt {
            name = "security-agent"
          }
          yum {
            name = "security-agent"
          }
        }
      }
    }
  }

  instance_filter {
    all = true
  }

  rollout {
    disruption_budget {
      percent = 10
    }
    min_wait_duration = "3.5s"
  }
}

Alle Projekte zentral verwalten

Wenn das Ändern eines Golden Project-Blueprints nicht zutreffend ist, können Sie die Aktivierung von VM Manager und die Zuweisung von Betriebssystemrichtlinien für mehrere vorhandene Projekte zentral mit dem Terraform-Argument for_each verwalten.

Wenn Sie VM Manager für alle Zielprojekte aktivieren möchten, verwenden Sie das Argument for_each, um die Projektzuordnung zu durchlaufen:

resource "google_project_service" "osconfig" {
  for_each           = var.target_projects
  project            = each.key
  service            = "osconfig.googleapis.com"
  disable_on_destroy = false
}

resource "google_project_service_identity" "osconfig_identity" {
  provider = google-beta
  for_each = var.target_projects
  project  = google_project_service.osconfig[each.key].project
  service  = "osconfig.googleapis.com"
}

resource "google_project_iam_member" "osconfig_service_agent_binding" {
  for_each = var.target_projects
  project  = google_project_service.osconfig[each.key].project
  role     = "roles/osconfig.serviceAgent"
  member   = "serviceAccount:${google_project_service_identity.osconfig_identity[each.key].email}"
}

resource "google_compute_project_metadata_item" "enable_osconfig" {
  for_each = var.target_projects
  project  = each.key
  key      = "enable-osconfig"
  value    = "TRUE"
}

Wenn Sie eine Betriebssystemrichtlinie projektübergreifend zuweisen möchten, definieren Sie die Richtlinienzuweisungsressource mit dem Argument for_each:

resource "google_os_config_os_policy_assignment" "observability_agent_policy" {
  for_each    = var.target_projects
  project     = each.key
  name        = "observability-agent-ospolicy"
  description = "Install Google Cloud Observability agent on CentOS VMs across target projects"
  location    = var.zone

  os_policies {
    id   = "setup-repo-and-install-package-policy"
    mode = "ENFORCEMENT"

    resource_groups {
      inventory_filters {
        os_short_name = "centos"
        os_version    = "8"
      }

      resources {
        id = "setup-repo"
        repository {
          yum {
            id           = "google-cloud-ops-agent"
            display_name = "Google Cloud Ops Agent Repository"
            base_url     = "https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el8-x86_64-all"
            gpg_keys = [
              "https://packages.cloud.google.com/yum/doc/yum-key.gpg",
              "https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg",
            ]
          }
        }
      }

      resources {
        id = "install-pkg"
        pkg {
          desired_state = "INSTALLED"
          yum {
            name = "google-cloud-ops-agent"
          }
        }
      }
    }
  }

  instance_filter {
    all = true
  }

  rollout {
    disruption_budget {
      percent = 10
    }
    min_wait_duration = "3.5s"
  }
}

Zielprojekte definieren

Sie können die var.target_projects-Karte für Ihre Terraform-Konfiguration entweder mit festem oder dynamischem Umfang bereitstellen:

  • Fester Umfang: Führen Sie eine explizite Liste von Projekt-IDs in einer lokalen Variablen oder einer externen Datendatei. Bei einem festen Bereich müssen Sie die Liste aktualisieren, wenn Sie Projekte erstellen oder löschen.

  • Dynamischer Bereich: Zielprojekte anhand von Regeln für die Ressourcenhierarchie ermitteln (z. B. alle Projekte innerhalb einer Organisation oder eines Ordners). Sie können Projekte mit der Datenquelle google_projects abfragen:

     data "google_projects" "in_folder" {
 filter = "parent.id:${local.folder_id}"
 }

    Wenn Sie Ausnahmen verarbeiten möchten, filtern Sie Projekte heraus, die bestimmte Ausschlusslabels enthalten. Sie können auch externe Skripts mit local_exec ausführen, die Google Cloud CLI-Befehle (z. B. gcloud asset search-all-resources) zum Generieren dynamischer Ziellisten ausführen.

Zustandslosen automatisierten Workflow einrichten

Wenn Sie dynamische Bereiche verwenden, ändert sich die Liste der Zielprojekte ständig. Wenn Sie eine standardmäßige persistente Terraform-Zustandsdatei verwenden, müssen Sie neue Ressourcen manuell importieren und gelöschte Projekte aus dem Zustand entfernen.

Wenn Sie die dynamische Bereichsdefinition effizient verwalten möchten, implementieren Sie einen zustandslosen automatisierten Workflow mit Cloud Build:

  1. Initialisieren Sie Terraform. Führen Sie terraform init mit einem temporären, nichtflüchtigen lokalen Backend aus.
  2. Zielprojekte entdecken: Generiere die aktuelle Liste der Zielprojekte basierend auf deinen dynamischen Bereichskriterien.
  3. Vorhandene Ressourcen importieren: Führen Sie terraform import aus, um vorhandene google_project_service-, google_project_service_identity-, google_project_iam_member-, google_compute_project_metadata_item- und google_os_config_os_policy_assignment-Ressourcen in den lokalen Status zu übernehmen.
  4. Konfiguration anwenden. Führen Sie Standard-Terraform-Befehle (terraform plan und terraform apply) aus und übergeben Sie die ermittelte Projektliste an Ihre Deklarationen.
  5. Laufartefakte speichern: Optional können Sie Planausgaben, Status-Snapshots und Zusammenfassungen von Kopien zur Überprüfung in einem Cloud Storage-Bucket speichern.

Planen Sie die Ausführung Ihrer Cloud Build-Pipeline in regelmäßigen Abständen (z. B. täglich oder wöchentlich), um Konfigurationsabweichungen automatisch zu erkennen und die Compliance in Ihrer gesamten Organisation zu erzwingen.

VM Manager-Status auf Organisationsebene ansehen

Nachdem Sie VM Manager in Ihrer Organisation eingerichtet haben, können Sie Berichte zum Aktivierungs- und Betriebssystemstatus für alle Projekte in Ihrer Hierarchie aufrufen. Wenn Sie Cloud Asset Inventory-Daten nach BigQuery exportieren, können Sie SQL-Abfragen ausführen, um zu prüfen, ob VM Manager aktiviert ist, die Versionen des OS Config-Agents zu prüfen und Betriebssystemdetails für alle Projekte in Ihrer Organisation zu untersuchen.

Informationen zum Exportieren von Daten und zum Ausführen von Statusberichtabfragen finden Sie unter VM Manager-Status für Ihre Organisation mit Cloud Asset Inventory und BigQuery aufrufen.

Nächste Schritte