Neste documento, mostramos como configurar a autorização binária para clusters do GKE. Em seguida, mostraremos como configurar uma política de autorização binária de amostra.
Antes de começar
Você precisa ter clusters do GKE registrados com o Connect. A autorização binária é compatível com os ambientes a seguir.
GKE em bare metal
GKE em Bare Metal 1.14 ou mais recente.
GKE no VMware
GKE no VMware 1.4 ou posterior.
O serviço de autorização binária usa um endereço IP público, 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
.GKE em Bare Metal
Configure as regras de firewall do GKE em Bare Metal.
GKE no VMware
Configure as regras de firewall do GKE no VMware.
Se você quiser usar os registros de auditoria do Cloud centralizados para visualizar as entradas de registro de auditoria, incluindo as da autorização binária para clusters do GKE, será preciso configurar os registros de auditoria do Cloud na configuração do cluster.
GKE em Bare Metal
Configure os Registros de auditoria do Cloud no GKE em Bare Metal.
GKE no VMware
Configurar os registros de auditoria do Cloud no GKE no VMware.
É necessário ativar a API Binary Authorization da seguinte maneira:
Acesse o Console do Google Cloud.
Na lista suspensa do projeto, selecione o projeto do Connect. Esse projeto do Google Cloud está disponível 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ê configura a autorização binária para clusters do GKE no seu cluster.
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 seu projeto do Connect:
export PROJECT_ID=PROJECT_ID
Especifique o código de assinatura do Fleet do cluster:
export MEMBERSHIP_ID=MEMBERSHIP_ID
Como usar a chave da conta de serviço
Especifique seu projeto do Connect:
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
à conta de serviço do Kubernetes no projeto do Connect: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:
Crie um diretório chamado
binauthz
.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 cluster de usuário dos clusters do GKE:GKE em Bare Metal
gsutil cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
GKE no VMware
gsutil 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 comStatus
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
à conta de serviço de acesso da API Binary Authorization no projeto do Connect: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:
Crie um diretório chamado
binauthz
.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 cluster de usuário dos clusters do GKE:anthos_clusters_on_bare_metal
gsutil cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .
anthos_clusters_on_vmware
gsutil 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 comStatus
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 do GKE.
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".
Selecione o ID do projeto do Connect.
Clique em Editar política.
Em Regra padrão do projeto, selecione Permitir todas as imagens.
Clique em Save Policy.
gcloud
Defina
PROJECT_ID
para seu projeto do Connect. Esse ID do projeto está no campogkeConnect
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
comoALWAYS_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 de administrador dos clusters do GKE, 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".
Verifique se o projeto do Connect 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 o ID do projeto do Connect.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
comoALWAYS_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 de administrador dos clusters do GKE, 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 Enterprise.
Selecione o ID do projeto do Connect para clusters do GKE. Esse ID do projeto está na seção
gkeConnect
do arquivo de configuração do cluster de usuário.Em Clusters gerenciados do Anthos, 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 tenha este formato:global.CLUSTER_ID
.
gcloud
Use o SSH para se conectar à estação de trabalho de administrador dos clusters do GKE.
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 (visualização). - 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 ver eventos de registro relacionados à autorização binária de clusters do GKE, consulte Conferir eventos de registros de auditoria do Cloud.
- Monitorar as métricas.