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 Cloud de Confiance by S3NS hierarquia de recursos, use o Terraform para configurar o VM Manager no nível da organização.

Este documento explica como usar o Terraform para ativar automaticamente o VM Manager (API OS Config), definir metadados comuns da instância e atribuir políticas do SO a 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

  • Configure a autenticação, caso ainda não tenha feito isso. Com isso, você confirma sua identidade para acesso a Cloud de Confiance by S3NS serviços e APIs do. Para executar código ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine com uma destas opções:

    Para usar os exemplos do Terraform desta página em um ambiente de desenvolvimento local, instale e inicialize a CLI gcloud e configure o Application Default Credentials com suas credenciais de usuário.

    1. Instale a Google Cloud CLI.

    2. Configure a CLI gcloud para usar sua identidade federada.

      Para mais informações, consulte Fazer login na CLI gcloud com sua identidade federada.

    3. Crie credenciais de autenticação local para sua conta de usuário: 

      gcloud auth application-default login

      Se um erro de autenticação for retornado e você estiver usando um provedor de identidade (IdP) externo, confirme se você fez login na CLI gcloud com sua identidade federada.

    Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento local.

Antes de começar

Permissões do IAM obrigatórias

Para ativar automaticamente o VM Manager e atribuir políticas do SO a vários projetos, a principal ou 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 do VM Manager e definir os metadados do projeto. Para acessar as permissões exatas que são 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 papéis personalizados ou outros papéis predefinidos.

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

O Google recomenda que você crie 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 escopo aplicável mais baixo, como a organização ou a pasta. Por exemplo, se todos os projetos de destino estiverem contidos 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 a vários projetos, use uma das seguintes abordagens automatizadas: projetos de referência ou gerenciamento centralizado de projetos.

Usar projetos de referência

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

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íticas do SO em todas as VMs provisionadas pelo projeto de referência, anexe 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 modo centralizado

Se a modificação de um projeto de referência não for aplicável, você poderá gerenciar centralmente a ativação do VM Manager e as atribuições de políticas do 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 projetos em uma variável local ou arquivo de dados externo. O escopo fixo exige que você atualize a lista sempre que criar ou excluir projetos.

  • Escopo dinâmico. Descubra 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 processar 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 com eficiência, 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 persistente.
  2. Descubra projetos de destino. Gere a lista atual de projetos de destino com base nos critérios de escopo dinâmico.
  3. Importe recursos atuais. Execute terraform import para extrair os recursos existentes google_project_service, google_project_service_identity, google_project_iam_member, google_compute_project_metadata_item e google_os_config_os_policy_assignment para o estado local.
  4. Aplique a configuração. Execute comandos padrão do Terraform (terraform plan e terraform apply), transmitindo a lista de projetos descoberta às declarações.
  5. Armazene artefatos de execução. Opcionalmente, salve as saídas do plano, os snapshots de estado e os resumos de cópia em um bucket do Cloud Storage para auditoria.

Programe o pipeline do Cloud Build para ser executado periodicamente (por exemplo, diariamente ou semanalmente) para detectar automaticamente a variação de configuração e aplicar a conformidade em toda a organização.

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

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

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

A seguir