Esta página foi traduzida pela API Cloud Translation.

Configuração para clusters no local

Este documento mostra como configurar a autorização binária para clusters no local criados como parte do Google Distributed Cloud. Em seguida, mostra como configurar uma política de autorização binária de exemplo.

Antes de começar

Certifique-se de que os seus clusters têm uma versão suportada do Google Distributed Cloud. A autorização binária suporta os seguintes ambientes.

Bare metal
Google Distributed Cloud 1.14 ou 1.15. Para a versão 1.16 ou posterior, a autorização binária pode ser configurada durante a criação ou a atualização do cluster.

VMware
Distributed Cloud for VMware (Google Distributed Cloud) 1.4 ou posterior.
O serviço de autorização binária usa um endereço IP externo, acessível através de uma ligação à Internet normal. Configure as regras da firewall para HTTPS para permitir que o cluster de utilizadores aceda ao ponto final binaryauthorization.googleapis.com.

Bare metal
Configure as regras de firewall do Google Distributed Cloud.

VMware
Configure as regras de firewall do Google Distributed Cloud.
Se quiser usar registos de auditoria da nuvem centralizados para ver entradas do registo de auditoria, incluindo as da autorização binária para clusters fora Google Cloud, tem de configurar os registos de auditoria da nuvem na configuração do cluster.

Bare metal
Configure os registos de auditoria do Cloud no Google Distributed Cloud.

VMware
Configure os registos de auditoria do Cloud no Google Distributed Cloud.
Tem de ativar a API Binary Authorization da seguinte forma:
1. Aceda à Google Cloud consola.
  
  Ative as APIs
2. Na lista pendente de projetos, selecione o projeto anfitrião da frota. Pode encontrar esta opção na secção gkeConnect do ficheiro de configuração do cluster de utilizadores. Este é o Google Cloud projeto que associa o seu cluster de utilizadores ao Google Cloud.

Configure a autorização binária

Nesta secção, configura a autorização binária no seu cluster no local.

Especifique variáveis de ambiente de instalação

Para especificar as variáveis de ambiente, faça o seguinte:

Usar o Workload Identity

Especifique o projeto anfitrião da frota:
```
export PROJECT_ID=PROJECT_ID
```
Defina o ID de membro da frota para o ID do cluster:

O ID de membro é apresentado na coluna NAME quando executa o comando gcloud container fleet memberships list.
```
export MEMBERSHIP_ID=CLUSTER_NAME
```

Usar a chave da conta de serviço

Especifique o projeto anfitrião da frota:
```
export PROJECT_ID=PROJECT_ID
```
Substitua PROJECT_ID pelo projeto na secção gkeConnect do ficheiro de configuração do cluster de utilizadores. Google Cloud
Especifique o caminho do ficheiro kubeconfig do cluster de utilizadores:
```
export KUBECONFIG=PATH
```
Substitua PATH pelo caminho do ficheiro kubeconfig do cluster de utilizadores.
Escolha um nome para a conta de serviço de acesso à API Binary Authorization:
```
export SA_NAME=SERVICE_ACCOUNT_NAME
```
Substitua SERVICE_ACCOUNT_NAME pelo nome da conta de serviço à sua escolha. O módulo de autorização binária usa esta conta de serviço para aceder à API Binary Authorization.
Especifique o caminho para o ficheiro de chave da conta de serviço que transfere mais adiante neste guia:
```
export SA_JSON_PATH=SA_KEY_FILE_PATH
```
Substitua SA_KEY_FILE_PATH pelo caminho do ficheiro de chave JSON para a conta de serviço.

Instale o módulo de Autorização binária no cluster de utilizadores

Para instalar o módulo de autorização binária, faça o seguinte:

Usar o Workload Identity

A identidade de carga de trabalho da frota permite que as cargas de trabalho no seu cluster sejam autenticadas no Google sem ter de transferir, rodar manualmente e, geralmente, gerir Google Cloud chaves de contas de serviço. Pode saber mais sobre o funcionamento do Workload Identity da frota e as vantagens da sua utilização no artigo Use o Workload Identity da frota.

Conceda a função binaryauthorization.policyEvaluator à conta de serviço do Kubernetes no projeto anfitrião da frota:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[binauthz-system/binauthz-admin]" \
    --role="roles/binaryauthorization.policyEvaluator"

Crie um diretório de trabalho:
1. Cria um diretório denominado binauthz.
2. Altere para o diretório.

Transfira o ficheiro manifest-wi-0.2.6.yaml.tmpl, que usa para instalar o módulo de autorização binária no cluster do utilizador:

Bare metal

gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .

VMware

gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .

Substitua as variáveis de ambiente no modelo:

envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml

Instale o módulo de autorização binária no cluster de utilizadores:
```
kubectl apply -f manifest-0.2.6.yaml
```

Verifique se a implementação foi criada:

kubectl get pod --namespace binauthz-system

Vê o pod binauthz-module-deployment-* listado com Status de Running e 1/1 pods prontos, semelhante a este resultado:

NAME                                          READY   STATUS    RESTARTS   AGE
binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s

Usar a chave da conta de serviço

Defina o projeto predefinido para a CLI gcloud:
```
gcloud config set project ${PROJECT_ID}
```
Crie uma conta de serviço de acesso à API Binary Authorization:
```
gcloud iam service-accounts create ${SA_NAME}
```

Conceda a função binaryauthorization.policyEvaluator à conta de serviço de acesso à API Binary Authorization no projeto anfitrião da sua frota:

gcloud projects add-iam-policy-binding ${PROJECT_ID}\
    --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/binaryauthorization.policyEvaluator"

Crie um diretório de trabalho:
1. Cria um diretório denominado binauthz.
2. Altere para o diretório.

Transfira o ficheiro manifest-0.2.6.yaml, que usa para instalar o módulo de autorização binária no cluster do utilizador:

Bare metal

gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .

VMware

gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .

Crie um ficheiro YAML para o espaço de nomes binauthz-system.

Copie o seguinte para um ficheiro denominado namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    control-plane: binauthz-controller
  name: binauthz-system

Crie o namespace no cluster de utilizadores:
```
kubectl apply -f namespace.yaml
```
Vê um resultado semelhante ao seguinte:
```
namespace/binauthz-system created
```

Transfira um ficheiro de chave JSON para a sua conta de serviço:

gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

Guarde a chave da conta de serviço como um segredo do Kubernetes no cluster de utilizadores:

kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}

Instale o módulo de autorização binária no cluster de utilizadores:
```
kubectl apply -f manifest-0.2.6.yaml
```

Verifique se a implementação foi criada:

kubectl get pod --namespace binauthz-system

Vê o pod binauthz-module-deployment-* listado com Status de Running e 1/1 pods prontos, semelhante a este resultado:

NAME                                          READY   STATUS    RESTARTS   AGE
binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s

Configure e use políticas de autorização binária

Esta secção mostra como configurar e usar políticas de autorização binária para clusters no local.

Em cada exemplo, configura a política e, em seguida, testa-a tentando implementar uma imagem de contentor no cluster.

Permitir todas

Esta secção demonstra um caso de sucesso. Configura a política de autorização binária para que uma imagem de contentor cumpra a política e seja implementada.

No Google Cloud, faça o seguinte:

Consola

Na Google Cloud consola, aceda à página Binary Authorization.

Aceda à Autorização binária
Certifique-se de que seleciona o ID do projeto anfitrião da frota.
Clique em Editar política.
Em Regra predefinida do projeto, selecione Permitir todas as imagens.
Clique em Guardar política.

gcloud

Defina o PROJECT_ID para o projeto do anfitrião da frota. Pode encontrar este ID do projeto no campo gkeConnect no ficheiro de configuração do cluster de utilizadores.
```
export PROJECT_ID=PROJECT_ID
```
Defina o Google Cloud projeto predefinido.
```
gcloud config set project ${PROJECT_ID}
```

Exporte o ficheiro YAML da política para o seu sistema local:

gcloud container binauthz policy export  > policy.yaml

O ficheiro YAML tem o seguinte aspeto:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/<var>PROJECT_ID</var>/policy

Edite o pacote policy.yaml.
Defina evaluationMode como ALWAYS_ALLOW.
Se tiver um bloco requireAttestationsBy no ficheiro, elimine este bloco.
Guarde o ficheiro.

Importe policy.yaml da seguinte forma:

gcloud container binauthz policy import policy.yaml

Para adicionar uma imagem isenta à lista de autorizações, adicione o seguinte ao ficheiro de política:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Substitua EXEMPT_IMAGE_PATH pelo caminho para uma imagem a isentar. Para isentar imagens adicionais, adicione mais entradas - namePattern. Saiba mais sobre admissionWhitelistPatterns.

Na estação de trabalho do administrador, faça o seguinte:

Crie um ficheiro de manifesto para um pod.

Guarde o seguinte num ficheiro denominado pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: us-docker.pkg.dev/google-samples/containers/gke/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

Crie o grupo:
```
kubectl apply -f pod.yaml
```
Verifica que o pod foi implementado com êxito.
Elimine o Pod:
```
kubectl delete -f pod.yaml
```

Não permitir todos

Esta secção demonstra um caso de falha. Nesta secção, configura a política predefinida para impedir a implementação da imagem do contentor.

No Google Cloud faça o seguinte:

Consola

Na Google Cloud consola, aceda à página Binary Authorization.

Aceda à Autorização binária
Certifique-se de que o projeto de anfitrião da frota está selecionado.
Clique em Editar política.
Em Regra predefinida do projeto, selecione Não permitir todas as imagens.
Clique em Guardar política.

gcloud

Defina o PROJECT_ID para o ID do projeto anfitrião da frota.
```
export PROJECT_ID=PROJECT_ID
```

Defina o Google Cloud projeto predefinido.

gcloud config set project ${PROJECT_ID}

Exporte o ficheiro YAML da política:

gcloud container binauthz policy export  > policy.yaml

Edite o pacote policy.yaml.
Defina evaluationMode como ALWAYS_DENY.
Se tiver um bloco requireAttestationsBy no ficheiro, elimine este bloco.
Guarde o ficheiro.

Importe policy.yaml da seguinte forma:

gcloud container binauthz policy import policy.yaml

Na estação de trabalho do administrador, faça o seguinte:

Crie um ficheiro de manifesto para um pod.

Guarde o seguinte num ficheiro denominado pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: us-docker.pkg.dev/google-samples/containers/gke/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

Crie o grupo:

kubectl apply -f pod.yaml

Vê que a implementação do pod foi bloqueada. O resultado tem o seguinte aspeto:

Error from server (VIOLATES_POLICY): error when creating "pod.yaml": admission webhook "binaryauthorization.googleapis.com" denied the request: Denied by default admission rule. Overridden by evaluation mode

Obtenha o ID do recurso do cluster de utilizadores

Esta secção mostra como compor o ID do recurso do cluster para o seu cluster de utilizadores. Na sua política de autorização binária, pode criar regras específicas do cluster. Associa estas regras a um ID de recurso específico do cluster, que se baseia no ID do cluster.

Obtém o ID de recurso da seguinte forma:

Consola

Na Google Cloud consola, aceda à página Clusters do GKE.

Aceda a Clusters
Selecione o ID do projeto anfitrião da frota para os seus clusters. Pode encontrar este ID do projeto na secção gkeConnect do ficheiro de configuração do cluster de utilizadores.
Na lista de clusters, encontre o ID do cluster na coluna Nome.
Para criar o ID do recurso, adicione o prefixo global. ao ID do cluster para que o ID do recurso tenha o seguinte formato: global.CLUSTER_ID.

gcloud

Use SSH para se ligar à sua estação de trabalho de administração.
Na estação de trabalho de administração, execute o seguinte comando:
```
kubectl get membership -o yaml
```

Obtenha o ID do cluster a partir do campo spec.owner.id da saída. Segue-se um exemplo de resultado:

apiVersion: v1
items:
- apiVersion: hub.gke.io/v1
  kind: Membership
  ...
  spec:
    owner:
      id: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/my-cluster-id

No exemplo de saída, o ID do cluster é my-cluster-id.

Para criar o ID do recurso, adicione o prefixo global. ao ID do cluster. No exemplo, o ID do recurso é global.my-cluster-id.

Usa este ID do recurso quando define regras específicas do cluster. Saiba como definir regras específicas do cluster através da Google Cloud consola ou da CLI gcloud.

Atualize a política de falhas

O webhook do módulo de autorização binária pode ser configurado para falhar aberto ou falhar fechado.

Falha ao fechar

Para atualizar a política de falha para falha no fecho, faça o seguinte:

Edite o ficheiro manifest-0.2.6.yaml e defina failurePolicy como Fail

Reative o webhook:

kubectl apply -f manifest-0.2.6.yaml

Vê um resultado semelhante ao seguinte:

serviceaccount/binauthz-admin unchanged
role.rbac.authorization.k8s.io/binauthz-role configured
clusterrole.rbac.authorization.k8s.io/binauthz-role configured
rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
secret/binauthz-tls unchanged
service/binauthz unchanged
deployment.apps/binauthz-module-deployment unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured

Abertura em caso de falha

Para atualizar a política de falha para falhar em aberto, faça o seguinte:

Edite o ficheiro manifest-0.2.6.yaml e defina failurePolicy como Ignore

Reative o webhook:

kubectl apply -f manifest-0.2.6.yaml

Vê um resultado semelhante ao seguinte:

serviceaccount/binauthz-admin unchanged
role.rbac.authorization.k8s.io/binauthz-role configured
clusterrole.rbac.authorization.k8s.io/binauthz-role configured
rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
secret/binauthz-tls unchanged
service/binauthz unchanged
deployment.apps/binauthz-module-deployment unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured

Para saber mais, consulte a política de falhas de webhook.

Limpar

O exemplo de código seguinte mostra como desativar o webhook:

kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration

O seguinte exemplo de código mostra como reativar o webhook:
```
kubectl apply -f manifest-0.2.6.yaml
```
O seguinte exemplo de código mostra como eliminar todos os recursos relacionados com a autorização binária:
```
kubectl delete -f manifest-0.2.6.yaml
kubectl delete namespace binauthz-system
```

O que se segue?

Para verificar a conformidade com as políticas no momento da criação do pod sem bloquear efetivamente a criação do pod, consulte a secção Ative o teste de execução.
Para forçar a criação de um pod que o aplicador da autorização binária bloquearia de outra forma, consulte Use breakglass.
Use o built-by-cloud-build atestador para implementar apenas imagens criadas pelo Cloud Build.
Para implementar uma política de autorização binária baseada em atestador, consulte o seguinte:
- Configure uma política através da Google Cloud consola ou da ferramenta de linha de comandos. Defina a regra predefinida ou específica do cluster para exigir atestações.
- Crie um atestador através da Google Cloud consola ou da ferramenta de linha de comandos.
- Crie uma atestação.
Para ver eventos de registo relacionados com a autorização binária para o Distributed Cloud, consulte o artigo Veja eventos do Cloud Audit Logs.
Monitorize as métricas.

Configuração para clusters no local Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Bare metal

VMware

Bare metal

VMware

Bare metal

VMware

Configure a autorização binária

Especifique variáveis de ambiente de instalação

Usar o Workload Identity

Usar a chave da conta de serviço

Instale o módulo de Autorização binária no cluster de utilizadores

Usar o Workload Identity

Bare metal

VMware

Usar a chave da conta de serviço

Bare metal

VMware

Configure e use políticas de autorização binária

Permitir todas

Consola

gcloud

Não permitir todos

Consola

gcloud

Obtenha o ID do recurso do cluster de utilizadores

Consola

gcloud

Atualize a política de falhas

Falha ao fechar

Abertura em caso de falha

Limpar

O que se segue?

Configuração para clusters no local