Restringir ações em recursos do GKE usando políticas personalizadas da organização

Nesta página, mostramos como restringir operações específicas nos recursos do Google Kubernetes Engine (GKE) em sua organização usando restrições personalizadas no Serviço de políticas da organização do Google Cloud. Para saber mais sobre a política da organização, consulte Políticas da organização personalizadas.

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

A política da organização do Google Cloud oferece controle centralizado e programático sobre os recursos da sua organização. À medida que administrador de políticas da organização, você pode definir umapolítica da organização, que é um conjunto de restrições chamado restrições que se aplicam aos recursos do Google Cloud e aos descendentes desses recursos na Hierarquia de recursos do Google Cloud. É possível aplicar políticas da organização no nível da organização, da pasta ou do projeto.

A política da organização fornece restrições predefinidas para vários serviços do Google Cloud. No entanto, se você quiser um controle mais granular e personalizável sobre os campos específicos restritos nas suas políticas da organização, crie também restrições personalizadas e use-as em uma política da organização personalizada.

Recursos compatíveis no GKE

Para o GKE, é possível criar restrições personalizadas para os métodos CREATE ou UPDATE em qualquer campo no recurso Cluster ou NodePool da API Google Kubernetes Engine v1, exceto nos campos somente para saída e nos seguintes campos:

  • projects.locations.clusters.masterAuth.clientKey
  • projects.locations.clusters.masterAuth.password

Herança de políticas

Por padrão, as políticas são herdadas pelos descendentes dos recursos em que a política é aplicada. Por exemplo, se você aplicar uma política em uma pasta, o Google Cloud aplicará a política a todos os projetos da pasta. Para saber mais sobre esse comportamento e como alterá-lo, consulte Regras de avaliação de hierarquia.

Preços

As políticas e restrições da organização são oferecidas sem custos financeiros.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.

Criar uma restrição personalizada

Para criar uma nova restrição personalizada, defina-a em um arquivo YAML e a aplique na sua organização usando a Google Cloud CLI.

  1. Crie um arquivo YAML para a restrição personalizada:

    name: organizations/ORGANIZATION_ID/customConstraints/custom.CONSTRAINT_NAME
resourceTypes:
- container.googleapis.com/RESOURCE_NAME
methodTypes:
- METHOD1
- METHOD2
condition: "resource.OBJECT_NAME.FIELD_NAME == VALUE"
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 precisa começar com custom. e só pode incluir letras maiúsculas, minúsculas ou números, por exemplo, custom.enableGkeAutopilot. O tamanho máximo desse campo é de 70 caracteres, sem contar o prefixo (por exemplo, organizations/123456789/customConstraints/custom.).
    • RESOURCE_NAME: o nome (não o URI) do recurso REST da API GKE que contém o objeto e o campo que você quer restringir. Por exemplo, Cluster ou NodePool.
    • METHOD1,METHOD2,...: uma lista de métodos "RESTful" para aplicar a restrição. Pode ser CREATE ou CREATE e UPDATE.

    • condition: a condição para validar a solicitação contra, escrita em Common Expression Language (CEL). Esse campo tem um comprimento máximo de 1000 caracteres. A expressão precisa conter os seguintes campos e oferecer suporte a operadores lógicos, como && e ||:

      • OBJECT_NAME: o nome do objeto da API GKE que você quer restringir, na formatação pascalCase. Por exemplo, privateClusterConfig.
      • FIELD_NAME: o nome do campo da API GKE que você quer restringir, na formatação pascalCase. Por exemplo, enablePrivateNodes.
      • VALUE: o valor do campo. Para campos booleanos, use true ou false. Para campos de string, use "STRING".

    • ACTION: a ação a ser realizada se o condition for atendido. Pode ser ALLOW ou DENY.

    • DISPLAY_NAME: um nome legível para a restrição. Esse campo tem um comprimento máximo de 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 tem um comprimento máximo de 2000 caracteres.

  2. Aplique a restrição personalizada:

    gcloud org-policies set-custom-constraint PATH_TO_FILE

    Substitua PATH_TO_FILE pelo caminho do arquivo da sua definição de restrição personalizada.

  3. Verifique se a restrição personalizada existe:

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

    O resultado será assim:

    CONSTRAINT                     LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot      -              SET               COCsm5QGENiXi2E=
...

Aplicar a restrição personalizada

Para aplicar a nova restrição personalizada, crie uma política da organização que faça referência à restrição e aplique-a.

  1. Crie um arquivo YAML para a política da organização:

    name: RESOURCE_HIERARCHY/policies/POLICY_NAME
spec:
  rules:
  - enforce: true

    Substitua:

    • RESOURCE_HIERARCHY: o local da nova política, que afeta o escopo da aplicação. Use a hierarquia de recursos do Google Cloud como guia. Por exemplo, se você quiser aplicar a política em um projeto específico, use projects/PROJECT_ID. Para aplicar a política em uma organização específica, use organizations/ORGANIZATION_ID.
    • POLICY_NAME: o nome da nova política.

  2. Aplique a política:

    gcloud org-policies set-policy PATH_TO_POLICY

    Substitua PATH_TO_POLICY pelo caminho para o arquivo de definição da política.

  3. Verifique se a política existe:

    gcloud org-policies list \
    --RESOURCE_FLAG=RESOURCE_ID

    Substitua:

    • RESOURCE_FLAG: o recurso do Google Cloud em que você aplicou a política. Por exemplo, project ou folder.
    • RESOURCE_ID: o ID do recurso em que a política foi aplicada. Por exemplo, o ID da pasta do Google Cloud.

    Para ver uma lista de argumentos, consulte gcloud org-policies list.

    O resultado será assim:

    CONSTRAINT                                    LIST_POLICY    BOOLEAN_POLICY    ETAG
iam.disableWorkloadIdentityClusterCreation    -              SET               CO3UkJAGEOj1qsQB
custom.enableGkeAutopilot                     -              SET               COCsm5QGENiXi2E=
custom.enableBinAuth                          -              SET               CJfKiZUGEJju7LUD

Exemplo: criar uma restrição personalizada e aplicar uma política

O exemplo a seguir cria uma restrição e política personalizada que exige que todos os novos clusters em um projeto específico sejam clusters do piloto automático.

Antes de começar, você precisa saber o seguinte:

  • O código da sua organização.
  • Um ID do projeto

Crie a restrição.

  1. Salve o seguinte arquivo como constraint-enable-autopilot.yaml:

    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableGkeAutopilot
resourceTypes:
- container.googleapis.com/Cluster
methodTypes:
- CREATE
condition: "resource.autopilot.enabled == false"
actionType: DENY
displayName: Enable GKE Autopilot
description: All new clusters must be Autopilot clusters.

    Isso define uma restrição em que para cada novo cluster, se o modo de cluster não for Autopilot, a operação será negada.

  2. Aplique a restrição:

    gcloud org-policies set-custom-constraint ~/constraint-enable-autopilot.yaml

  3. Verifique se a restrição existe:

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

    O resultado será assim:

    CUSTOM_CONSTRAINT                       ACTION_TYPE  METHOD_TYPES   RESOURCE_TYPES                     DISPLAY_NAME
custom.enableGkeAutopilot               DENY         CREATE         container.googleapis.com/Cluster   Enable GKE Autopilot
...

Crie a política

  1. Salve o seguinte arquivo como policy-enable-autopilot.yaml:

    name: projects/PROJECT_ID/policies/custom.enableGkeAutopilot
spec:
  rules:
  - enforce: true

    Substitua PROJECT_ID pela ID do seu projeto.

  2. Aplique a política:

    gcloud org-policies set-policy ~/policy-enable-autopilot.yaml

  3. Verifique se a política existe:

    gcloud org-policies list --project=PROJECT_ID

    O resultado será assim:

    CONSTRAINT                  LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot   -              SET               COCsm5QGENiXi2E=

Depois de aplicar a política, aguarde cerca de dois minutos para que o Google Cloud comece a aplicar a política.

Testar a política

Tente criar um cluster do GKE Standard no projeto:

gcloud container clusters create org-policy-test \
    --project=PROJECT_ID \
    --zone=COMPUTE_ZONE \
    --num-nodes=1

A saída é esta:

Operation denied by custom org policies: ["customConstraints/custom.enableGkeAutopilot": "All new clusters must be Autopilot clusters."]

Exemplos de restrições personalizadas para casos de uso comuns

As seções a seguir fornecem a sintaxe de algumas restrições personalizadas que podem ser úteis para você:

Descrição Sintaxe de restrição
Permitir a criação de clusters somente quando a autorização binária estiver ativada 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeBinaryAuthorization
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "condition:resource.binaryAuthorization.enabled == true || resource.binaryAuthorization.evaluationMode=='PROJECT_SINGLETON_POLICY_ENFORCE'"
    action: ALLOW
    displayName: Enable GKE Binary Authorization
    description: All new clusters must enable Binary Authorization.
Não desativar o upgrade automático de nós para novos pools de nós 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableAutoUpgrade
    resourceTypes:
    - container.googleapis.com/NodePool
    methodTypes:
    - CREATE
    condition: "resource.management.autoUpgrade == true"
    actionType: ALLOW
    displayName: Enable node auto-upgrade
    description: All node pools must have node auto-upgrade enabled.
Ativar a federação de identidade da carga de trabalho do GKE para novos clusters 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableWorkloadIdentity
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "has(resource.workloadIdentityConfig.workloadPool) || resource.workloadIdentityConfig.workloadPool.size() > 0"
    actionType: ALLOW
    displayName: Enable Workload Identity on new clusters
    description: All new clusters must use Workload Identity.
Não desativar o Cloud Logging em clusters existentes 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableLogging
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - UPDATE
    condition: "resource.loggingService == 'none'"
    actionType: DENY
    displayName: Do not disable Cloud Logging
    description: You cannot disable Cloud Logging on existing GKE cluster.
Permitir a criação ou atualização do pool de nós do Standard somente quando os endpoints de metadados legados estiverem desativados 
    name: organizations/ORGANIZATION_ID/customConstraints/custom.nodeConfigMetadata
    resourceTypes:
    - container.googleapis.com/NodePool
    methodTypes:
    - CREATE
    - UPDATE
    condition: "'disable-legacy-endpoints' in resource.config.metadata && resource.config.metadata['disable-legacy-endpoints'] == 'true'"
    actionType: ALLOW
    displayName: Disable legacy metadata endpoints
    description: You can only create or update node pools if you disable legacy
    metadata endpoints.

Este exemplo de restrição mostra como definir uma restrição personalizada em um valor de mapa. O campo condition usa o operador de índice na chave do mapa disable-legacy-endpoints. Se você usar a sintaxe de seleção de campo regular, como nos exemplos anteriores, receberá um erro INVALID_CUSTOM_CONSTRAINT_CONDITION.

A seguir