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 Cloud de Confiance by S3NS . É possível usar restrições para ajudar sua organização a atender aos requisitos de compliance, segurança e política, garantindo que os recursos do cluster atendam a requisitos específicos. Nesta página, você vai aprender a criar restrições personalizadas e aplicá-las aos recursos do cluster.

Esta página é para especialistas em segurança que garantem que a organização atenda aos requisitos de compliance, segurança e política limitando ou exigindo configurações específicas nos recursos do cluster. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Cloud de Confiance by S3NS , consulte Tarefas e funções de usuário comuns do GKE.

Antes de ler esta página, confira se você conhece as políticas da Política da organização.

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

A política da organização do Cloud de Confiance oferece controle centralizado e programático sobre os recursos da sua organização. Como administrador de políticas da organização, você pode definir uma política da organização, que é um conjunto de restrições chamado restrições que se aplicam aos recursos do Cloud de Confiance e aos descendentes desses recursos na hierarquia de recursos doCloud de Confiance by S3NS . É 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 oferece restrições predefinidas para vários serviços do Cloud de Confiance . 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 a uma pasta, oCloud 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.

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

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 pode ter no máximo 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 doCloud de Confiance 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 Cloud de Confiance recurso 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 Cloud de Confiance .

    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 ID da sua organização.
  • Um ID de projeto

Criar 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á o seguinte:

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

Criar 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 pelo 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á o seguinte:

    CONSTRAINT                  LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot   -              SET               COCsm5QGENiXi2E=

Depois de aplicar a política, aguarde cerca de dois minutos para que o Cloud de Confiance 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 \
    --location=CONTROL_PLANE_LOCATION \
    --num-nodes=1

Substitua:

  • PROJECT_ID: o ID do projeto da política.
  • CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.

A saída é esta:

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

Confira exemplos de restrições personalizadas para casos de uso comuns

Os exemplos a seguir fornecem a sintaxe de algumas restrições personalizadas que podem ser úteis, como a aplicação da federação de identidade da carga de trabalho para o GKE em novos clusters. Para usar essas amostras, modifique os exemplos conforme necessário para adequar ao seu caso de uso específico. Depois, siga as instruções nesta página para aplicá-las à sua organização.

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: "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