Configuração de vários projetos

É possível configurar a autorização binária no seu ambiente em uma configuração de projeto único ou de vários projetos. Uma configuração de vários projetos é adequada para a maioria dos usos reais da autorização binária, em que várias pessoas que atuam em papéis diferentes podem ser responsáveis por diferentes estágios do fluxo de trabalho da cadeia de suprimentos de software. Isso geralmente é chamado de separação de deveres. Por exemplo, os papéis podem ser:

  • Implantação: um processo individual ou automatizado que implanta um aplicativo no GKE de acordo com a política da empresa. Aqui, o foco é implantar o software. Um engenheiro de software ou engenheiro de DevOps normalmente faz isso.

  • Gerente de operações de segurança (SecOps): um indivíduo que gerencia as chaves autorizadas que a autorização binária usa para aplicar regras de política que exigem atestado de acordo com a política da empresa. Essa pessoa também pode criar a política, as regras e os atestadores. Esses atestadores acabam verificando um atestado, permitindo que um contêiner seja implantado no GKE. Dessa forma, somente esse papel tem acesso de gravação ao atestador.

  • Gerente de atestados: uma pessoa que cria e gerencia atestados exigidos pelos atestadores. Essa pessoa gera e gerencia as chaves criptográficas. Em seguida, eles assinam um descritor de imagem de contêiner para criar atestados. Eles gerenciam os atestados.

Neste tutorial, você vai configurar um projeto diferente para cada um dos papéis acima. Você vai configurar um projeto de implantação para alguém no papel de "implantador", um projeto de atestador para alguém no papel de gerenciador de segurança e, por fim, um projeto de confirmação para a pessoa no Gerenciador de atestados.

Em seguida, você vai configurar sua política de autorização binária com regras que exigem atestados. Por fim, você vai testar uma implantação.

Cada projeto será configurado com o controle de acesso apropriado por meio do Gerenciamento de Identidade e Acesso (IAM).

Para mais segurança, é possível usar o VPC Service Controls para proteger ainda mais os recursos criados neste tutorial. Para mais informações, consulte Como proteger com o VPC Service Controls.

Configurar o projeto do implantador

A primeira etapa é configurar o projeto do implantador.

Um projeto do implantador gerencia os clusters do Google Kubernetes Engine (GKE) em que as imagens são implantadas, bem como a política de autorização binária que rege a implantação. É possível ter mais de um projeto do implantador, dependendo do tamanho, da complexidade e de outros requisitos do ambiente.

Para configurar o projeto do implantador:

  1. Crie o projeto e ative o faturamento no Console do Google Cloud, se ainda não tiver feito isso.

  2. Nota do Gerenciamento de Identidade e Acesso: o projeto do implantador contém o cluster do GKE. A configuração do Gerenciamento de Identidade e Acesso deste projeto deve refletir isso.

  3. Defina variáveis de ambiente para armazenar o nome e o número do projeto:

    DEPLOYER_PROJECT_ID=PROJECT_ID
    

    em que PROJECT_ID é o nome do projeto no Google Cloud.

    DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
        --format="value(projectNumber)")
    
  4. Ative as APIs de autorização binária e do GKE:

    gcloud --project=${DEPLOYER_PROJECT_ID} \
        services enable \
        container.googleapis.com \
        binaryauthorization.googleapis.com
    
  5. Consiga o nome da conta de serviço do projeto do implantador:

    DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
    

    Use o nome da conta de serviço em uma etapa posterior ao configurar permissões na nota do Container Analysis associada ao atestador.

Configurar o projeto do atestador

Um projeto de atestador armazena os atestadores que podem verificar se uma imagem está pronta para implantação. Muitas vezes, você tem um único projeto de atestador que atua como um repositório centralizado para informações sobre partes confiáveis no processo de autorização. Isso permite que você gerencie de maneira centralizada as chaves de segurança necessárias para verificar a identidade dos atestadores e restringir o acesso apenas às partes que os administram.

Para configurar o projeto de atestador:

  1. Crie o projeto e ative o faturamento no Console do Google Cloud, se ainda não tiver feito isso.

  2. Nota do gerenciamento de identidade e acesso: como este projeto contém seus atestadores, somente a equipe de segurança pode ter acesso de gravação.

  3. Defina variáveis de ambiente para armazenar o nome e o número do projeto:

    ATTESTOR_PROJECT_ID=PROJECT_ID
    

    em que PROJECT_ID é o nome do projeto no Google Cloud.

    ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
        --format="value(projectNumber)")
    
  4. Ative as APIs do Container Analysis e de autorização binária:

    gcloud services --project=${ATTESTOR_PROJECT_ID} \
        enable containeranalysis.googleapis.com \
        binaryauthorization.googleapis.com
    
  5. Consiga o nome da conta de serviço do projeto do atestador:

    ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
    

    Use o nome da conta de serviço em uma etapa posterior ao configurar permissões na nota do Container Analysis associada ao atestador.

Configurar o projeto de atestados

Um projeto de atestado é aquele que armazena atestados que os atestadores fazem quando verificam uma imagem. Um projeto de atestado separado permite que você organize e inspecione instruções sobre prontidão de software com mais facilidade.

  1. Crie o projeto e ative o faturamento no Console do Google Cloud, se ainda não tiver feito isso.

  2. Nota do gerenciamento de identidade e acesso: todos os papéis envolvidos na autorização binária precisam ter acesso de leitura às observações e ocorrências do Container Analysis neste projeto, mas apenas os gerenciadores de atestado precisam ter acesso de gravação.

  3. Defina uma variável de ambiente para armazenar o nome do projeto:

    ATTESTATION_PROJECT_ID=PROJECT_ID
    

    em que PROJECT_ID é o nome do projeto no Google Cloud.

  4. Ative as APIs do Container Analysis e de autorização binária:

    gcloud services --project=${ATTESTATION_PROJECT_ID} \
        enable containeranalysis.googleapis.com \
        binaryauthorization.googleapis.com
    

Crie um cluster

Agora você pode criar um cluster do GKE no projeto do implantador. Esse é o cluster em que você quer que as imagens de contêiner implantadas sejam geradas. Ao criar o cluster, você passa a sinalização --enable-binauthz para o comando gcloud beta container clusters create.

Para criar o cluster:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    beta 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.

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 local kubeconfig:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Crie um atestador

Um atestador é uma parte responsável por verificar se um processo necessário foi concluído antes que uma imagem de contêiner possa ser implantada. Essa parte pode ser um usuário humano ou, mais frequentemente, um processo de máquina como um sistema de criação e teste ou seus pipelines de integração contínua (CI) e de implantação (CD). Você cria atestadores no seu projeto de atestador.

A criação de um atestador exige que você:

  • Crie uma nota no Container Analysis para armazenar metadados confiáveis usados no processo de autorização
  • Crie o próprio atestador no projeto do atestador e associe a nota que você criou
  • Adicione uma vinculação de papel do IAM para a conta de serviço do projeto do implantador ao atestador
  • Defina permissões na nota do Container Analysis

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, é possível ter qualquer número de atestadores, cada um representando uma parte que participa do processo de autorização da imagem.

Crie a nota do Container Analysis

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

    ATTESTOR_NAME=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/${ATTESTOR_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/${ATTESTOR_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/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
    

Crie o atestador

Agora, você pode criar o atestador:

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

    gcloud --project=${ATTESTOR_PROJECT_ID} \
        beta container binauthz attestors create ${ATTESTOR_NAME} \
        --attestation-authority-note=${NOTE_ID} \
        --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}
    
  2. Verifique se ele foi criado:

    gcloud --project=${ATTESTOR_PROJECT_ID} \
        beta container binauthz attestors list
    

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

Adicione uma vinculação de papel do IAM para o projeto do implantador

Você precisa adicionar uma vinculação de papel do IAM para o projeto do implantador ao atestador. Isso é usado pela autorização binária quando avalia uma política para determinar se o projeto tem permissões para acessar os atestados associados.

Para adicionar a vinculação de papel do IAM:

gcloud --project ${ATTESTOR_PROJECT_ID} \
    beta container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Defina permissões na nota do Container Analysis

Também é preciso definir permissões na nota do Container Analysis que você criou para que ela seja acessível ao projeto do implantador e ao do atestador. Para fazer isso, atualize a política do IAM da nota para atribuir acesso de Leitor às contas de serviço do projeto.

  1. Gere um arquivo JSON que contenha as informações necessárias para definir a política do IAM na sua nota.

    cat > /tmp/iam_request.json << EOM
    {
      'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
      'policy': {
        'bindings': [
          {
            'role': 'roles/containeranalysis.notes.occurrences.viewer',
            'members': [
              'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}'
            ]
          }
        ]
      }
    }
    EOM
    
  2. Adicione a conta de serviço e os papéis de acesso solicitados à política do IAM para a nota que você criou:

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

Configurar chaves PKIX

A autorização binária usa chaves criptográficas para verificar com segurança a identidade dos atestadores. Isso garante que somente as partes verificadas possam participar da autorização de uma imagem de contêiner. O par de chaves consiste em uma chave privada, que o atestador usa para assinar atestados digitalmente, e uma chave pública, que você adiciona ao atestador conforme armazenado pelo serviço de autorização binária.

Neste tutorial, você usa o Algoritmo de assinatura digital de curva elíptica (ECDSA, na sigla em inglês) recomendado para criar o par de chaves. Também é possível usar chaves RSA ou PGP para assinatura. Consulte Principais finalidades e algoritmos para mais informações sobre algoritmos de assinatura.

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

Gerar um par de chaves

Um par de chaves PKIX consiste em uma chave privada, que o signatário usa para assinar atestados digitalmente e uma chave pública que você adiciona ao atestador. No momento da implantação, a autorização binária usa essa chave pública para verificar o atestado assinado pela chave privada.

  1. Gerar a chave privada:

    Para gerar um novo par de chaves PKIX assimétricas locais e armazená-lo em um arquivo:

    PKIX (chave local)

    1. Gerar a chave privada:

      PRIVATE_KEY_FILE é o nome do arquivo que contém a chave privada usada para assinar o payload do atestado.

      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 e armazene-a em um arquivo:

      PUBLIC_KEY_FILE é o nome do arquivo que contém a chave pública que será armazenada no atestador.

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

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

      gcloud --project="${ATTESTOR_PROJECT_ID}" \
      beta container binauthz attestors public-keys add \
      --attestor="${ATTESTOR_NAME}" \
      --pkix-public-key-file=${PUBLIC_KEY_FILE} \
      --pkix-public-key-algorithm=ecdsa-p256-sha256
      

    PKIX (Cloud KMS)

    Nesta etapa, mostramos como executar um atestado usando chaves geradas e armazenadas no Cloud Key Management Service.

    1. Configure variáveis de ambiente para armazenar informações sobre o par de chaves como gerenciado pelo Cloud KMS:

      Se você já tiver um par de chaves, poderá definir essas variáveis de ambiente e pular a próxima etapa.

      KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
      KMS_KEY_LOCATION=KMS_KEY_LOCATION
      KMS_KEYRING_NAME=KMS_KEYRING_NAME
      KMS_KEY_NAME=KMS_KEY_NAME
      KMS_KEY_VERSION=KMS_KEY_VERSION
      

      em que:

      • KMS_KEY_PROJECT_ID é o ID do projeto em que as chaves são armazenadas;
      • KMS_KEY_LOCATION é o local da chave;
      • KMS_KEYRING_NAME é o nome do keyring;
      • KMS_KEY_NAME é o nome da chave;
      • KMS_KEY_VERSION é a versão da chave.
    2. [Opcional] Configurar uma chave KMS:

      1. Crie uma chave KMS cuja chave pública possa ser armazenada em um atestador. Esta etapa também configura as variáveis de ambiente que você usa abaixo.

        Para criar uma chave e configurar as variáveis de ambiente:

        KMS_KEY_PROJECT_ID=${PROJECT_ID}
        KMS_KEYRING_NAME=my-binauthz-keyring
        KMS_KEY_NAME=my-binauthz-kms-key-name
        KMS_KEY_LOCATION=global
        KMS_KEY_PURPOSE=asymmetric-signing
        KMS_KEY_ALGORITHM=ec-sign-p256-sha256
        KMS_PROTECTION_LEVEL=software
        KMS_KEY_VERSION=1
        
      2. Crie um keyring do KMS:

        gcloud kms keyrings create ${KMS_KEYRING_NAME} \
          --location ${KMS_KEY_LOCATION} \
          --project ${KMS_KEY_PROJECT_ID}
        
      3. Crie a chave:

        gcloud kms keys create ${KMS_KEY_NAME} \
          --location ${KMS_KEY_LOCATION} \
          --keyring ${KMS_KEYRING_NAME}  \
          --purpose ${KMS_KEY_PURPOSE} \
          --default-algorithm ${KMS_KEY_ALGORITHM} \
          --protection-level ${KMS_PROTECTION_LEVEL} \
          --project ${KMS_KEY_PROJECT_ID}
        

        Para mais informações sobre como criar chaves do KMS, consulte Criar uma chave assimétrica.

    3. Adicione a chave pública ao atestador:

      gcloud --project="${ATTESTOR_PROJECT_ID}" \
          alpha container binauthz attestors public-keys add \
          --attestor="${ATTESTOR_NAME}" \
          --keyversion-project="${KMS_KEY_PROJECT_ID}" \
          --keyversion-location="${KMS_KEY_LOCATION}" \
          --keyversion-keyring="${KMS_KEYRING_NAME}" \
          --keyversion-key="${KMS_KEY_NAME}" \
          --keyversion="${KMS_KEY_VERSION}"
      

Configurar a política

Agora, você pode configurar sua política no projeto do implantador. 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:

  1. Crie um novo arquivo de política que permita as imagens do sistema mantidas pelo Google, defina o evaluationMode como REQUIRE_ATTESTATION e adicione 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/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
        name: projects/${DEPLOYER_PROJECT_ID}/policy
    EOM
    
  2. Importe o arquivo YAML da política para a autorização binária:

    gcloud --project=${DEPLOYER_PROJECT_ID} \
        beta 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 um aplicativo de amostra de Hello, World!.

Para tentar 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 é uma declaração de um atestador de que um processo obrigatório no pipeline foi concluído e que a imagem do contêiner em questão está autorizada para implantação. O próprio atestado é um registro assinado digitalmente que contém o caminho completo para uma versão da imagem conforme armazenado no registro de imagem do contêiner, bem como a identidade do atestador.

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

Para criar um atestado:

  1. Defina variáveis que armazenem 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 --project=${ATTESTATION_PROJECT_ID} \
        beta container binauthz create-signature-payload \
        --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json
    

    O arquivo JSON de 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. Se estiver usando arquivos PKIX locais, assine o payload com sua chave privada PKIX local 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 arquivo JSON do payload que você criou acima.

  4. Ou, se você estiver usando o Cloud KMS, assine o payload com o serviço do Cloud KMS:

      gcloud kms asymmetric-sign \
            --location=${KMS_KEY_LOCATION} \
            --keyring=${KMS_KEYRING_NAME} \
            --key=${KMS_KEY_NAME} \
            --version=${KMS_KEY_VERSION} \
            --digest-algorithm=sha256 \
            --input-file=/tmp/generated_payload.json \
            --signature-file=/tmp/ec_signature \
            --project ${KMS_KEY_PROJECT_ID}
    
  5. Receba o ID da chave pública do atestador

    É possível ver seu ID de chave pública a qualquer momento usando o comando: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

    Para salvar o ID da chave pública em uma variável de ambiente, digite este comando:

    PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
    --format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
    
  6. Crie um URL para a imagem a ser atestada:

    IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
    
  7. Crie o atestado:

    gcloud container binauthz attestations create \
        --project="${ATTESTATION_PROJECT_ID}" \
        --artifact-url="${IMAGE_TO_ATTEST}" \
        --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
        --signature-file=/tmp/ec_signature \
        --public-key-id="${PUBLIC_KEY_ID}"
    

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

    gcloud alpha container binauthz attestations create \
        --project="${ATTESTATION_PROJECT_ID}" \
        --artifact-url="${IMAGE_TO_ATTEST}" \
        --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
        --signature-file=/tmp/ec_signature \
        --public-key-id="${PUBLIC_KEY_ID}" \
        --validate
    
  8. Verifique se o atestado foi criado:

    gcloud --project=${ATTESTATION_PROJECT_ID} \
        beta container binauthz attestations list \
        --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_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:

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

Agora que você implantou com sucesso a imagem do contêiner e verificou se a configuração está funcionando, exclua o cluster criado no GKE:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster