Restrições gerenciadas

As restrições gerenciadas são políticas da organização predefinidas, criadas em uma plataforma moderna, que oferecem controle centralizado e programático sobre os recursos do Compute Engine. Eles incluem suporte integrado para ferramentas de implantação segura como Simulador de política e o teste a seco.

As restrições gerenciadas são identificadas pelo prefixo compute.managed.* e servem como substituição direta para as restrições legadas compute.*.

Vantagens

  • Implantação e monitoramento seguros: implemente políticas com ferramentas completas, controle de mudanças mais rápido e implantação gradual usando recursos de simulação e simulação.
  • Registro consistente: impõe uniformidade nas mensagens de registro e de erro, simplificando o monitoramento centralizado e agilizando as auditorias.

Herança de políticas

As políticas da organização definidas em um recurso são herdadas pelos descendentes dele na hierarquia de recursos. Por exemplo, se você aplicar uma política a uma pasta,o Google Cloud vai aplicá-la a todos os projetos dessa pasta.

Preços

O serviço de políticas da organização, incluindo políticas predefinidas (legadas), gerenciadas e personalizadas, é oferecido sem custos financeiros.

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 Google Cloud . Para executar código ou exemplos em um ambiente de desenvolvimento local, faça a autenticação no Compute Engine com um destes métodos:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Instale a CLI do Google Cloud. Após a instalação, inicialize a CLI do Google Cloud executando o seguinte comando:

      gcloud init

      Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.

    2. Set a default region and zone.

    REST

    Para usar as amostras da API REST desta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

      Instale a CLI do Google Cloud. Após a instalação, inicialize a CLI do Google Cloud executando o seguinte comando:

      gcloud init

      Ao usar um provedor de identidade (IdP) externo, primeiro faça login na gcloud CLI com sua identidade federada.

    Saiba mais em Autenticar para usar REST na documentação de autenticação do Google Cloud .

Funções exigidas

Para receber as permissões necessárias para gerenciar políticas da organização com restrições gerenciadas, peça ao administrador que conceda a você os seguintes papéis do IAM:

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 gerenciar políticas da organização com restrições gerenciadas. 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 gerenciar políticas da organização com restrições gerenciadas:

  • orgpolicy.constraints.list
  • orgpolicy.policies.create
  • orgpolicy.policies.delete
  • orgpolicy.policies.list
  • orgpolicy.policies.update
  • orgpolicy.policy.get
  • orgpolicy.policy.set
  • Para testar as restrições:
    • compute.instances.create no projeto
    • Usar uma imagem personalizada para criar a VM: compute.images.useReadOnly na imagem
    • Utilizar um snapshot para criar a VM: compute.snapshots.useReadOnly no snapshot
    • Usar um modelo de instância para criar a VM: compute.instanceTemplates.useReadOnly no modelo de instância
    • Atribuir uma rede legada à VM: compute.networks.use no projeto
    • Especificar um endereço IP estático para a VM: compute.addresses.use no projeto
    • Atribuir um endereço IP externo à VM ao usar uma rede legada: compute.networks.useExternalIp no projeto
    • Especificar uma sub-rede para a VM: compute.subnetworks.use no projeto ou na sub-rede escolhida
    • Atribuir um endereço IP externo à VM ao usar uma rede VPC: compute.subnetworks.useExternalIp no projeto ou na sub-rede escolhida
    • Definir os metadados da instância da VM: compute.instances.setMetadata no projeto
    • Definir tags para a VM: compute.instances.setTags na VM
    • Definir rótulos para a VM: compute.instances.setLabels na VM
    • Definir uma conta de serviço para a VM usar: compute.instances.setServiceAccount na VM
    • Criar um disco para a VM: compute.disks.create no projeto
    • Anexar um disco atual no modo somente leitura ou de leitura e gravação: compute.disks.use no disco
    • Anexar um disco atual no modo somente leitura: compute.disks.useReadOnly no disco

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

Restrições gerenciadas disponíveis

As seguintes restrições gerenciadas de política da organização estão disponíveis para o Compute Engine:

Restrição Descrição
Configurações de criptografia de anexo da VLAN permitidas

Essa restrição de lista define as configurações de criptografia permitidas para novos anexos da VLAN.
Por padrão, os anexos da VLAN podem usar qualquer configuração de criptografia.
Defina IPSEC como o valor permitido para aplicar à criação apenas de anexos da VLAN criptografados.

constraints/compute.managed.allowedVlanAttachmentEncryption
Bloquear recursos de prévia do Compute Engine

Essa restrição garante que os recursos de prévia sejam bloqueados, a menos que ela seja explicitamente permitida. Depois de definir como "Permitir", você pode controlar quais recursos de prévia podem ser ativados ou desativados individualmente para seu projeto. Somente os recursos de prévia ativados podem ser acessados no projeto. Desativar a política depois não muda o status dos recursos de prévia individual já definidos, e eles podem ser desativados individualmente. Essa restrição se aplica apenas aos recursos da API Alpha do Compute.

constraints/compute.managed.blockPreviewFeatures
Desativar virtualização aninhada da VM

[Prévia pública] Essa restrição booleana desativa a virtualização aninhada acelerada por hardware de todas as VMs do Compute Engine pertencentes à organização, ao projeto ou à pasta em que essa restrição está definida como True.
Por padrão, a virtualização aninhada acelerada por hardware é permitida em todas as VMs do Compute Engine em execução no Intel Haswell ou em plataformas de CPU mais recentes.

constraints/compute.managed.disableNestedVirtualization
Restringir a ativação de metadados de acesso à porta serial da VM

Prévia: essa restrição impede que a chave de metadados "serial-port-enable" seja definida como "true" para VMs do Compute Engine na organização, no projeto ou na pasta em que a restrição é aplicada. Por padrão, o acesso à porta serial pode ser ativado por VM, por zona ou por projeto usando essa chave de metadados. Para permitir o acesso à porta serial para VMs específicas, é possível isentar essas VMs da política usando tags e regras condicionais.
Importante: a aplicação dessa restrição não afeta as VMs atuais em que "serial-port-enable" já está definido como "true". Elas vão manter o acesso, a menos que os metadados sejam atualizados.

constraints/compute.managed.disableSerialPortAccess
Desativar o registro da porta serial da VM para o Stackdriver

[Prévia pública] Quando aplicada, essa restrição desativa a geração de registros de porta serial no Stackdriver das VMs do Compute Engine.
Por padrão, a geração de registros de porta serial das VMs do Compute Engine fica desativada e pode ser ativada seletivamente por VM ou por projeto com o uso de atributos de metadados. A desativação da geração de registros de porta serial pode impedir o funcionamento correto de alguns serviços que dependem deles, como os clusters do Google Kubernetes Engine. Antes de aplicar a restrição, verifique se os produtos no seu projeto não dependem desses registros. É possível permitir que instâncias de VM específicas usem a geração de registros da porta serial. Primeiro, aplique tags para marcar as instâncias e, em seguida, use regras condicionais com base nos valores de tag para definir corretamente o escopo dessas instâncias fora da aplicação.

constraints/compute.managed.disableSerialPortLogging
Restringe o uso do DNS interno global (gDNS) para projetos que têm uma configuração de DNS ZonalOnly.

[Prévia pública] Quando aplicada, essa restrição limita o uso do gDNS. Essa restrição desativa a criação de VMs do gDNS e a atualização de VMs para usar o gDNS. A reversão de um projeto zDNS para gDNS não será bloqueada, mas vai resultar na aplicação de violações da política durante as invocações subsequentes da API Instance.

constraints/compute.managed.disallowGlobalDns
Exigir configuração do SO

[Prévia pública] Quando aplicada, essa restrição exige a ativação do VM Manager (configuração do SO) em todos os novos projetos. Nos projetos novos e atuais, essa restrição impede atualizações de metadados que desativem o VM Manager no nível do projeto, da zona do projeto ou da instância. É possível permitir que instâncias de VM específicas desativem o VM Manager. Primeiro, aplique tags para marcar as instâncias e, em seguida, use regras condicionais com base nos valores de tag para definir corretamente o escopo dessas instâncias fora da aplicação.

constraints/compute.managed.requireOsConfig
Requer login do SO

[Prévia pública] Quando aplicada, essa restrição exige a ativação do Login do SO em todos os projetos recém-criados. Nos projetos novos e atuais, essa restrição impede atualizações de metadados que desativem o login do SO no nível do projeto, da zona do projeto ou da instância. É possível permitir que instâncias de VM específicas desativem o login do SO. Primeiro, aplique tags para marcar as instâncias e, em seguida, use regras condicionais com base nos valores de tag para definir corretamente o escopo dessas instâncias fora da aplicação.

constraints/compute.managed.requireOsLogin
Restringe o uso do encaminhamento de protocolo

Com essa restrição, é possível restringir os tipos de implantações de encaminhamento de protocolo (internas ou externas) que podem ser criadas na sua organização. Para configurar a restrição, especifique uma lista de permissões do tipo de implantação de encaminhamento de protocolo que será permitida. A lista de permissões só pode incluir os seguintes valores:

  • INTERNAL
  • EXTERNAL
. Por exemplo, se a lista de permissões estiver definida como "INTERNAL", seus usuários só poderão configurar o encaminhamento de protocolo interno. Ou seja, todas as regras de encaminhamento associadas a instâncias de destino são restritas ao esquema de balanceamento de carga INTERNAL e precisam usar apenas endereços IP internos.

constraints/compute.managed.restrictProtocolForwardingCreationForTypes
Restringir o encaminhamento IP da VM

[Prévia pública] Essa restrição define se as instâncias de VM do Compute Engine podem ativar o encaminhamento de IP. Por padrão, se nenhuma política for especificada, qualquer VM poderá ativar o encaminhamento de IP em qualquer rede virtual. Se aplicada, essa restrição vai negar a criação ou atualização de instâncias de VM com o encaminhamento de IP ativado. É possível permitir que instâncias de VM específicas ativem o encaminhamento de IP. Primeiro, aplique tags para marcar as instâncias e, em seguida, use regras condicionais com base nos valores de tag para definir corretamente o escopo dessas instâncias fora da aplicação.

constraints/compute.managed.vmCanIpForward
Restringir IPs externos para instâncias de VM

[Prévia pública] Essa restrição define se as instâncias de VM do Compute Engine podem usar endereços IP externo IPv4. Por padrão, todas as instâncias de VM podem usar endereços IP externos. Se aplicada, essa restrição vai negar a criação ou atualização de instâncias de VM com endereços IP externo IPv4. Essa restrição não limita o uso de endereços IP externo IPv6. É possível permitir que instâncias de VM específicas usem endereços IP IPv4 externos. Primeiro, aplique tags para marcar as instâncias e, em seguida, use regras condicionais com base nos valores de tag para definir corretamente o escopo dessas instâncias fora da aplicação.

constraints/compute.managed.vmExternalIpAccess

Avaliação hierárquica de metadados

As restrições gerenciadas que dependem de chaves de metadados predefinidas, como login do SO ou acesso à porta serial, oferecem suporte à avaliação hierárquica. Quando o Compute Engine avalia essas restrições, ele verifica os valores de metadados definidos no nível da instância de VM, do projeto ou da zona.

Definir valores de metadados no nível do projeto ou da zona permite gerenciar instâncias de VM em grande escala. No entanto, a aplicação de restrições ocorre apenas durante a criação de instâncias de VM ou chamadas de API de atualização. Assim, as mudanças nos metadados do projeto ou da zona afetam a conformidade de uma instância de VM com a restrição somente quando essa instância é criada ou atualizada.

Restrições e níveis com base em metadados

Restrição Chave de metadados Níveis da hierarquia de metadados
compute.managed.disableSerialPortAccess serial-port-enable Projeto, zonal, instância
compute.managed.requireOsLogin enable-oslogin Projeto, zonal, instância
compute.managed.disableGuestAttributesAccess enable-guest-attributes Projeto, zonal, instância
compute.managed.requireOsConfig enable-osconfig Projeto, zonal, instância
compute.managed.disallowGlobalDns VmDnsSetting Projeto, instância

Lançamento seguro: o ciclo de vida da política

Para evitar interrupções no serviço ao implementar gradualmente novas restrições, o Google recomenda que você implemente restrições gerenciadas seguindo estas etapas:

Analisar com o Simulador de política

Antes de aplicar uma política, use o Simulador de política para ver quais recursos atuais violam a política. Siga estas etapas:

  1. No console do Google Cloud , acesse a página Políticas da organização.

    Acesse as políticas da organização

  2. Na barra de filtro, pesquise sua restrição e clique no nome dela para acessar a página Detalhes da política.

  3. Clique em Testar mudanças para gerar um relatório de simulação.

  4. As mudanças nos metadados hierárquicos podem levar algumas horas para aparecer no relatório de simulação de restrições nas configurações de metadados da VM.

  5. Analise o relatório para reconfigurar recursos fora de conformidade ou pedir isenções.

Validar com simulação

O modo de teste registra violações no Cloud Logging, mas não aplica restrições.

Para testar uma restrição, use o comando gcloud org-policies set-policy da seguinte maneira:

  1. Crie um arquivo YAML de política (por exemplo, dry-run-policy.yaml) com um dryRunSpec:

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
    dryRunSpec:
      rules:
      - enforce: true
    

    Substitua PROJECT_ID pela ID do seu projeto.

  2. Aplique a política:

    gcloud org-policies set-policy dry-run-policy.yaml
    

Aplicação total

Depois de simular e testar a política, é possível aplicá-la a um recurso. As mudanças nas políticas podem levar até 15 minutos para serem propagadas em todos os sistemas do Google Cloud .

Testar a aplicação de restrições

Depois de definir uma política, é possível verificar a aplicação usando a CLI gcloud. Por exemplo, para testar a restrição compute.managed.requireOsLogin, siga estas etapas:

  1. Liste as políticas atuais para confirmar sua configuração:

    gcloud org-policies list --project=PROJECT_ID
    
  2. Aplique a política de aplicação usando um arquivo YAML:

    gcloud org-policies set-policy enforce_managed_constraint.yaml
    
  3. Verifique a aplicação chamando uma API de mutação. A tentativa de criar uma instância de VM com metadados não compatíveis deve falhar:

    gcloud compute instances create VM_NAME \
        --machine-type=MACHINE_TYPE \
        --image-family=IMAGE_FAMILY \
        --image-project=IMAGE_PROJECT \
        --metadata=enable-oslogin=false
    

    Substitua:

    • VM_NAME: o nome da nova instância de VM.
    • MACHINE_TYPE: um tipo de máquina válido, por exemplo, e2-micro.
    • IMAGE_FAMILY: uma família de imagens válida, por exemplo, debian-11.
    • IMAGE_PROJECT: o projeto da família de imagens, por exemplo, debian-cloud.
  4. Leia a mensagem de erro. Você vai receber uma negação indicando a restrição específica violada: ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Operation denied by org policy: [constraints/compute.managed.requireOsLogin]

Exceções condicionais com tags

É possível usar tags para conceder exceções a recursos específicos com base nas necessidades da empresa. Neste exemplo, usamos uma tag chamada osLoginOptional para identificar recursos isentos da exigência de Login do SO. Quando você vincula essa tag com um valor de true a um recurso, a política da organização permite que esse recurso específico exista sem o login do SO ativado, mesmo que a política permaneça estritamente aplicada ao restante do seu ambiente.

Para conceder uma exceção usando tags, siga estas etapas:

  1. Crie uma tag: use a CLI gcloud para criar uma chave e um valor de tag.

    1. Crie a chave da tag:

      gcloud resource-manager tags keys create osLoginOptional \
          --parent=organizations/ORGANIZATION_ID
      
    2. Crie o valor da tag:

      gcloud resource-manager tags values create true \
          --parent=organizations/ORGANIZATION_ID/tagKeys/osLoginOptional
      

    Substitua ORGANIZATION_ID pelo ID da organização.

  2. Vincule a tag a um recurso. Para isentar um projeto da restrição compute.managed.requireOsLogin, vincule a tag osLoginOptional=true ao projeto usando o comando gcloud resource-manager tags bindings create:

    gcloud resource-manager tags bindings create \
        --tag-value=ORGANIZATION_ID/osLoginOptional/true \
        --parent=//cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
        --location=global
    

    Substitua ORGANIZATION_ID pelo ID da organização e PROJECT_ID pelo ID do projeto que você quer isentar.

    Para saber como vincular tags a outros recursos, consulte Vincular uma tag a um recurso.

  3. Atualize a política: crie ou atualize o arquivo YAML da política (por exemplo, policy.yaml) para incluir a regra condicional.

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
    spec:
      rules:
      - condition:
          expression: "resource.matchTag('ORGANIZATION_ID/osLoginOptional', 'true')"
        enforce: false
      - enforce: true
    

    Substitua:

    • PROJECT_ID: o ID do projeto.
    • ORGANIZATION_ID: o código da sua organização.
  4. Aplique a política: use o seguinte comando da CLI gcloud para ativar a configuração:

    gcloud org-policies set-policy policy.yaml
    

Migração de restrições legadas

Ao migrar, observe que as restrições gerenciadas melhoram, mas não replicam exatamente o comportamento das políticas legadas. As restrições gerenciadas oferecem mais previsibilidade porque verificam violações apenas durante solicitações de API que criam ou modificam recursos. Se uma solicitação violar uma restrição, a chamada de API vai falhar com um erro claro. Isso é diferente das políticas legadas, que podiam ser aplicadas em várias etapas de uma operação ou usadas como atributos de recursos, tornando o comportamento de aplicação menos previsível.

Ao migrar de uma restrição legada compute.* para um equivalente moderno compute.managed.*, siga estas etapas para evitar o aperto não intencional das restrições:

  1. Descubra: identifique a nova alternativa de restrição gerenciada.
  2. Analise e valide: use o Simulador de política e a simulação, conforme descrito anteriormente.
  3. Impor restrição gerenciada: aplique a nova restrição gerenciada junto com a legada.
  4. Exclua as políticas legadas:
    • Acesse o Inventário de recursos no console do Google Cloud e filtre por orgpolicy.Policy e o nome da restrição legada para identificar todas as políticas que usam a restrição legada.
    • Exclua todas as políticas que usam a restrição legada. A exclusão de uma política a redefine para o comportamento padrão gerenciado pelo Google para essa restrição.

A seguir