Usar a biblioteca de modelos de restrição

Esta página mostra como definir restrições do Controlador de Políticas usando os modelos de restrição preexistentes fornecidos pelo Google.

O Controlador de Políticas permite aplicar uma política a um cluster do Kubernetes definindo um ou mais objetos de restrição. Depois que uma restrição é instalada, as solicitações ao servidor da API são verificadas em relação à restrição e são rejeitadas se não estiverem em conformidade. Recursos preexistentes que não sejam compatíveis são relatados no momento da auditoria.

Cada restrição é baseada em um modelo que define o esquema e a lógica da restrição. Os modelos de restrição podem ser provenientes do Google e de terceiros ou criados por você. Saiba mais sobre como criar novos modelos em Escrever um modelo de restrição.

Antes de começar

Examinar a biblioteca de modelos de restrição

Ao definir uma restrição, você especifica o modelo de restrição que ela estende. Uma biblioteca de modelos de restrição comuns desenvolvida pelo Google está instalada por padrão, e muitas organizações não precisam criar modelos de restrição personalizados diretamente no Rego. Os modelos de restrição fornecidos pelo Google têm o rótulo configmanagement.gke.io/configmanagement.

Para listar restrições, use o seguinte comando:

kubectl get constrainttemplates \
    -l="configmanagement.gke.io/configmanagement=config-management"

Para descrever um modelo de restrição e verificar os parâmetros necessários, use o seguinte comando:

kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME

Também é possível visualizar todos os modelos de restrição da biblioteca.

Definir uma restrição

Defina uma restrição usando o YAML, não sendo necessário entender ou escrever o Rego. Em vez disso, uma restrição chama um modelo e envia-o com parâmetros específicos à restrição.

Se você estiver usando o Config Sync com um repositório hierárquico, recomendamos criar suas restrições no diretório cluster/.

As restrições têm os seguintes campos:

  • O kind em minúsculas corresponde ao nome de um modelo de restrição.
  • O metadata.name é o nome da restrição.
  • O campo match define a quais objetos a restrição se aplica. Todas as condições especificadas precisam ser correspondidas antes que um objeto esteja no escopo de uma restrição. As condições match são definidas pelos seguintes subcampos:
    • kinds são os tipos de recursos a que a restrição se aplica, determinados por dois campos: apiGroups é uma lista de grupos de APIs do Kubernetes que serão correspondentes, e kinds é uma lista de tipos que serão correspondentes. "*" corresponde a tudo. Se pelo menos um apiGroup e uma entrada kind forem correspondentes, a condição kinds será atendida.
    • scope aceita *, cluster ou com namespace, que determina se os recursos com escopo de cluster ou com escopo de namespace são selecionados (o padrão é *).
    • namespaces é uma lista de nomes de namespace a que o objeto pode pertencer. O objeto precisa pertencer a pelo menos um desses namespaces. Os recursos de namespace são tratados como se pertencessem a eles mesmos.
    • excludedNamespaces é uma lista de namespaces a que o objeto não pode pertencer.
    • labelSelector é um seletor de rótulo do Kubernetes a que o objeto precisa atender.
    • namespaceSelector é um seletor de rótulo no namespace a que o objeto pertence. Se o namespace não atender ao objeto, ele não será correspondente. Os recursos de namespace são tratados como se pertencessem a eles mesmos.
  • O campo parameters define os argumentos para a restrição, com base no que o modelo de restrição espera.

A restrição a seguir, chamada ns-must-have-geo, invoca um modelo de restrição chamado K8sRequiredLabels, incluído na biblioteca de modelos de restrição fornecida pelo Google. A restrição define parâmetros que o modelo de restrição usa para avaliar se os namespaces têm o rótulo geo definido com algum valor.

# ns-must-have-geo.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-geo
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - key: "geo"

Para criar a restrição, use kubectl apply -f:

kubectl apply -f ns-must-have-geo.yaml

Auditar uma restrição

Se a restrição tiver sido configurada e instalada corretamente, o campo status.byPod[].enforced dela estará definido como true, esteja ela configurada para impor ou apenas testar a restrição.

As restrições são impostas por padrão, e a violação de uma restrição impede uma determinada operação de cluster. É possível definir spec.enforcementAction de uma restrição como dryrun para relatar violações no campo status.violations sem impedir a operação.

Para saber mais sobre como fazer auditoria, consulte Fazer auditoria usando restrições.

Advertências ao sincronizar restrições

Se você estiver sincronizando suas restrições com uma fonte centralizada, como um repositório Git, com o Config Sync ou outra ferramenta no estilo GitOps, lembre-se das ressalvas a seguir ao sincronizar as restrições.

Consistência eventual

É possível confirmar restrições em uma fonte de verdade, como um repositório Git, e limitar os efeitos delas usando ClusterSelectors ou NamespaceSelectors. Como a sincronização tem consistência posterior, lembre-se das seguintes advertências:

  • Se uma operação de cluster acionar uma restrição em que o NamespaceSelector se referir a um namespace que não foi sincronizado, a restrição será imposta e a operação será impedida. Em outras palavras, um namespace ausente "falha ao fechar".
  • Se você alterar os rótulos de um namespace, o cache poderá conter dados desatualizados por um breve período.

Minimize a necessidade de renomear um namespace ou alterar os respectivos rótulos e teste as restrições que afetam um namespace com novo nome ou rótulo para garantir que funcionem conforme esperado.

Configurar o Controlador de Políticas com restrições referenciais

Antes de ativar as restrições referenciais, é necessário criar uma configuração que informe ao Controlador de Políticas quais tipos de objetos precisam ser observados, como os namespaces.

Salve o seguinte manifesto YAML em um arquivo e aplique-o com kubectl. O manifesto configura o Policy Controller para ficar atento a namespaces e entradas. Crie uma entrada com group, version e kind em spec.sync.syncOnly, com os valores para cada tipo de objeto que você quer observar.

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: "extensions"
        version: "v1beta1"
        kind: "Ingress"

Ativar restrições referenciais

Uma restrição referencial refere-se a outro objeto na definição. Por exemplo, é possível criar uma restrição que exija que os objetos da entrada em um cluster tenham nomes de host exclusivos. A restrição será referencial se o modelo de restrição contiver a string data.inventory no Rego.

As restrições referenciais serão ativadas por padrão se você instalar o Controlador de Políticas usando o console do Google Cloud. Se você instalar o Controlador de Políticas usando a CLI do Google Cloud, poderá escolher se quer ativar as restrições referenciais ao instalar o Controlador de Políticas. As restrições referenciais são garantidas somente como consistências posteriores, e isso provoca riscos:

  • Em um servidor de API sobrecarregado, o conteúdo do cache do Controlador de Políticas pode ficar desatualizado, provocando uma restrição referencial de "falha ao abrir". Isso significa que a ação de imposição parece estar funcionando, quando não está. Por exemplo, é possível criar entradas com nomes de host duplicados rápido demais para que o controlador de admissão consiga detectar as cópias.

  • As ordens em que as restrições são instaladas e em que o cache é atualizado são aleatórias.

É possível atualizar um cluster atual para permitir restrições referenciais.

Console

Para desativar as restrições referenciais, siga as seguintes etapas:

  1. No console do Google Cloud, acesse a página Política do GKE Enterprise na seção Gerenciamento de postura.

    Acessar a política

  2. Na guia Configurações, na tabela de clusters, selecione Editar na coluna Editar configuração.
  3. Expanda o menu Editar configuração do Policy Controller.
  4. Selecione a caixa de seleção Ativar modelos de restrição que se referem a objetos diferentes do objeto que está sendo avaliado.
  5. Selecione Salvar alterações.

Policy Controller da gcloud

Para ativar o suporte para restrições referenciais, execute o seguinte comando:

gcloud container fleet policycontroller update \
    --memberships=MEMBERSHIP_NAME \
    --referential-rules

Substitua MEMBERSHIP_NAME pelo nome de assinatura do cluster registrado para ativar as regras referenciais. Você pode especificar várias associações separadas por uma vírgula.

gcloud ConfigManagement

Para ativar o suporte a restrições referenciais, defina policyController.referentialRulesEnabled como true no arquivo config-management.yaml:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
  namespace: config-management-system
spec:
  clusterName: my-cluster
  channel: dev
  policyController:
    enabled: true
    referentialRulesEnabled: true

Desativar restrições referenciais

Quando você desativa as restrições referenciais, todos os modelos que usam restrições referenciais também são removidos do cluster, com todas as restrições que usam esses modelos.

Console

As restrições referenciais são ativadas por padrão ao intalar o Controlador de Políticas com o console do Google Cloud. Para desativar as restrições referenciais, siga as seguintes etapas:

  1. No console do Google Cloud, acesse a página Política do GKE Enterprise na seção Gerenciamento de postura.

    Acessar a política

  2. Na guia Configurações, na tabela de clusters, selecione Editar na coluna Editar configuração.
  3. Expanda o menu Editar configuração do Policy Controller.
  4. Desmarque a caixa de seleção Ativar modelos de restrição que se referem a objetos diferentes do objeto que está sendo avaliado.
  5. Selecione Salvar alterações.

Policy Controller da gcloud

Para desativar o suporte a restrições referenciais, execute o seguinte comando:

gcloud container fleet policycontroller update \
    --memberships=MEMBERSHIP_NAME \
    --no-referential-rules

Substitua MEMBERSHIP_NAME pelo nome de assinatura do cluster registrado para ativar as regras referenciais. Você pode especificar várias associações separadas por uma vírgula.

gcloud ConfigManagement

Para desativar as restrições referenciais em um cluster, defina policyController.referentialRulesEnabled como false no seu arquivo config-management.yaml:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
  namespace: config-management-system
spec:
  clusterName: my-cluster
  channel: dev
  policyController:
    enabled: true
    referentialRulesEnabled: false

Listar todas as restrições

Para listar todas as restrições instaladas em um cluster, use o seguinte comando:

kubectl get constraint

Também é possível ter uma visão geral das restrições aplicadas no console do Google Cloud. Para mais informações, consulte Métricas do Controlador de políticas.

Remover uma restrição

Para encontrar todas as restrições que usam um modelo de restrição, use o seguinte comando para listar todos os objetos com o mesmo kind que o metadata.name do modelo de restrição:

kubectl get CONSTRAINT_TEMPLATE_NAME

Para remover uma restrição, especifique kind e name:

kubectl delete CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME

Quando você remove uma restrição, ela deixa de ser imposta assim que o servidor de API marca a restrição como excluída.

Remover todos os modelos de restrição

Console

Para desativar a biblioteca de modelos de restrição, siga estas etapas:

  1. No console do Google Cloud, acesse a página Política do GKE Enterprise na seção Gerenciamento de postura.

    Acessar a política

  2. Na guia Configurações, na tabela de clusters, selecione Editar na coluna Editar configuração.
  3. No menu Adicionar/editar pacotes de políticas, desative a biblioteca de modelos e todos os pacotes de políticas .
  4. Selecione Salvar alterações.

Policy Controller da gcloud

Para desativar a biblioteca de modelos de restrição, execute o seguinte comando:

gcloud container fleet policycontroller content templates disable \
    --memberships=MEMBERSHIP_NAME

Substitua MEMBERSHIP_NAME pelo nome de assinatura do cluster registrado para desativar a biblioteca de modelos de restrição. Você pode especificar várias associações separadas por vírgula.

gcloud ConfigManagement

Defina spec.policyController.templateLibraryInstalled como false. Isso impede que o Policy Controller reinstale automaticamente a biblioteca.

Para remover todos os modelos de restrição e todas as restrições, use o seguinte comando:

kubectl delete constrainttemplate --all

Restaurar a biblioteca de modelos de restrição

Console

Para ativar a biblioteca de modelos de restrição, siga estas etapas:

  1. No console do Google Cloud, acesse a página Política do GKE Enterprise na seção Gerenciamento de postura.

    Acessar a política

  2. Na guia Configurações, na tabela de clusters, selecione Editar na coluna Editar configuração.
  3. No menu Adicionar/editar pacotes de políticas, ative a biblioteca de modelos para . Também é possível ativar qualquer um ou todos os pacotes de políticas.
  4. Selecione Salvar alterações.

Policy Controller da gcloud

Para restaurar a biblioteca de modelos de restrição, execute o seguinte comando:

gcloud container fleet policycontroller content templates enable \
    --memberships=MEMBERSHIP_NAME

Substitua MEMBERSHIP_NAME pelo nome de assinatura do cluster registrado para ativar a biblioteca de modelos de restrição. Você pode especificar várias associações separadas por vírgula.

gcloud ConfigManagement

Se você desativou a biblioteca de modelos de restrição ou desinstalou todos os modelos de restrição, será possível restaurá-la definindo spec.policyController.templateLibraryInstalled como true na configuração do Controlador de Políticas.

Para reiniciar o pod do Operador, use o seguinte comando:

kubectl delete pod -n config-management-system -l k8s-app=config-management-operator

A seguir