Gerenciar recursos do Cloud Load Balancing usando restrições personalizadas

Nesta página, mostramos como usar restrições personalizadas do serviço de políticas da organização para restringir operações específicas nos seguintes recursos do Cloud de Confiance by S3NS :

• compute.googleapis.com/BackendBucket
• compute.googleapis.com/BackendService
• compute.googleapis.com/ForwardingRule
• compute.googleapis.com/HealthCheck
• compute.googleapis.com/NetworkEndpointGroup
• networkservices.googleapis.com/ServiceLbPolicy
• compute.googleapis.com/SslPolicy
• compute.googleapis.com/TargetInstance
• compute.googleapis.com/TargetPool
• compute.googleapis.com/TargetTcpProxy
• compute.googleapis.com/TargetSslProxy
• compute.googleapis.com/TargetHttpProxy
• compute.googleapis.com/TargetHttpsProxy
• compute.googleapis.com/TargetGrpcProxy
• compute.googleapis.com/UrlMap

Para saber mais sobre políticas da organização, consulte Políticas personalizadas da organização.

Sobre políticas da organização e restrições

O serviço de políticas da organização do Cloud de Confiance oferece controle centralizado e programático sobre os recursos da sua organização. Um administrador de políticas da organização pode definir políticas da organização, ou seja, conjuntos de restrições que se aplicam aos recursos doCloud de Confiance e aos elementos que descendem dele na hierarquia de recursos doCloud de Confiance by S3NS . É possível aplicar políticas da organização no nível de projetos, de pastas ou da organização.

Uma política da organização oferece restrições gerenciadas e integradas para vários serviços do Cloud de Confiance . No entanto, para ter controle mais granular e personalizável sobre os campos específicos restritos nas políticas da organização, também é possível criar restrições personalizadas e usá-las nessas políticas.

Herança de políticas

Por padrão, as políticas da organização são herdadas pelos elementos que descendem dos recursos em que elas são aplicadas. Por exemplo, se você aplicar uma política a uma pasta, o Cloud de Confiance vai aplicá-la a todos os projetos dessa pasta. Para saber mais sobre esse comportamento e como alterá-lo, consulte Regras de avaliação de hierarquia.

Vantagens

• Gerenciamento de custos: use políticas personalizadas da organização para restringir a frequência da sondagem de verificação de integridade.

• Segurança, compliance e governança: é possível usar políticas personalizadas da organização para aplicar políticas. Exemplo:

  • Para aplicar o uso de protocolos ou intervalos de porta específicos de verificação de integridade
  • Para não permitir determinados protocolos de tráfego de back-end
  • Para exigir que os buckets de back-end tenham o Cloud CDN ativado
  • Para exigir que as regras de encaminhamento usem Níveis de Serviço de Rede específicos

Limitações

• As verificações de integridade legadas (Legado global (HTTP) e Legado global (HTTPS)) não são compatíveis.

• Para recursos da política de SSL do Compute Engine, as restrições personalizadas também são aplicadas no método UPDATE.

Antes de começar

1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

   Go to project selector

2. Verify that billing is enabled for your Cloud de Confiance project.

3. Instale a CLI do Google Cloud.

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

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

5. Para inicializar a gcloud CLI, execute o seguinte comando:

   gcloud init

6. Verifique qual é o ID da organização.

Papéis necessários

Para receber as permissões necessárias a fim de gerenciar as políticas da organização, peça ao administrador para conceder a você o papel do IAM de Administrador de políticas da organização (roles/orgpolicy.policyAdmin) no recurso da organização. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Configurar uma restrição personalizada

Uma restrição personalizada é definida em um arquivo YAML pelos recursos, métodos, condições e ações compatíveis com o serviço em que você está aplicando a política da organização. As condições das restrições personalizadas são definidas usando a Common Expression Language (CEL). Para saber como criar condições em restrições personalizadas usando a CEL, consulte a seção CEL em Como criar e gerenciar restrições personalizadas.

Console

Para criar uma restrição personalizada, faça o seguinte:

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

   Acessar a página Políticas da organização

2. No seletor de projetos, selecione o projeto em que você quer definir a política da organização.
3. Clique em add Restrição personalizada.
4. Na caixa Nome de exibição, insira um nome legível para a restrição. Esse nome é usado em mensagens de erro e pode ser usado para identificação e depuração. Não use informações de identificação pessoal (PII) ou dados sensíveis em nomes de exibição, porque eles podem ser expostos em mensagens de erro. Esse campo pode ter até 200 caracteres.
5. Na caixa ID da restrição, insira o ID que você quer para a nova restrição personalizada. Uma restrição personalizada só pode conter letras (maiúsculas e minúsculas) ou números, por exemplo, custom.enforceTCPHealthCheckPort1024. Esse campo pode conter até 70 caracteres, sem contar o prefixo (custom.), por exemplo, organizations/123456789/customConstraints/custom. Não inclua PII ou dados sensíveis no ID da restrição, porque eles podem ser expostos em mensagens de erro.
6. Na caixa Descrição, insira uma descrição legível da restrição. Essa descrição é usada como uma mensagem de erro quando a política é violada. Inclua detalhes sobre o motivo da violação e como resolver o problema. Não inclua PII ou dados sensíveis na descrição, porque eles podem ser expostos em mensagens de erro. Esse campo pode conter até 2.000 caracteres.
7. Na caixa Tipo de recurso, selecione o nome do recurso REST do Cloud de Confiance que contém o objeto e o campo que você quer restringir. Por exemplo, container.googleapis.com/NodePool. A maioria dos tipos de recursos aceita até 20 restrições personalizadas. Se você tentar criar mais restrições personalizadas, a operação vai falhar.
8. Em Método de aplicação, selecione se quer aplicar a restrição em um método REST CREATE ou em ambos os métodos CREATE e UPDATE. Se você aplicar a restrição com o método UPDATE em um recurso que a viola, as mudanças nesse recurso serão bloqueadas pela política da organização, a menos que a mudança resolva a violação.

Para ver os métodos compatíveis para cada serviço, encontre o serviço em Serviços que aceitam restrições personalizadas.

9. Para definir uma condição, clique em edit Editar condição.
1. No painel Adicionar condição, crie uma condição de CEL que se refira a um recurso de serviço compatível, por exemplo, resource.management.autoUpgrade == false. Esse campo pode conter até 1.000 caracteres. Para detalhes sobre o uso da CEL, consulte Common Expression Language. Para mais informações sobre os recursos de serviço que você pode usar nas restrições personalizadas, consulte Serviços compatíveis com restrição personalizada.
2. Clique em Salvar.
10. Em Ação, selecione se você quer permitir ou negar o método avaliado quando a condição é atendida.

A ação de negação significa que a operação para criar ou atualizar o recurso será bloqueada se a condição for avaliada como verdadeira.

A ação de permissão significa que a operação para criar ou atualizar o recurso só é permitida se a condição for avaliada como verdadeira. Todos os outros casos, exceto os listados explicitamente na condição, estão bloqueados.

11. Clique em Criar restrição.

Quando você digita um valor em cada campo, a configuração YAML equivalente à restrição personalizada aparece à direita.

gcloud

1. Para criar uma restrição personalizada, crie um arquivo YAML com o seguinte formato:

name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
resourceTypes: RESOURCE_NAME
methodTypes:
  - CREATE
  - UPDATE 
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

Substitua:

• ORGANIZATION_ID: o ID da organização, como 123456789.
• CONSTRAINT_NAME: o nome da sua nova restrição personalizada. Uma restrição personalizada só pode conter letras (maiúsculas e minúsculas) ou números, por exemplo, custom.enforceTCPHealthCheckPort1024. Esse campo pode conter até 70 caracteres, sem contar o prefixo (custom.), por exemplo, organizations/123456789/customConstraints/custom. Não inclua PII ou dados sensíveis no ID da restrição, porque eles podem ser expostos em mensagens de erro.
• RESOURCE_NAME: o nome totalmente qualificado do recurso Cloud de Confiance que contém o objeto e o campo que você quer restringir. Por exemplo, compute.googleapis.com/HealthCheck. A maioria dos tipos de recursos aceita até 20 restrições personalizadas. Se você tentar criar mais restrições personalizadas, a operação vai falhar.
• methodTypes: os métodos REST em que a restrição é aplicada. Pode ser CREATE ou CREATE e UPDATE. Se você aplicar a restrição com o método UPDATE em um recurso que a viole, as mudanças nesse recurso serão bloqueadas pela política da organização, a menos que a mudança resolva a violação.

Para ver os métodos compatíveis com cada serviço, encontre o serviço em Serviços que aceitam restrições personalizadas.

• CONDITION: uma condição de CEL gravada em uma representação de um recurso de serviço compatível. Esse campo pode conter até 1.000 caracteres. Por exemplo, "resource.tcpHealthCheck.port >= 1024".

Para mais informações sobre os recursos disponíveis para gravação de condições, consulte Recursos compatíveis.

• ACTION: a ação a ser realizada se o condition for atendido. Os valores possíveis são ALLOW e DENY.

A ação "permitir" significa que, se a condição for avaliada como verdadeira, a operação para criar ou atualizar o recurso será permitida. Isso também significa que todos os outros casos, exceto o listado explicitamente na condição, estão bloqueados.

A ação de negação significa que, se a condição for avaliada como verdadeira, a operação para criar ou atualizar o recurso será bloqueada.

• DISPLAY_NAME: um nome legível para a restrição. Esse nome é usado em mensagens de erro e pode ser usado para identificação e depuração. Não use PII ou dados sensíveis em nomes de exibição, porque eles podem ser expostos em mensagens de erro. Esse campo pode ter até 200 caracteres.
• DESCRIPTION: uma descrição legível da restrição a ser exibida como uma mensagem de erro quando a política for violada. Esse campo pode conter até 2.000 caracteres.
2. Depois de criar o arquivo YAML para uma nova restrição personalizada, faça a configuração necessária para disponibilizá-la para as políticas da organização. Para configurar uma restrição personalizada, use o comando gcloud org-policies set-custom-constraint:

gcloud org-policies set-custom-constraint CONSTRAINT_PATH

Substitua CONSTRAINT_PATH pelo caminho completo do arquivo de restrição personalizada. Por exemplo, /home/user/customconstraint.yaml.

Após a conclusão, as restrições personalizadas vão estar disponíveis como políticas da organização na lista de políticas da organização do Cloud de Confiance by S3NS .

3. Para verificar se a restrição personalizada existe, use o comando gcloud org-policies list-custom-constraints:

gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

Substitua ORGANIZATION_ID pelo ID do recurso da organização.

Para mais informações, consulte Como visualizar políticas da organização.

Aplicar uma política personalizada da organização

Para aplicar uma restrição, crie uma política da organização que faça referência a ela e aplique essa política a um recurso do Cloud de Confiance by S3NS .

Console

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

   Acessar a página Políticas da organização

2. No seletor de projetos, selecione o projeto em que você quer definir a política da organização.
3. Na lista da página Políticas da organização, selecione uma restrição para acessar a página Detalhes da política associada.
4. Para configurar a política da organização nesse recurso, clique em Gerenciar política.
5. Na página Editar política, selecione Substituir a política do recurso pai.
6. Clique em Adicionar uma regra.
7. Na seção Aplicação, selecione se essa política da organização é aplicada ou não.
8. Opcional: para tornar a política da organização condicional em uma tag, clique em Adicionar condição. Se você adicionar uma regra condicional a uma política da organização, inclua pelo menos uma regra não condicional para que a política seja salva. Para mais informações, consulte Definir o escopo das políticas da organização com tags.
9. Clique em Testar mudanças para simular o efeito da política da organização. Para mais informações, consulte Testar mudanças na política da organização com o Simulador de política.
10. Para aplicar a política da organização no modo de teste, clique em Definir política de simulação. Para mais informações, consulte Testar políticas da organização.
11. Depois de verificar se a política da organização no modo de simulação funciona como esperado, clique em Definir política para definir a política ativa.

gcloud

1. Para criar uma política da organização com regras booleanas, crie um arquivo YAML para a política que faça referência à restrição:

name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
spec:
  rules:
  - enforce: true

dryRunSpec:
  rules:
  - enforce: true

Substitua:

• PROJECT_ID: o projeto em que você quer aplicar a restrição.
• CONSTRAINT_NAME: o nome definido para a restrição personalizada. Por exemplo, custom.enforceTCPHealthCheckPort1024.
2. Para aplicar a política da organização no modo de teste, execute o seguinte comando com a flag dryRunSpec:

gcloud org-policies set-policy POLICY_PATH --update-mask=dryRunSpec

Substitua POLICY_PATH pelo caminho completo para o arquivo YAML da política da organização. A política leva até 15 minutos para entrar em vigor.

3. Depois de verificar se a política da organização no modo de simulação funciona conforme o esperado, defina a política ativa com o comando org-policies set-policy e a flag spec:

gcloud org-policies set-policy POLICY_PATH --update-mask=spec

Substitua POLICY_PATH pelo caminho completo para o arquivo YAML da política da organização. A política leva até 15 minutos para entrar em vigor.

Testar a política personalizada da organização

O exemplo a seguir cria uma restrição personalizada que exige que as portas de verificação de integridade TCP sejam 1024 ou superiores, impedindo o uso de portas conhecidas (0-1023).

Criar a restrição personalizada

1. Para definir uma restrição personalizada, crie um arquivo chamado constraint-tcp-health-check-ports.yaml.

   name: organizations/ORGANIZATION_ID/customConstraints/custom.enforceTCPHealthCheckPort1024
   resource_types:
   – compute.googleapis.com/HealthCheck
   condition: "resource.tcpHealthCheck.port >= 1024"
   method_types:
   – CREATE
   – UPDATE
   action_type: ALLOW
   display_name: Only TCP health check ports >= 1024 allowed.
   description: Prevent TCP health checks on well-known ports.

   Substitua ORGANIZATION_ID pelo ID da organização.

2. Aplique a restrição personalizada.

   gcloud org-policies set-custom-constraint constraint-tcp-health-check-ports
   

Criar a política da organização

1. Para definir uma política da organização, crie um arquivo chamado policy-tcp-health-check-ports.yaml. Neste exemplo, aplicamos essa restrição a envolvidos no projeto, mas também é possível defini-la no nível da organização ou da pasta.

   name: projects/PROJECT_ID/policies/custom.enforceTCPHealthCheckPort1024
   spec:
     rules:
     – enforce: true

   Substitua PROJECT_ID pela ID do seu projeto.

2. Aplique a política da organização.

   gcloud org-policies set-policy policy-tcp-health-check-ports
   

3. Verifique se a política da organização existe.

   gcloud org-policies list --project PROJECT_ID
   

   O resultado será o seguinte:

   CONSTRAINT: custom.enforceTCPHealthCheckPort1024
   LIST_POLICY: SET
   BOOLEAN_POLICY: -
   ETAG: CNHuh7kGEJiatFo=-
   

Testar a política

1. Teste a restrição criando uma verificação de integridade TCP na porta 80.

   gcloud compute health-checks create tcp my-tcp-health-check \
       --project=PROJECT_ID \
       --region=us-central1 \
       --port=80 \
       --check-interval=5s \
       --timeout=5s \
       --healthy-threshold=4 \
       --unhealthy-threshold=5 \
   

   A operação não é permitida, e a saída é semelhante a esta:

   ERROR: (gcloud.compute.healthChecks.create) Could not fetch resource:
   – Operation denied by custom org policies: [customConstraints/custom.enforceTCPHealthCheckPort1024]: Only TCP health check ports >= 1024 allowed.
   

Exemplos de políticas personalizadas da organização para casos de uso comuns

A tabela a seguir mostra a sintaxe de algumas restrições personalizadas comuns.

Descrição	Sintaxe da restrição
Exigir que todos os buckets de back-end tenham o Cloud CDN ativado	name: organizations/ORGANIZATION_ID/customConstraints/custom.backendBucketEnableCdn resourceTypes: - compute.googleapis.com/BackendBucket methodTypes: - CREATE - UPDATE condition: "resource.enableCdn == true" actionType: ALLOW displayName: Require all backend buckets to have Cloud CDN enabled description: All backend buckets must have Cloud CDN enabled.
Não permitir o uso de HTTP e TCP como protocolos de serviço de back-end	name: organizations/ORGANIZATION_ID/customConstraints/custom.backendBucketEnableCdn resourceTypes: - compute.googleapis.com/BackendService methodTypes: - CREATE - UPDATE condition: "resource.protocol == 'HTTP' || resource.protocol == 'TCP'" actionType: DENY displayName: Disallow the use of HTTP and TCP as backend service protocols description: Backend services cannot configure HTTP or TCP as the backend service protocol.
Exigir que as regras de encaminhamento usem o nível Standard	name: organizations/ORGANIZATION_ID/customConstraints/custom.forwardingRulesStandardTier resourceTypes: - compute.googleapis.com/ForwardingRule methodTypes: - CREATE - UPDATE condition: "resource.networkTier == 'STANDARD'" actionType: ALLOW displayName: Require forwarding rules to use Standard Tier description: Forwarding rules must use the Standard Network Service Tier.
Exija que todos os protocolos de verificação de integridade ocorram na porta 1024 ou superior	name: organizations/ORGANIZATION_ID/customConstraints/custom.healthCheckPortMin1024 resourceTypes: - compute.googleapis.com/HealthCheck methodTypes: - CREATE - UPDATE condition: "resource.tcpHealthCheck.port >= 1024 && resource.httpHealthCheck.port >= 1024 && resource.httpsHealthCheck.port >= 1024 && resource.sslHealthCheck.port >= 1024 && resource.sslHealthCheck.port >= 1024 &&resource.http2HealthCheck.port >= 1024 && resource.grpcHealthCheck.port >= 1024" actionType: ALLOW displayName: Require port 1024 or greater for all health checks description: All health check protocols must use a port of 1024 or higher, to avoid well-known ports.
Desativar verificações de integridade do gRPC	name: organizations/ORGANIZATION_ID/customConstraints/custom.disallowGRPCHealthChecks resourceTypes: - compute.googleapis.com/HealthCheck methodTypes: - CREATE - UPDATE condition: "resource.type == 'GRPC'" actionType: DENY displayName: Disallow GRPC health checks description: Health checks aren't allowed to use GRPC.
Evitar sondagens de verificação de integridade de alta frequência	name: organizations/ORGANIZATION_ID/customConstraints/custom.minHealthCheckFrequency resourceTypes: - compute.googleapis.com/HealthCheck methodTypes: - CREATE - UPDATE condition: "resource.checkIntervalSec >= 30" actionType: ALLOW displayName: Disallow fast health check probes description: Prevent health checks from having a probe frequency under 30 seconds.
Não permitir valores de tempo limite do sinal de atividade HTTPS do cliente maiores que 1.000 segundos	name: organizations/ORGANIZATION_ID/customConstraints/custom.clientHTTPSKeepalive1000Sec resourceTypes: - compute.googleapis.com/TargetHttpsProxy methodTypes: - CREATE - UPDATE condition: "resource.httpKeepAliveTimeoutSec > 1000" actionType: DENY displayName: Disallow client HTTPS keepalive timeout greater than 1000 seconds description: Disallow client HTTPS keepalive timeout values greater than 1000 seconds.
Exigir que os mapas de URL tenham uma política de resposta de erro personalizada para códigos de status HTTP 500	name: organizations/ORGANIZATION_ID/customConstraints/custom.urlMapCustomResponseHTTP500 resourceTypes: - compute.googleapis.com/UrlMaps methodTypes: - CREATE - UPDATE condition: "resource.defaultCustomErrorResponsePolicy.errorResponseRule.exists(value, value.matchResponseCode == 500)" actionType: ALLOW displayName: Require URL maps to have a custom error response policy for HTTP 500 errors description: URL maps must have a custom error response policy configured for HTTP 500 errors.
Exigir que as instâncias de destino tenham um nome que comece com a string "targetInstance"	name: organizations/ORGANIZATION_ID/customConstraints/custom.targetInstanceConstraint resourceTypes: - compute.googleapis.com/TargetInstance methodTypes: - CREATE - UPDATE condition: "resource.name.startsWith('targetInstance')" actionType: ALLOW displayName: Require target instances to have a name that starts with the string "targetInstance" description: Target instances must have resource names that start with the string "targetInstance"
Exigir que os pools de destino tenham uma afinidade da sessão CLIENT_IP	name: organizations/ORGANIZATION_ID/customConstraints/custom.targetPoolConstraint resourceTypes: - compute.googleapis.com/TargetPool methodTypes: - CREATE - UPDATE condition: "resource.sessionAffinity == 'CLIENT_IP'" actionType: ALLOW displayName: Require target pools to use CLIENT_IP session affinity description: Target pools must use CLIENT_IP session affinity
Restringir a versão mínima do TLS a 1.2	name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictLbTlsVersion resource_types: compute.googleapis.com/SslPolicy methodTypes: - CREATE - UPDATE condition: resource.minTlsVersion == "TLS_1_2" action_type: ALLOW display_name: Restrict Load Balancing TLS version to 1.2 description: Only allow SSL policies to be created or updated if the minimum TLS version is 1.2 where this custom constraint is enforced.
Permita a criação de um recurso SSL se as seguintes condições forem atendidas: A versão mínima do TLS está definida como 1.2 A política de SSL tem um perfil PERSONALIZADO que permite selecionar recursos SSL individualmente. A política de SSL não inclui o pacote de criptografia ChaCha20-Poly1305	name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictLbTlsCapabilities resourceTypes: - compute.googleapis.com/SslPolicy methodTypes: - CREATE - UPDATE condition: resource.minTlsVersion == "TLS_1_2" && resource.profile == "CUSTOM" && !resource.customFeatures.exists(feature, feature.contains("CHACHA20_POLY1305")) actionType: ALLOW displayName: Restrict Load Balancing TLS Capabilities description: Only allow SSL Policy resources to be created or updated if the minimum TLS version is 1.2, profile is CUSTOM, and no ChaCha20-Poly1305 cipher suite is used where this custom constraint is enforced.

Recursos compatíveis com o Cloud Load Balancing

Para o Cloud Load Balancing, é possível definir restrições personalizadas nos seguintes recursos e campos.

A seguir

• Saiba mais sobre o Serviço de políticas da organização.
• Saiba como criar e gerenciar políticas da organização.
• Confira a lista completa de restrições de política da organização gerenciadas.