Configurar 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, mostraremos como configurar uma política de autorização binária de amostra.

Antes de começar

Verifique se os clusters têm uma versão compatível do Google Distributed Cloud. A autorização binária é compatível com os ambientes a seguir.

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

VMware
Distributed Cloud for VMware (Google Distributed Cloud) 1.4 ou mais recente.
O serviço de autorização binária usa um endereço IP externo, acessível com uma conexão de Internet normal. Configure suas regras de firewall para HTTPS para permitir que o cluster de usuário acesse o endpoint 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 você quiser usar registros de auditoria do Cloud centralizados para visualizar entradas de registro de auditoria, incluindo as da autorização binária para fora do Google Cloud, configure os Registros de auditoria do Cloud na configuração do cluster.

Bare Metal
Configure os Registros de auditoria do Cloud no Google Distributed Cloud.

VMware
Configure os Registros de auditoria do Cloud no Google Distributed Cloud.
É necessário ativar a API Binary Authorization da seguinte maneira:
1. Acesse o Console do Google Cloud.
  
  Ative as APIs
2. Na lista suspensa de projetos, selecione o projeto host da frota. É possível encontrar isso na Seção gkeConnect do arquivo de configuração do cluster de usuário. Este é o projeto do Google Cloud que conecta o cluster de usuário ao Google Cloud.

Configurar a autorização binária

Nesta seção, você vai configurar a autorização binária no cluster local.

Especificar as variáveis de ambiente de instalação

Para especificar as variáveis de ambiente:

Como usar a Identidade da carga de trabalho

Especifique o projeto host da frota:
```
export PROJECT_ID=PROJECT_ID
```
Defina o ID do participante da frota como o ID do cluster:

O ID do participante é listado na coluna NAME quando você executa comando gcloud container fleet memberships list.
```
export MEMBERSHIP_ID=CLUSTER_NAME
```

Como usar a chave da conta de serviço

Especifique o projeto host da frota:
```
export PROJECT_ID=PROJECT_ID
```
Substitua PROJECT_ID pelo projeto do Google Cloud na seção gkeConnect do arquivo de configuração do cluster de usuário.
Especifique o caminho do arquivo kubeconfig do cluster de usuário:
```
export KUBECONFIG=PATH
```
Substitua PATH pelo caminho do arquivo kubeconfig do cluster de usuário.
Escolha um nome para a conta de serviço de acesso da API Binary Authorization:
```
export SA_NAME=SERVICE_ACCOUNT_NAME
```
Substitua SERVICE_ACCOUNT_NAME pelo nome da conta de serviço de sua escolha. O módulo de autorização binária usa essa conta de serviço para acessar a API Binary Authorization.
Especifique o caminho para o arquivo de chave da conta de serviço que você fará o download posteriormente neste guia:
```
export SA_JSON_PATH=SA_KEY_FILE_PATH
```
Substitua SA_KEY_FILE_PATH pelo caminho do arquivo de chave JSON para a conta de serviço.

Instalar o módulo de autorização binária no cluster de usuário

Para instalar o módulo de autorização binária:

Como usar a Identidade da carga de trabalho

A Identidade da carga de trabalho da frota permite que as cargas de trabalho no seu cluster sejam autenticadas no Google sem que você precise fazer o download, alternar manualmente e gerenciar as chaves da conta de serviço do Google Cloud. Saiba mais sobre como a Identidade da carga de trabalho da frota funciona e as vantagens de usá-la em Usar a Identidade da carga de trabalho da frota.

Conceda o papel binaryauthorization.policyEvaluator para a conta de serviço do Kubernetes no projeto host 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. Crie um diretório chamado binauthz.
2. Altere para o diretório.

Faça o download do arquivo manifest-wi-0.2.6.yaml.tmpl que você usa para instalar o Módulo de autorização binária no seu usuário cluster:

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 usuário:
```
kubectl apply -f manifest-0.2.6.yaml
```

Verifique se a implantação foi criada:

kubectl get pod --namespace binauthz-system

Você verá o pod binauthz-module-deployment-* listado com Status Running e 1/1 pods prontos, semelhante a esta saída:

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

Como usar a chave da conta de serviço

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

Conceda o papel binaryauthorization.policyEvaluator para a conta de serviço de acesso da API de autorização binária no projeto host da 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. Crie um diretório chamado binauthz.
2. Altere para o diretório.

Faça o download do arquivo manifest-0.2.6.yaml que você usa para instalar o Módulo de autorização binária no seu usuário cluster:

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 arquivo YAML para o namespace binauthz-system.

Salve o seguinte em um arquivo chamado namespace.yaml:

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

Configure o namespace no cluster de usuário:
```
kubectl apply -f namespace.yaml
```
Você verá uma saída semelhante a esta:
```
namespace/binauthz-system created
```

Faça o download de um arquivo de chave JSON para essa conta de serviço;

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

Salve a chave da conta de serviço como um secret do Kubernetes no cluster de usuário:

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 usuário:
```
kubectl apply -f manifest-0.2.6.yaml
```

Verifique se a implantação foi criada:

kubectl get pod --namespace binauthz-system

Você verá o pod binauthz-module-deployment-* listado com Status Running e 1/1 pods prontos, semelhante a esta saída:

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

Configurar e usar políticas de autorização binária

Nesta seção, mostramos como configurar e usar políticas de autorização binária para clusters no local.

Em cada exemplo, configure a política e, em seguida, teste-a tentando implantar uma imagem de contêiner no cluster do GKE.

Permitir todos

Esta seção demonstra um caso de sucesso. Configure a política de autorização binária para que uma imagem de contêiner atenda à política e seja implantada.

No Google Cloud, faça o seguinte:

Console

No Console do Google Cloud, acesse a página "Autorização binária".

Acesse Autorização binária
Selecione o ID do projeto host da frota.
Clique em Editar política.
Em Regra padrão do projeto, selecione Permitir todas as imagens.
Clique em Save Policy.

gcloud

Definir o PROJECT_ID do host da frota sobre o projeto. Esse ID do projeto está no campo gkeConnect no arquivo de configuração do cluster de usuário.
```
export PROJECT_ID=PROJECT_ID
```
Defina o projeto padrão do Google Cloud.
```
gcloud config set project ${PROJECT_ID}
```

Exporte o arquivo YAML da política para o sistema local:

gcloud container binauthz policy export  > policy.yaml

Seu arquivo YAML tem a seguinte aparência:

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

Editar policy.yaml.
Defina evaluationMode como ALWAYS_ALLOW.
Se você tiver um bloco requireAttestationsBy no arquivo, exclua-o.
Salve o arquivo.

Importe policy.yaml da seguinte maneira:

gcloud container binauthz policy import policy.yaml

Para adicionar uma imagem isenta à lista de permissões, inclua o seguinte no arquivo de política:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

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

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

Crie um arquivo de manifesto para um pod.

Salve o seguinte em um arquivo chamado pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

Crie o pod:
```
kubectl apply -f pod.yaml
```
Você verá que o pod foi implantado com sucesso.
Exclua o pod:
```
kubectl delete -f pod.yaml
```

Não permitir todos

Nesta seção, demonstramos um caso de falha. Nesta seção, você configurará a política padrão para proibir a implantação da imagem do contêiner.

No Google Cloud, faça o seguinte:

Console

No Console do Google Cloud, acesse a página "Autorização binária".

Acesse Autorização binária
Verifique se o projeto host da frota está selecionado.
Clique em Editar política.
Em Regra padrão do projeto, selecione Não permitir todas as imagens.
Clique em Salvar política.

gcloud

Defina o PROJECT_ID como seu ID do projeto host da frota.
```
export PROJECT_ID=PROJECT_ID
```

Defina o projeto padrão do Google Cloud.

gcloud config set project ${PROJECT_ID}

Exporte o arquivo YAML da política:

gcloud container binauthz policy export  > policy.yaml

Editar policy.yaml.
Defina evaluationMode como ALWAYS_DENY.
Se você tiver um bloco requireAttestationsBy no arquivo, exclua-o.
Salve o arquivo.

Importe policy.yaml da seguinte maneira:

gcloud container binauthz policy import policy.yaml

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

Crie um arquivo de manifesto para um pod.

Salve o seguinte em um arquivo chamado pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

Crie o pod:

kubectl apply -f pod.yaml

Você verá que a implantação do pod foi bloqueada. A saída será assim:

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

Conseguir o ID do recurso do cluster de usuário

Nesta seção, mostramos como compor o ID de recurso do cluster de usuário. Na sua política de autorização binária, é possível criar regras específicas do cluster. Você associa essas regras a um ID de recurso específico do cluster, que é baseado no ID do cluster.

Você consegue o ID do recurso da seguinte maneira:

Console

No console do Google Cloud, acesse a página Clusters do GKE.

Acessar Clusters
Selecione o ID do projeto host da frota para seus clusters. Esse ID do projeto está na seção gkeConnect do arquivo de configuração do cluster de usuário.
Na lista de clusters, encontre o ID do cluster em Nome .
Para criar o ID do recurso, adicione o prefixo global. ao ID do cluster para que o ID tenha este formato: global.CLUSTER_ID.

gcloud

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

Encontre o ID do cluster no campo spec.owner.id da saída. Exemplo de saída:

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.

Use esse ID de recurso ao definir regras específicas do cluster. Saiba como definir regras específicas do cluster usando o Console do Google Cloud ou a CLI gcloud.

Atualizar a política de falhas

O webhook do módulo de autorização binária pode ser configurado para falha ao abrir ou falha ao fechar.

Falha ao fechar

Para atualizar a política de falha para que ela falhe ao fechar, faça o seguinte:

Dite o arquivo manifest-0.2.6.yaml e defina failPolicy como Fail.

Reative o webhook:

kubectl apply -f manifest-0.2.6.yaml

Você verá uma saída semelhante a esta:

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

Fail open

Para atualizar a política de falha para que ela falhe ao abrir, faça o seguinte:

Dite o arquivo manifest-0.2.6.yaml e defina failPolicy como Ignore.

Reative o webhook:

kubectl apply -f manifest-0.2.6.yaml

Você verá uma saída semelhante a esta:

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 falha do webhook.

Limpar

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

kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration

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

A seguir

Para verificar a conformidade da política no momento da criação do pod sem bloquear a criação dele, consulte Ativar teste.
Para forçar a criação de um pod que o aplicador de autorização binária não bloquearia, consulte Usar implantação forçada.
Use o atestador built-by-cloud-build para implantar somente imagens criadas pelo Cloud Build).
Para implementar uma política de autorização binária baseada em atestador, consulte o seguinte:
- Configurar uma política usando o Console do Google Cloud ou a ferramenta de linha de comando. Definir a regra padrão ou específica do cluster para exigir atestados.
- Criar um atestador usando o Console do Google Cloud ou a ferramenta de linha de comando.
- Criar um atestado.
Para acessar eventos de registro relacionados à autorização binária para o Distributed Cloud, consulte Veja os eventos dos Registros de auditoria do Cloud.
Monitorar as métricas.