VM Manager organisationsweit mit Terraform einrichten

Wenn Sie einheitliche Betriebssystemkonfigurationen erzwingen und die Compliance in der Cloud de Confiance by S3NS Ressourcenhierarchie automatisieren möchten, konfigurieren Sie VM Manager mit Terraform auf Organisationsebene.

In diesem Dokument wird erläutert, 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 Cloud de Confiance by S3NS Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich bei Compute Engine authentifizieren, indem Sie eine der folgenden Optionen auswählen:

    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. Konfigurieren Sie die gcloud CLI für die Verwendung Ihrer föderierten Identität.

      Weitere Informationen finden Sie unter Mit Ihrer föderierten Identität in der gcloud CLI anmelden.

    3. Lokale Anmeldedaten zur Authentifizierung für Ihr Nutzerkonto erstellen: 

      gcloud auth application-default login

      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

Wenn Sie VM Manager automatisch aktivieren und Betriebssystemrichtlinien für mehrere Projekte zuweisen möchten, benötigt das Prinzipal oder Dienstkonto, das Terraform ausführt, bestimmte IAM-Berechtigungen (Identity and Access Management).

Berechtigungen für Zielprojekte

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, die erforderlich sind:

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 Dienst konto zu erstellen, um Ihre zentralisierte Terraform-Automatisierung auszuführen.

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

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

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-Blaupausen oder zentralisierte Projektverwaltung.

Golden-Project-Blaupausen verwenden

Wenn Ihre Organisation ein standardisiertes Terraform-Projektmodul (eine Golden-Blueprint) oder einen zentral erzwungenen Mechanismus zum Bereitstellen von Projekten verwendet, fügen Sie Ihrer 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 Zuweisungen von Betriebssystemrichtlinien für alle VMs bereitstellen möchten, die mit der Blueprint bereitgestellt wurden, fügen Sie die folgende Ressource für die Richtlinienzuweisung hinzu:

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 die Änderung einer Golden-Project-Blueprint nicht anwendbar ist, können Sie die Aktivierung von VM Manager und die Zuweisungen von Betriebssystemrichtlinien für mehrere vorhandene Projekte zentral verwalten. Verwenden Sie dazu das Terraform-Argument for_each.

Wenn Sie VM Manager für Zielprojekte aktivieren möchten, verwenden Sie das Argument for_each, um Ihre 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 für Zielprojekte zuweisen möchten, definieren Sie die Ressource für die Richtlinienzuweisung 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 Zuordnung var.target_projects Ihrer Terraform-Konfiguration entweder mit fester oder dynamischer Bereichsdefinition bereitstellen:

  • Feste Bereichsdefinition Pflegen Sie eine explizite Liste von Projekt-IDs in einer lokalen Variablen oder einer externen Datendatei. Bei der festen Bereichsdefinition müssen Sie die Liste aktualisieren, wenn Sie Projekte erstellen oder löschen.

  • Dynamische Bereichsdefinition Zielprojekte werden anhand von Regeln für die Ressourcenhierarchie ermittelt (z. B. alle Projekte in einer Organisation oder einem Ordner). Sie können Projekte mit der Datenquelle google_projects abfragen:

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

    Um Ausnahmen zu verarbeiten, 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) verwenden, um dynamische Ziellisten zu generieren.

Zustandslosen automatisierten Workflow einrichten

Wenn Sie die dynamische Bereichsdefinition verwenden, ändert sich die Liste der Zielprojekte ständig. Bei Verwendung einer standardmäßigen nichtflüchtigen Terraform-Statusdatei müssen neue Ressourcen manuell importiert und gelöschte Projekte aus dem Status entfernt werden.

Um die dynamische Bereichsdefinition effizient zu verwalten, implementieren Sie einen zustandslosen automatisierten Workflow mit Cloud Build:

  1. Terraform initialisieren Führen Sie terraform init mit einem temporären, nichtflüchtigen lokalen Backend aus.
  2. Zielprojekte ermitteln Generieren Sie die aktuelle Liste der Zielprojekte basierend auf Ihren dynamischen Bereichsdefinitionskriterien.
  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 die Standard-Terraform-Befehle (terraform plan und terraform apply) aus und übergeben Sie die ermittelte Projektliste an Ihre Deklarationen.
  5. Ausführungsartefakte speichern Optional können Sie Planausgaben, Statussnapshots und Kopienzusammenfassungen zur Prü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 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 ansehen. 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 OS Config-Agent-Versionen 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 ansehen.

Nächste Schritte