Como bloquear implantações com autenticação binária

1. Introdução

A autorização binária é um controle de segurança do ambiente de implantação que garante que apenas imagens de contêiner confiáveis sejam implantadas no Google Kubernetes Engine (GKE) ou no Cloud Run. Com esse controle, é possível solicitar que todas as imagens sejam assinadas por autoridades confiáveis durante o processo de desenvolvimento e, depois disso, aplicar a validação da assinatura ao implantar. Ao aplicar a validação, você assume maior controle sobre o ambiente de contêineres e garante que apenas imagens verificadas sejam integradas ao processo de criação e lançamento.

O diagrama a seguir mostra os componentes em uma configuração de autorização binária/Cloud Build:

Pipeline de atestado da autorização binária do Cloud Build.**Figura 1.**Pipeline do Cloud Build que cria um atestado de autorização binária.

Nesse pipeline:

  1. O código para criar a imagem do contêiner é enviado para um repositório de origem, como o Cloud Source Repositories.
  2. O Cloud Build, uma ferramenta de integração contínua (CI), cria e testa o contêiner.
  3. O build envia a imagem do contêiner para o Container Registry ou outro registro que armazena as imagens criadas.
  4. O Cloud Key Management Service, que fornece gerenciamento de chaves para o par de chaves criptográficas, assina a imagem do contêiner. A assinatura resultante é armazenada em um atestado recém-criado.
  5. No momento da implantação, o atestador verifica o atestado usando a chave pública do par de chaves. A autorização binária aplica a política exigindo que atestados assinados implantem a imagem do contêiner.

Neste laboratório, você vai se concentrar nas ferramentas e técnicas para proteger os artefatos implantados. Este laboratório se concentra em artefatos (contêineres) depois de criados, mas não implantados em um ambiente específico.

O que você vai aprender

  • Assinatura de imagens
  • Políticas de controle de admissão
  • Assinatura de imagens digitalizadas
  • Autorizar imagens assinadas
  • Imagens não assinadas bloqueadas

2. Configuração e requisitos

Configuração de ambiente personalizada

  1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google Você pode atualizar a qualquer momento.
  • O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. normalmente você não se importa com o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, que normalmente é identificado como PROJECT_ID. Se você não gostar do ID gerado, poderá gerar outro ID aleatório. Como alternativa, você pode tentar o seu próprio e ver se ele está disponível. Ela não pode ser alterada após essa etapa e permanecerá durante a duração do projeto.
  • Para sua informação, há um terceiro valor, um Número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
  1. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e não gerar faturamento além deste tutorial, exclua os recursos criados ou exclua o projeto inteiro. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Configuração do ambiente

No Cloud Shell, defina o ID e o número do projeto. Salve-as como variáveis PROJECT_ID e PROJECT_ID.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

Ativar serviços

Ative todos os serviços necessários:

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com

Criar repositório do Artifact Registry

Neste laboratório, você vai usar o Artifact Registry para armazenar e verificar imagens. Crie o repositório com o comando a seguir.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

Configure o Docker para utilizar suas credenciais da gcloud ao acessar o Artifact Registry.

gcloud auth configure-docker us-central1-docker.pkg.dev

Criar e mudar para um diretório de trabalho

mkdir vuln-scan && cd vuln-scan

Definir uma imagem de amostra

Crie um arquivo chamado Dockerfile com o conteúdo abaixo.

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

Crie um arquivo chamado main.py com o conteúdo a seguir

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

Criar e enviar a imagem para RA

Use o Cloud Build para criar e enviar automaticamente seu contêiner para o Artifact Registry.

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

3. Assinatura de imagens

O que é um atestador

Atestador

  • Essa pessoa/processo é responsável por um elo na cadeia de confiança do sistema.
  • Ele detém uma chave criptográfica e assina uma imagem se ela for aprovada no processo de aprovação.
  • Enquanto o criador de políticas determina a política de maneira abstrata e de alto nível, o atestador é responsável por aplicar de forma concreta algum aspecto da política.
  • Pode ser uma pessoa real, como um testador de controle de qualidade ou gerente, ou um bot em um sistema de CI.
  • A segurança do sistema depende da confiabilidade. Por isso, é importante que as chaves privadas sejam mantidas em segurança.

Cada uma dessas funções pode representar uma pessoa ou uma equipe na sua organização. Em um ambiente de produção, esses papéis provavelmente seriam gerenciados por projetos separados do Google Cloud Platform (GCP), e o acesso aos recursos seria compartilhado entre eles de maneira limitada usando o Cloud IAM.

a37eb2ed54b9c2eb.png

Os atestadores na autorização binária são implementados com base na API Cloud Container Analysis. Por isso, é importante descrever como isso funciona antes de avançar. A API Container Analysis foi projetada para permitir a associação de metadados a imagens de contêiner específicas.

Por exemplo, uma nota pode ser criada para rastrear a vulnerabilidade Heartbleed. Os fornecedores de segurança criariam scanners para testar imagens de contêiner quanto à vulnerabilidade e criariam uma ocorrência associada a cada contêiner comprometido.

208aa5ebc53ff2b3.png

Além de rastrear vulnerabilidades, o Container Analysis foi projetado para ser uma API de metadados genérica. A autorização binária usa o Container Analysis para associar assinaturas às imagens de contêiner que estão sendo verificadas**.** Uma nota do Container Analysis é usada para representar um único atestador, e as ocorrências são criadas e associadas a cada contêiner aprovado pelo atestador.

A API Binary Authorization usa os conceitos de "atestadores" e "atestados", mas são implementados usando observações e ocorrências correspondentes na API Container Analysis.

63a701bd0057ea17.png

Criar uma nota de atestador

Uma nota do atestador é simplesmente um pequeno pedaço de dado que funciona como um rótulo para o tipo de assinatura que está sendo aplicada. Por exemplo, uma observação pode indicar a verificação de vulnerabilidades, enquanto outra pode ser usada para a aprovação do controle de qualidade. A nota será mencionada no processo de assinatura.

919f997db0ffb881.png

Criar uma nota

cat > ./vulnz_note.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "Container Vulnerabilities attestation authority"
    }
  }
}
EOM

Armazenar a nota

NOTE_ID=vulnz_note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./vulnz_note.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Verificar a nota

curl -vvv  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Agora sua observação está salva na API Container Analysis.

Como criar um atestador

Os atestadores são usados para realizar o processo de assinatura da imagem e anexarão uma ocorrência da nota à imagem para verificação posterior. Para usar seu atestador, você também precisa registrar a nota com autorização binária:

ed05d438c79b654d.png

Criar atestador

ATTESTOR_ID=vulnz-attestor

gcloud container binauthz attestors create $ATTESTOR_ID \
    --attestation-authority-note=$NOTE_ID \
    --attestation-authority-note-project=${PROJECT_ID}

Verificar atestador

gcloud container binauthz attestors list

A última linha indica NUM_PUBLIC_KEYS: 0. Você vai fornecer as chaves em uma etapa posterior.

Além disso, o Cloud Build cria automaticamente o atestador built-by-cloud-build no seu projeto quando você executa uma versão que gera imagens. Portanto, o comando acima retorna dois atestadores, vulnz-attestor e built-by-cloud-build. Depois que as imagens são criadas, o Cloud Build assina e cria automaticamente atestados para elas.

Adicionando papel do IAM

A conta de serviço de autorização binária precisa de direitos para acessar as observações do atestado. Forneça o acesso com a seguinte chamada de API

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}"  --format="value(projectNumber)")

BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"


cat > ./iam_request.json << EOM
{
  'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${BINAUTHZ_SA_EMAIL}'
        ]
      }
    ]
  }
}
EOM

Use o arquivo para criar a política do IAM

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @./iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Como adicionar uma chave KMS

1e3af7c177f7a311.png

Antes de usar esse atestador, sua autoridade precisa criar um par de chaves criptográficas que possa ser usado para assinar imagens de contêiner. Isso pode ser feito no Google Cloud Key Management Service (KMS).

Primeiro, adicione algumas variáveis de ambiente para descrever a chave nova

KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1

Criar um keyring para armazenar um conjunto de chaves

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

Criar um novo par de chaves de assinatura assimétrica para o atestador

gcloud kms keys create "${KEY_NAME}" \
    --keyring="${KEYRING}" --location="${KEY_LOCATION}" \
    --purpose asymmetric-signing   \
    --default-algorithm="ec-sign-p256-sha256"

Sua chave será exibida na página KMS do console do Google Cloud.

Agora, associe a chave ao seu atestador usando o comando gcloud binauthz:

gcloud beta container binauthz attestors public-keys add  \
    --attestor="${ATTESTOR_ID}"  \
    --keyversion-project="${PROJECT_ID}"  \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

Se você imprimir a lista de autoridades novamente, vai encontrar uma chave registrada:

gcloud container binauthz attestors list

Como criar um atestado assinado

Agora, você tem os recursos configurados que permitem assinar imagens. Use o atestador criado anteriormente para assinar a imagem do contêiner com que você está trabalhando.

858d7e6feeb6f159.png

Um atestado precisa incluir uma assinatura criptográfica para declarar que o atestador verificou uma imagem de contêiner específica e está seguro para ser executado no seu cluster. Para especificar qual imagem de contêiner será atestada, você precisa determinar o resumo dela.

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

Agora você pode usar a gcloud para criar seu atestado. O comando apenas recebe os detalhes da chave que você quer usar para assinatura e a imagem de contêiner específica que você quer aprovar

gcloud beta container binauthz attestations sign-and-create  \
    --artifact-url="${CONTAINER_PATH}@${DIGEST}" \
    --attestor="${ATTESTOR_ID}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${PROJECT_ID}" \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

Em termos do Container Analysis, isso criará uma nova ocorrência e a anexará à nota do atestador. Para garantir que tudo funcionou como esperado, liste seus atestados

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

4. Políticas de controle de admissão

A autorização binária é um recurso do GKE e do Cloud Run que permite validar regras antes que uma imagem de contêiner seja executada. A validação é executada em qualquer solicitação para executar uma imagem, seja ela de um pipeline de CI/CD confiável ou um usuário tentando implantar uma imagem manualmente. Com esse recurso, você protege os ambientes de execução de maneira mais eficaz do que apenas as verificações de pipeline de CI/CD.

Para entender esse recurso, você vai modificar a política padrão do GKE para aplicar uma regra de autorização rígida.

Crie o cluster do GKE

Crie o cluster do GKE com a autorização binária ativada:

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Permita que o Cloud Build seja implantado neste cluster:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/container.developer"

Política "Permitir tudo"

Primeiro, verifique o estado da política padrão e sua capacidade de implantar qualquer imagem

  1. Revisar política atual
gcloud container binauthz policy export
  1. A política de aplicação está definida como ALWAYS_ALLOW.

evaluationMode: ALWAYS_ALLOW

  1. Implante o exemplo para verificar se é possível implantar qualquer coisa
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
  1. Verificar se a implantação funcionou
kubectl get pods

A saída a seguir será exibida:

161db370d99ffb13.png

  1. Excluir implantação
kubectl delete pod hello-server

Política Negar tudo

Agora atualize a política para proibir todas as imagens.

  1. Exportar a política atual para um arquivo editável
gcloud container binauthz policy export  > policy.yaml
  1. Alterar a política

Em um editor de texto, altere o "avaliaçãoMode" de ALWAYS_ALLOW para ALWAYS_DENY.

edit policy.yaml

O arquivo YAML da política será exibido da seguinte maneira:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

Essa política é relativamente simples. A linha globalPolicyEvaluationMode declara que esta política estende a política global definida pelo Google. Isso permite que todos os contêineres oficiais do GKE sejam executados por padrão. Além disso, a política declara uma defaultAdmissionRule que declara que todos os outros pods serão rejeitados. A regra de admissão inclui uma linha enforcementMode, que declara que todos os pods que não estiverem em conformidade com essa regra devem ser impedidos de serem executados no cluster.

Para instruções sobre como criar políticas mais complexas, consulte a documentação da autorização binária.

657752497e59378c.png

  1. Abra o Terminal, aplique a nova política e aguarde alguns segundos para que a alteração seja propagada.
gcloud container binauthz policy import policy.yaml
  1. Tentativa de implantação da carga de trabalho de amostra
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
  1. A implantação falha com a seguinte mensagem
Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Reverter a política para permitir todos

Antes de prosseguir para a próxima seção, reverta as alterações de política

  1. Alterar a política

Em um editor de texto, altere o "avaliaçãoMode" de ALWAYS_DENY para ALWAYS_ALLOW.

edit policy.yaml

O arquivo YAML da política será exibido da seguinte maneira:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy
  1. Aplicar a política revertida
gcloud container binauthz policy import policy.yaml

5. Assinar imagens digitalizadas

Você ativou a assinatura de imagens e usou manualmente o atestador para assinar sua imagem de amostra. Na prática, convém aplicar atestados durante processos automatizados, como pipelines de CI/CD.

Nesta seção, você vai configurar o Cloud Build para atestar imagens automaticamente.

Papéis

Adicione o papel Visualizador de atestador de autorização binária à conta de serviço do Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

Adicione o papel Signatário/Verificador de CryptoKey do Cloud KMS à conta de serviço do Cloud Build (assinatura baseada em KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

Adicione o papel Anexador de notas do Container Analysis à conta de serviço do Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

Conceder acesso à conta de serviço do Cloud Build

O Cloud Build vai precisar de direitos para acessar a API de verificação sob demanda. Forneça acesso com os comandos a seguir.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

Preparar a etapa personalizada do Cloud Build

Você vai usar uma etapa do Custom Build no Cloud Build para simplificar o processo de atestado. O Google oferece essa etapa de criação personalizada, que contém funções auxiliares para simplificar o processo. Antes do uso, o código da etapa personalizada de build precisa ser integrado a um contêiner e enviado ao Cloud Build. Para fazer isso, execute os seguintes comandos:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community

Adicione uma etapa de assinatura ao seu cloudbuild.yaml

Nesta etapa, você vai adicionar a etapa de atestado ao seu pipeline do Cloud Build.

  1. Revise a etapa de assinatura abaixo.

Somente revisão. Não copiar

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'
  1. Grave um arquivo cloudbuild.yaml com o pipeline completo abaixo.
cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'



images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

Executar o build

gcloud builds submit

Revisar o build no histórico do Cloud Build

Abra o console do Cloud na página Histórico do Cloud Build e revise o build mais recente e a execução das etapas de build.

6. Autorizar imagens assinadas

Nesta seção, você vai atualizar o GKE para usar a autorização binária para validar se uma imagem tem uma assinatura da verificação de vulnerabilidades antes de permitir a execução dela.

d5c41bb89e22fd61.png

Atualizar a política do GKE para exigir o atestado

Exigir que as imagens sejam assinadas pelo atestador adicionando clusterAdmissionRules à política BinAuth do GKE

No momento, o cluster está executando uma política com uma regra: permitir contêineres de repositórios oficiais e rejeitar todos os outros.

Substitua a política pela configuração atualizada usando o comando abaixo.

COMPUTE_ZONE=us-central1-a

cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  ${COMPUTE_ZONE}.binauthz:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM

Agora você deve ter um novo arquivo no disco, chamado updated_policy.yaml. Agora, em vez da regra padrão que rejeita todas as imagens, primeiro ele verifica se há verificações no atestador.

822240fc0b02408e.png

Faça o upload da nova política para a autorização binária:

gcloud beta container binauthz policy import binauth_policy.yaml

Implantar uma imagem assinada

Acesse o resumo da imagem boa

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
    --format='get(image_summary.digest)')

Usar o resumo na configuração do Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Implantar o app no GKE

kubectl apply -f deploy.yaml

Analise a carga de trabalho no console e observe se a implantação da imagem foi concluída.

7. Imagens não assinadas bloqueadas

Criar uma imagem

Nesta etapa, você vai usar o Docker local para criar a imagem no cache local.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

Envie a imagem não assinada para o repositório

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

Acessar o resumo da imagem ruim

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
    --format='get(image_summary.digest)')

Usar o resumo na configuração do Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Tentar implantar o app no GKE

kubectl apply -f deploy.yaml

Analise a carga de trabalho no console e observe o erro que informa que a implantação foi negada:

No attestations found that were valid and signed by a key trusted by the attestor

8. Parabéns!

Parabéns, você concluiu o codelab.

O que aprendemos:

  • Assinatura de imagens
  • Políticas de controle de admissão
  • Assinatura de imagens digitalizadas
  • Autorizar imagens assinadas
  • Imagens não assinadas bloqueadas

O que vem em seguida:

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto ou mantenha o projeto e exclua cada um dos recursos.

Excluir o projeto

O jeito mais fácil de evitar cobranças é excluindo o projeto que você criou para este tutorial.

—

Última atualização: 21/03/2023