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.

Este documento explica 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 sua 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 serviços e APIs do Cloud de Confiance by S3NS . Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine selecionando uma das seguintes opções:

    Para usar os exemplos do Terraform nesta 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 CLI do Google Cloud.

    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 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 VM Manager e definir 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 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 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 no nível da organização ou da pasta. Por exemplo, se todos os projetos de destino estiverem contidos em uma pasta específica, conceda a função 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 projetos padrão

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
}

# 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 modo centralizado

Se não for possível modificar um blueprint de projeto principal, gerencie 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_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 escopo fixo ou dinâmico:

  • Escopo fixo. Mantenha uma lista explícita de IDs de projetos em uma variável local ou um 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. Usar 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. Importe recursos atuais. Execute terraform import para extrair os recursos google_project_service, 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 os resumos de cópia 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 sua 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, conferir 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