Configurar o VM Manager em uma organização usando o Terraform

Para aplicar configurações consistentes do sistema operacional e automatizar a conformidade em toda a hierarquia de recursos do Cloud de Confiance by S3NS , use o Terraform para configurar o VM Manager no nível da organização.

Neste documento, explicamos como usar o Terraform para ativar automaticamente o VM Manager (API OS Config), definir metadados de instância comuns e atribuir políticas de SO em todos os projetos de destino na hierarquia de recursos.

Para uma visão geral dos recursos do Terraform disponíveis para o VM Manager, consulte Provisionar recursos do VM Manager usando o Terraform.

Antes de começar

Antes de começar

Permissões do IAM obrigatórias

Para ativar automaticamente o VM Manager e atribuir políticas de SO em vários projetos, o principal ou a conta de serviço que executa o Terraform precisa de permissões específicas do Identity and Access Management (IAM).

Permissões do projeto de destino

Para receber as permissões necessárias para ativar o serviço do VM Manager e definir os metadados do projeto, peça ao administrador para conceder a você os seguintes papéis do IAM em cada projeto de destino:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para ativar o serviço VM Manager e definir metadados do projeto. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para ativar o serviço do VM Manager e definir os metadados do projeto:

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

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Configuração da conta de serviço e do papel personalizado

O Google recomenda criar uma conta de serviço dedicada para executar a automação centralizada do Terraform.

Para conceder as permissões necessárias a essa conta de serviço em vários projetos, crie um papel personalizado do IAM no nível da organização:

  1. Crie um papel personalizado no nível da organização que inclua serviceusage.services.enable e compute.projects.setCommonInstanceMetadata.
  2. Conceda o papel personalizado à sua conta de serviço no menor escopo aplicável, como no nível da organização ou da pasta. Por exemplo, se os projetos de destino estiverem todos em uma pasta específica, conceda o papel no nível da pasta.

Ativar o VM Manager usando o Terraform

Para ativar o VM Manager e atribuir políticas do SO em vários projetos, use uma das seguintes abordagens automatizadas: modelos de projeto principal ou gerenciamento centralizado de projetos.

Usar blueprints de projetos de referência

Se a organização usa um módulo de projeto do Terraform padronizado (um blueprint de ouro) ou um mecanismo aplicado centralmente para provisionar projetos, adicione as seguintes definições de recursos ao blueprint do projeto:

Para ativar o VM Manager, inclua os seguintes recursos de serviço e metadados:

# 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"
}

Para implantar atribuições de política de SO em todas as VMs provisionadas pelo blueprint, adicione o seguinte recurso de atribuição de política:

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"
  }
}

Gerenciar todos os projetos de forma centralizada

Se não for possível modificar um blueprint de projeto de referência, gerencie de forma centralizada a ativação do VM Manager e as atribuições de políticas de SO em vários projetos usando o argumento for_each do Terraform.

Para ativar o VM Manager em projetos de destino, use o argumento for_each para iterar no mapa do projeto:

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"
}

Para atribuir uma política do SO a projetos de destino, defina o recurso de atribuição de política com o argumento 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"
  }
}

Definir projetos de destino

É possível fornecer o mapa var.target_projects à configuração do Terraform usando o escopo fixo ou dinâmico:

  • Escopo fixo. Mantenha uma lista explícita de IDs de projeto em uma variável local ou em um arquivo de dados externo. O escopo fixo exige que você atualize a lista sempre que criar ou excluir projetos.

  • Escopo dinâmico. Descobrir projetos de destino com base em regras de hierarquia de recursos (por exemplo, todos os projetos em uma organização ou pasta). É possível consultar projetos usando a fonte de dados google_projects:

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

    Para lidar com exceções, filtre os projetos que contêm rótulos de exclusão específicos. Também é possível executar scripts externos usando local_exec que executam comandos da Google Cloud CLI (como gcloud asset search-all-resources) para gerar listas de destino dinâmicas.

Estabelecer um fluxo de trabalho automatizado sem estado

Quando você usa o escopo dinâmico, a lista de projetos de destino muda constantemente. O uso de um arquivo de estado persistente padrão do Terraform exige esforço manual para importar novos recursos e remover projetos excluídos do estado.

Para gerenciar o escopo dinâmico de maneira eficiente, implemente um fluxo de trabalho automatizado sem estado usando o Cloud Build:

  1. Inicialize o Terraform. Execute terraform init usando um back-end local temporário e não permanente.
  2. Descubra projetos de destino. Gere a lista atual de projetos de destino com base nos seus critérios de escopo dinâmico.
  3. Importar recursos. Execute terraform import para extrair os recursos google_project_service, google_project_service_identity, google_project_iam_member, google_compute_project_metadata_item e google_os_config_os_policy_assignment atuais para o estado local.
  4. Aplicar configuração. Execute comandos padrão do Terraform (terraform plan e terraform apply), transmitindo a lista de projetos descoberta às suas declarações.
  5. Armazene artefatos de execução. Se quiser, salve as saídas do plano, os snapshots de estado e as cópias de resumos em um bucket do Cloud Storage para auditoria.

Programe a execução periódica do pipeline do Cloud Build (por exemplo, diária ou semanalmente) para detectar automaticamente o desvio de configuração e garantir a conformidade em toda a organização.

Ver o status do VM Manager no nível da organização

Depois de configurar o VM Manager em toda a organização, é possível conferir relatórios de status de ativação e do sistema operacional em todos os projetos da hierarquia. Ao exportar dados do Inventário de recursos do Cloud para o BigQuery, é possível executar consultas SQL para verificar se o VM Manager está ativado, verificar as versões do agente de configuração do SO e inspecionar os detalhes do sistema operacional em todos os projetos da sua organização.

Para saber como exportar dados e executar consultas de relatórios de status, consulte Ver o status do VM Manager na sua organização usando o Inventário de recursos do Cloud e o BigQuery.

A seguir