Primeiros passos usando a CLI

Neste tutorial, mostramos como configurar e testar uma política de autorização binária que requer atestados. Esse tipo de política protege sua cadeia de suprimentos de software baseada em contêiner definindo quem pode implantar imagens de contêiner no Google Kubernetes Engine (GKE) e quais imagens de contêiner podem ser implantadas no GKE.

No momento da implantação, a autorização binária usa atestadores para verificar assinaturas digitais em atestados. Os atestados foram criados por signatários como parte de um pipeline de integração contínua (CI).

Neste tutorial, o cluster do GKE, os atestados e os atestadores estão localizados em um único projeto. Uma configuração de projeto único é muito útil para testar ou testar o serviço. Para ver um exemplo mais real, consulte configuração de vários projetos.

As etapas abaixo descrevem as tarefas que você executa na linha de comando. Para seguir essas etapas usando o Console do Google Cloud, consulte Primeiros passos com o Console.

Objetivos

Neste tutorial, você aprenderá a realizar as seguintes tarefas:

  • Criar um cluster do Google Kubernetes Engine (GKE) com autorização binária ativada
  • Criar um atestador que o aplicador de autorização binária usa para verificar a assinatura em um atestado
  • Configurar uma política que exija um atestado
  • Criar um par de chaves criptográficas para assinar atestados e depois verificá-los
  • Assinar um resumo de imagem de contêiner, criando uma assinatura
  • Criar um atestado usando a assinatura
  • Testar a política implantando uma imagem de contêiner no GKE

Custos

Neste tutorial, há componentes faturáveis do Google Cloud, a saber:

  • Container Registry
  • GKE;

Use a Calculadora de preços para gerar uma estimativa de custo com base no uso previsto. Usuários novos do Cloud Platform podem ter direito a uma avaliação gratuita.

Antes de começar

  1. Faça login na sua conta do Google.

    Se você ainda não tiver uma, inscreva-se.

  2. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar a página do seletor de projetos

  3. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  4. Instale e inicialize o SDK do Cloud..
  5. Instale o kubectl para interagir com o GKE.

Ativar autorização binária

Defina o projeto padrão.

A primeira etapa é definir o projeto padrão do Google Cloud usado pelo comando gcloud:

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

PROJECT_ID é o nome do projeto.

Ativar APIs obrigatórias

Em seguida, ative as APIs do Google Cloud para GKE, Container Analysis e autorização binária:

gcloud services enable \
    container.googleapis.com \
    containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Criar um cluster com a autorização binária ativada

Criar o cluster

Agora é possível criar um cluster do GKE com a autorização binária ativada. Este é o cluster em que você quer executar as imagens de contêiner implantadas. Ao criar o cluster, você passa a sinalização --enable-binauthz para o comando gcloud container clusters create.

Para criar o cluster, siga estas etapas:

gcloud container clusters create \
    --enable-binauthz \
    --zone us-central1-a \
    test-cluster

Aqui, você cria um cluster chamado test-cluster na zona us-central1-a do GKE.

Configurar kubectl

Também é necessário atualizar o arquivo kubeconfig local para a instalação do kubectl. Isso fornece as credenciais e as informações de endpoint necessárias para acessar o cluster no GKE.

Para atualizar o arquivo kubeconfig local:

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Ver a política padrão

Uma política na autorização binária é um conjunto de regras que regem a implantação de imagens de contêiner. Você pode ter uma política por projeto. Por padrão, a política é configurada para permitir que todas as imagens de contêiner sejam implantadas.

A autorização binária permite exportar e importar um arquivo de política no formato YAML. Esse formato reflete a estrutura de uma política conforme ela é armazenada pelo serviço. Ao configurar uma política usando comandos gcloud, você edita esse arquivo.

Para ver a política padrão, exporte o arquivo YAML da política:

gcloud container binauthz policy export

Por padrão, o arquivo tem o seguinte conteúdo:

admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/*
- namePattern: gke.gcr.io/*
- namePattern: gcr.io/stackdriver-agents/*
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/${PROJECT_ID}/policy

Aqui, a regra padrão é definida no nó defaultAdmissionRule. evaluationMode especifica que a política permite todas as tentativas de implantação de imagem.

Para mais informações sobre a estrutura de uma política, consulte a Referência do YAML de políticas.

Criar um atestador

Um atestador é a autoridade de verificação que o aplicador de autorização binária usa no momento da implantação para decidir se o GKE implantará a imagem do contêiner assinado correspondente. O atestador contém a chave pública e normalmente é gerenciado pela equipe da sua organização responsável pela segurança da cadeia de suprimentos de software.

Para criar um atestador, você precisa:

  • Crie uma observação no Container Analysis para armazenar metadados confiáveis usados no processo de autorização
  • Criar o atestador em autorização binária e associar a nota que você criou

Para este tutorial, você tem um atestador chamado test-attestor e uma nota do Container Analysis chamada test-attestor-note. Em um cenário real, você pode ter qualquer número de atestadores, cada um representando uma parte que participa do processo de autorização para uma imagem de contêiner.

Criar a nota do Container Analysis

  1. Defina variáveis que armazenam o nome do atestador e da nota do Container Analysis:

    ATTESTOR=test-attestor
    NOTE_ID=test-attestor-note
    
  2. Crie um arquivo JSON em /tmp/note_payload.json que descreva a nota do Container Analysis:

    cat > /tmp/note_payload.json << EOM
    {
      "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
      "attestation": {
        "hint": {
          "human_readable_name": "Attestor Note"
        }
      }
    }
    EOM
    
  3. Crie a nota enviando uma solicitação HTTP para a API REST do Container Analysis:

    curl -X POST \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
        --data-binary @/tmp/note_payload.json  \
        "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"
    
  4. Verifique se a nota foi criada:

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

Crie o atestador

Agora, você pode criar o atestador:

  1. Crie o atestador na autorização binária:

    gcloud container binauthz attestors create ${ATTESTOR} \
    --attestation-authority-note=${NOTE_ID} \
    --attestation-authority-note-project=${PROJECT_ID}
    
  2. Verifique se o atestador foi criado:

    gcloud container binauthz attestors list
    

O atestador que você criou ainda não pode ser usado sem um par de chaves PKIX associado, criado abaixo.

Gerar um par de chaves

A autorização binária usa chaves criptográficas para verificar com segurança a identidade dos assinantes. Isso garante que somente imagens de contêiner autorizadas possam ser implantadas. O par de chaves consiste em uma chave privada e uma chave pública. O signer usa a chave privada para assinar o resumo da imagem do contêiner, produzindo uma assinatura que é armazenada em um atestado. A chave pública é armazenada no atestador. No momento da implantação, o implementador de autorização binária usa a chave pública do atestador para verificar a assinatura no atestado antes de permitir a implantação do contêiner.

Neste tutorial, use o formato Infraestrutura de chave pública (X.509) (PKIX, na sigla em inglês) para chaves criptográficas. Este tutorial usa o Algoritmo de assinatura digital de curva elíptica (ECDSA, na sigla em inglês) recomendado para gerar um par de chaves PKIX. Também é possível usar chaves RSA ou PGP para assinatura.

Algoritmos e finalidades de chave para mais informações sobre algoritmos de assinatura.

As chaves geradas e armazenadas pelo Cloud Key Management Service (Cloud KMS) são compatíveis com o PKIX. Consulte Como criar atestadores usando a CLI para mais informações sobre o uso de chaves PKIX e do Cloud KMS.

Para gerar um par de chaves PKIX, siga estas etapas:

  1. Crie a chave privada:

    PRIVATE_KEY_FILE="/tmp/ec_private.pem"
    openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
    
  2. Extraia a chave pública da chave privada:

    PUBLIC_KEY_FILE="/tmp/ec_public.pem"
    openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
    
  3. Adicione a chave pública ECDSA ao atestador.

    Agora, adicione a chave pública exportada ao atestador para que ela possa ser usada pela autorização binária para verificação de identidade:

    gcloud --project="${PROJECT_ID}" \
        beta container binauthz attestors public-keys add \
        --attestor="${ATTESTOR}" \
        --pkix-public-key-file=${PUBLIC_KEY_FILE} \
        --pkix-public-key-algorithm=ecdsa-p256-sha256
    
  4. Salve o código da chave pública.

    Para salvar o ID da chave pública, é possível copiá-lo da saída de public-keys add acima. Para ver o código da chave pública do atestador depois de adicioná-lo ao atestador, use gcloud container binauthz attestors describe ${ATTESTOR}:

    PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR} \
      --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
    

Configurar a política

Agora, você pode configurar sua política. Nesta etapa, você exporta o arquivo YAML da política para o sistema local e modifica a regra padrão para que exija um atestado pelo atestador definido acima.

Para configurar a política, siga estas etapas:

  1. Criar um novo arquivo de política que permita Imagens do sistema mantidas pelo Google , define o evaluationMode para REQUIRE_ATTESTATION e adiciona um nó chamado requireAttestationsBy que faz referência ao atestador que você criou:

    cat > /tmp/policy.yaml << EOM
        globalPolicyEvaluationMode: ENABLE
        defaultAdmissionRule:
          evaluationMode: REQUIRE_ATTESTATION
          enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
          requireAttestationsBy:
            - projects/${PROJECT_ID}/attestors/${ATTESTOR}
        name: projects/${PROJECT_ID}/policy
    EOM
    
  2. Importe o arquivo YAML da política para a autorização binária:

    gcloud container binauthz policy import /tmp/policy.yaml
    

Para mais informações sobre como configurar uma política, consulte Como configurar uma política usando a CLI.

Testar a política

Para testar a política configurada acima, tente implantar uma imagem de contêiner de amostra no cluster. A política bloqueará a implantação porque o atestado necessário não foi feito.

Para este tutorial, use a imagem de amostra localizada no caminho gcr.io/google-samples/hello-app no Container Registry. Esta é uma imagem de contêiner pública criada pelo Google que contém uma mensagem "Hello, World!" aplicativo de amostra.

Primeiro, tente implantar a imagem:

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

Agora verifique se a implantação foi bloqueada pela autorização binária:

kubectl get pods

O comando imprime a seguinte mensagem, que indica que a imagem não foi implantada:

No resources found.

Veja mais detalhes sobre a implantação:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

que mostra que a implantação não foi permitida pela política:

FailedCreate: Error creating: pods "hello-server-579859fb5b-hjvnr" is forbidden: image policy webhook backend denied one or more images: Denied by default admission rule. Denied by Attestation Authority. Image gcr.io/google-samples/hello-app:1.0 denied by projects/example-project/attestors/test-attestor: No attestations found

Exclua a implantação para seguir para a próxima etapa:

kubectl delete deployment hello-server

Criar um atestado

Um atestado é um documento digital criado por um signatário que certifica que o GKE tem permissão para implantar a imagem de contêiner associada. O processo de criação de um atestado às vezes é chamado de "assinatura de imagem". Um signatário pode ser uma pessoa ou, mais frequentemente, um processo automatizado executado quando uma imagem de contêiner é criada. A assinatura é criada usando a chave privada de um par de chaves. No momento da implantação, o aplicador de autorização binária usa a chave pública do Attestor para verificar a assinatura no atestado.

Neste tutorial, seu atestado simplesmente declara que você autoriza a imagem para implantação.

Para criar um atestado, siga estas etapas:

  1. Defina variáveis que armazenam o caminho do registro e o resumo da imagem:

    IMAGE_PATH="gcr.io/google-samples/hello-app"
    IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
    
  2. Gere o payload do atestado:

    gcloud container binauthz create-signature-payload \
    --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json
    

    O arquivo JSON do payload tem o seguinte conteúdo:

    {
      "critical": {
        "identity": {
          "docker-reference": "gcr.io/google-samples/hello-app"
        },
        "image": {
          "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
    882eb722c3be4"
        },
        "type": "Google cloud binauthz container signature"
      }
    }
    
  3. Assine o payload com a chave privada PKIX e gere um arquivo de assinatura:

    openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
    

    O arquivo de assinatura é uma versão assinada digitalmente do payload JSON criado acima.

  4. Crie o atestado:

    gcloud container binauthz attestations create \
        --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \
        --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \
        --signature-file=/tmp/ec_signature \
        --public-key-id="${PUBLIC_KEY_ID}"
    

    Como alternativa, para criar e validar o atestado pode ser verificado pelo atestador fornecido:

    gcloud alpha container binauthz attestations create \
        --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \
        --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \
        --signature-file=/tmp/ec_signature \
        --public-key-id="${PUBLIC_KEY_ID}" \
        --validate
    

    em que PUBLIC_KEY_ID é o ID da chave pública que você encontrou em Gerar um par de chaves PKIX acima.

  5. Verifique se o atestado foi criado:

    gcloud container binauthz attestations list \
        --attestor=$ATTESTOR --attestor-project=$PROJECT_ID
    

Para mais informações sobre como criar atestados, consulte Como criar atestados.

Testar a política outra vez

Novamente, teste a política implantando uma imagem de contêiner de amostra no cluster. Desta vez, implante a imagem usando o resumo em vez de uma tag como 1.0 ou latest, já que a autorização binária usará o caminho e o resumo da imagem para procurar atestados. Aqui, a autorização binária permite que a imagem seja implantada porque o atestado necessário foi feito.

Para implantar a imagem, siga estas etapas:

kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080

Para verificar se a imagem foi implantada:

kubectl get pods

O comando imprime uma mensagem semelhante à seguinte, que indica que a implantação foi bem-sucedida:

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

Como fazer a limpeza

Para evitar que os recursos usados neste tutorial sejam cobrados na conta do Google Cloud Platform:

Exclua o cluster que você criou no GKE:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

A seguir