Configuración de varios proyectos

Puedes configurar la autorización binaria en tu entorno en una configuración de proyecto único o en una de varios proyectos. Una configuración de varios proyectos es adecuada para la mayoría de los usos reales de la autorización binaria, en la que varias personas con diferentes funciones pueden ser responsables de diferentes etapas del flujo de trabajo de la cadena de suministro de software. Por lo general, esto se conoce como separación de obligaciones. Por ejemplo, las funciones podrían ser las siguientes:

  • Implementador: Es un proceso individual o automatizado que implementa una aplicación en GKE de acuerdo con la política de la empresa. Aquí, la atención se centra en implementar el software. Por lo general, esto lo realiza un ingeniero de software o un ingeniero DevOps.

  • Administrador de operaciones de seguridad (SecOps): Es una persona que administra las claves autorizadas que usa la autorización binaria a fin de aplicar reglas de políticas que requieren certificación de acuerdo con la política de la empresa. Esta persona también puede crear la política, las reglas y los certificadores. En definitiva, estos certificadores verifican una certificación, lo que permite que un contenedor se implemente en GKE. Como tal, solo esta función tiene acceso de escritura al certificador.

  • Administrador de certificación: Es una persona que crea y administra certificaciones necesarias para los certificadores. Esta persona genera y administra las claves criptográficas. Luego, firman un descriptor de imagen de contenedor a fin de crear certificaciones. A continuación, administran las certificaciones.

En este instructivo, configurarás un proyecto diferente para cada una de las funciones anteriores. Configurarás un proyecto de implementador para una persona con la función de “implementador”, un proyecto de certificador para una persona con la función de administrador de seguridad y, por último, un proyecto de certificación para la persona en el administrador de certificación.

A continuación, deberás configurar tu política de autorización binaria con reglas que requieran certificaciones. Por último, probarás una implementación.

Cada proyecto se configurará con el control de acceso adecuado a través de la administración de identidades y accesos (IAM).

A fin de obtener una mayor seguridad, puedes usar Controles del servicio de VPC para proteger mejor los recursos que creas en este instructivo. Para obtener más información, consulta Protege con Controles del servicio de VPC.

Configura el proyecto de implementador

El primer paso es configurar el proyecto de implementador.

Un proyecto de implementador administra la política de autorización binaria que rige la implementación y los clústeres de Google Kubernetes Engine (GKE) en los que se implementan tus imágenes. Puedes tener más de un proyecto de implementador; esto depende del tamaño, la complejidad y otros requisitos de tu entorno.

Para configurar el proyecto de implementación, sigue estos pasos:

  1. Crea el proyecto y habilita la facturación en Google Cloud Console si aún no lo hiciste.

  2. Nota sobre la administración de identidades y accesos: El proyecto de implementador contiene el clúster de GKE. La configuración de la administración de identidades y accesos de este proyecto debe reflejar eso.

  3. Configura las variables de entorno para almacenar el nombre y el número del proyecto:

    DEPLOYER_PROJECT_ID=PROJECT_ID
    

    En el ejemplo anterior, PROJECT_ID es el nombre del proyecto en Google Cloud.

    DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
        --format="value(projectNumber)")
    
  4. Habilita la autorización binaria y las API de GKE:

    gcloud --project=${DEPLOYER_PROJECT_ID} \
        services enable \
        container.googleapis.com \
        binaryauthorization.googleapis.com
    
  5. Obtén el nombre de la cuenta de servicio del proyecto de implementador:

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

    Usarás el nombre de la cuenta de servicio en un paso posterior cuando configures los permisos en la nota de Container Analysis asociada con tu certificador.

Configura el proyecto del certificador

Un proyecto de certificador almacena los certificadores que pueden verificar que una imagen está lista para la implementación. A menudo, tienes un solo proyecto de certificador que actúa como un almacenamiento centralizado de información sobre las partes de confianza del proceso de autorización. Esto te permite administrar de forma centralizada las llaves de seguridad necesarias para verificar la identidad de los certificadores y restringir el acceso a solo las partes que los administran.

A fin de configurar el proyecto del certificador, sigue estos pasos:

  1. Crea el proyecto y habilita la facturación en Google Cloud Console si aún no lo hiciste.

  2. Nota sobre la administración de identidades y accesos: Debido a que este proyecto contiene tus certificadores, solo el personal de seguridad debería tener acceso de escritura.

  3. Configura las variables de entorno para almacenar el nombre y el número del proyecto:

    ATTESTOR_PROJECT_ID=PROJECT_ID
    

    En el ejemplo anterior, PROJECT_ID es el nombre del proyecto en Google Cloud.

    ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
        --format="value(projectNumber)")
    
  4. Habilita las API de Container Analysis y de autorización binaria:

    gcloud services --project=${ATTESTOR_PROJECT_ID} \
        enable containeranalysis.googleapis.com \
        binaryauthorization.googleapis.com
    
  5. Obtén el nombre de la cuenta de servicio del proyecto del certificador:

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

    Usarás el nombre de la cuenta de servicio en un paso posterior cuando configures los permisos en la nota de Container Analysis asociada con tu certificador.

Configura el proyecto de certificaciones

Un proyecto de certificación es el que almacena las certificaciones que realizan los certificadores cuando verifican una imagen. Un proyecto de certificación diferente te permite inspeccionar y organizar declaraciones sobre la preparación del software con mayor facilidad.

  1. Crea el proyecto y habilita la facturación en Google Cloud Console si aún no lo hiciste.

  2. Nota sobre la administración de identidades y accesos: Todas las funciones involucradas en la autorización binaria deben tener acceso de lectura a casos y notas de Container Analysis en este proyecto. Sin embargo, solo los administradores de la certificación deben tener acceso de escritura.

  3. Establece una variable de entorno para almacenar el nombre del proyecto:

    ATTESTATION_PROJECT_ID=PROJECT_ID
    

    En el ejemplo anterior, PROJECT_ID es el nombre del proyecto en Google Cloud.

  4. Habilita las API de Container Analysis y de autorización binaria:

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

Crea un clúster

Ahora puedes crear un clúster de GKE en el proyecto de implementador. Este es el clúster en el que se recomienda que se ejecuten las imágenes de contenedor que implementaste. Cuando creas el clúster, debes pasar la marca --enable-binauthz al comando gcloud beta container clusters create.

Para ello, sigue estos pasos:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    beta container clusters create \
    --enable-binauthz \
    --zone us-central1-a \
    test-cluster

Aquí, crearás un clúster llamado test-cluster en la zona de GKE us-central1-a.

También debes actualizar el archivo local kubeconfig de tu instalación de kubectl. Esto proporciona las credenciales y la información del extremo necesarias para acceder al clúster en GKE.

Para actualizar el archivo kubeconfig local, sigue estos pasos:

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

Crea un certificador

Un certificador es una parte responsable de certificar que se completó un proceso obligatorio antes de que se pueda implementar una imagen de contenedor. Esta parte puede ser un usuario humano o, casi siempre, un proceso de máquina, como un sistema de compilación y prueba, o tus canalizaciones de integración continua (CI) e implementación continua (CD). Debes crear certificadores en tu proyecto de certificador.

Para crear un certificador, debes hacer lo siguiente:

  • Crea una nota en Container Analysis a fin de almacenar los metadatos de confianza que se usan en el proceso de autorización.
  • Crea el certificador en el proyecto de certificador y asocia la nota que creaste.
  • Agrega una vinculación de función de IAM para la cuenta de servicio del proyecto de implementador al certificador
  • Establece permisos en la nota de Container Analysis

Para este instructivo, debes tener un certificador llamado test-attestor y una nota de Container Analysis llamada test-attestor-note. En una situación real, puedes tener cualquier cantidad de certificadores, cada uno representa a una parte que participa en el proceso de autorización de la imagen.

Crea la nota de Container Analysis

  1. Establece las variables que almacenan el nombre del certificador y la nota de Container Analysis:

    ATTESTOR_NAME=test-attestor
    NOTE_ID=test-attestor-note
    
  2. Crea un archivo JSON en /tmp/note_payload.json que describa la nota de 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. Envía una solicitud HTTP a la API de REST de Container Analysis para crear la nota:

    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. Verifica que se haya creado la nota:

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

Crea el certificador

Ahora, puedes crear el certificador:

  1. Crea el certificador en la autorización binaria:

    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. Verifica que se haya creado el certificador:

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

El certificador que creaste aún no se puede usar sin un par de claves PKIX asociado, que puedes crear, a continuación.

Agrega una vinculación de función de IAM para el proyecto de implementador

Debes agregar una vinculación de función de IAM para el proyecto de implementador al certificador. La autorización binaria usa esta vinculación cuando evalúa una política a fin de determinar si el proyecto tiene permisos para acceder a las certificaciones asociadas.

Para agregar la vinculación de función de IAM, sigue estos pasos:

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

Establece permisos en la nota de Container Analysis

También debes establecer permisos en la nota de Container Analysis que creaste a fin de que sea accesible para el proyecto de implementador y el de certificador. Para ello, actualiza la política de IAM de la nota a fin de asignar el acceso de visualizador a las cuentas de servicio del proyecto.

  1. Genera un archivo JSON que contenga la información necesaria para establecer la política de IAM en la 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. Agrega la cuenta de servicio y las funciones de acceso solicitadas a la política de IAM para la nota que creaste:

    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"
    

Configura claves de PKIX

La autorización binaria usa claves criptográficas para verificar de forma segura la identidad de los certificadores. Esto garantiza que solo las partes verificadas puedan participar en la autorización de una imagen de contenedor. El par de claves consta de una clave privada, que el certificador usa para firmar de forma digital las certificaciones, y una clave pública, que se agrega al certificador que almacenó el servicio de autorización binaria.

En este instructivo, usarás el Algoritmo de firma digital de curva elíptica (ECDSA) que se recomienda para crear el par de claves. También puedes usar las claves de RSA o PGP para firmar. Consulta Algoritmos y propósitos de clave para obtener más información sobre los algoritmos de firma.

Las claves asimétricas que Cloud Key Management Service (Cloud KMS) genera y almacena son compatibles con PKIX. Consulta Crea certificadores mediante la CLI para obtener más información sobre el uso de claves de PKIX y Cloud KMS.

Genera un par de claves

Un par de claves de PKIX consta de una clave privada, que el firmante usa para firmar de forma digital las certificaciones, y una clave pública, que agregas al certificador. En el momento de la implementación, la autorización binaria usa esta clave pública para verificar la certificación que firma la clave privada.

  1. Genera la clave privada:

    Sigue estos pasos a fin de generar un par nuevo y local de claves de PKIX asimétricas y almacenarlo en un archivo:

    PKIX (clave local)

    1. Genera la clave privada:

      PRIVATE_KEY_FILE es el nombre del archivo que contiene la clave privada que se usa para firmar la carga útil de la certificación.

      PRIVATE_KEY_FILE="/tmp/ec_private.pem"
      openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
      
    2. Extrae la clave pública de la clave privada y guárdala en un archivo:

      PUBLIC_KEY_FILE es el nombre del archivo que contiene la clave pública que se almacenará en el certificador.

      PUBLIC_KEY_FILE="/tmp/ec_public.pem"
      openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
      
      1. Agrega la clave pública local al certificador

      Ahora, agrega la clave pública que exportaste al certificador a fin de que la autorización binaria pueda usarla para la verificación de identidad:

      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)

    En este paso, se muestra cómo realizar una certificación mediante claves generadas y almacenadas en Cloud Key Management Service.

    1. Configura las variables de entorno para almacenar información sobre el par de claves administradas por Cloud KMS:

      Si ya tienes un par de claves, puedes configurar estas variables de entorno y omitir el siguiente paso.

      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
      

      En el ejemplo anterior, se ilustra lo siguiente:

      • KMS_KEY_PROJECT_ID es el ID del proyecto en el que se almacenan las claves.
      • KMS_KEY_LOCATION es la ubicación de la clave.
      • KMS_KEYRING_NAME es el nombre del llavero de claves.
      • KMS_KEY_NAME es el nombre de la clave.
      • KMS_KEY_VERSION es la versión de la clave.
    2. Configura una clave de KMS (opcional):

      1. Crea una clave de KMS cuya clave pública se pueda almacenar en un certificador. En este paso, también se configuran las variables de entorno que usarás a continuación.

        Sigue estos pasos para crear una clave y configurar las variables de entorno:

        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. Crea un llavero de claves de KMS.

        gcloud kms keyrings create ${KMS_KEYRING_NAME} \
          --location ${KMS_KEY_LOCATION} \
          --project ${KMS_KEY_PROJECT_ID}
        
      3. Crea la clave:

        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 obtener más información sobre cómo crear claves de KMS, consulta Crea una clave asimétrica.

    3. Agrega la clave pública al certificador:

      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}"
      

Configura la política

Ahora, puedes configurar la política en el proyecto de implementador. En este paso, exportarás el archivo YAML de la política a tu sistema local y modificarás la regla predeterminada para que necesite una certificación del certificador que definiste antes.

Para configurar la política, sigue estos pasos:

  1. Crea un archivo de política nuevo que permita imágenes del sistema mantenidas por Google, establece el evaluationMode en REQUIRE_ATTESTATION y agrega un nodo llamado requireAttestationsBy que hace referencia al certificador que creaste:

    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. Importa el archivo YAML de política a la autorización binaria:

    gcloud --project=${DEPLOYER_PROJECT_ID} \
        beta container binauthz policy import /tmp/policy.yaml
    

Para obtener más información sobre cómo configurar una política, consulta Configura una política mediante la CLI.

Prueba la política

Para probar la política que configuraste antes, intenta implementar una imagen de contenedor de muestra en el clúster. La política bloqueará la implementación porque no se realizó la certificación necesaria.

Para este instructivo, puedes usar la imagen de muestra que se ubica en la ruta gcr.io/google-samples/hello-app en Container Registry. Google creó esta imagen de contenedor pública que contiene una aplicación Hello World! de muestra.

Para intentar implementar la imagen, sigue estos pasos:

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

Ahora, verifica que la autorización binaria haya bloqueado la implementación:

kubectl get pods

El comando imprime el siguiente mensaje, que indica que la imagen no se implementó:

No resources found.

Puedes obtener más detalles sobre la implementación:

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

En el código anterior, se muestra que la política no permitió la implementación:

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

Asegúrate de borrar la implementación para poder continuar con el siguiente paso:

kubectl delete deployment hello-server

Crea una certificación

Una certificación es una declaración de un certificador que constata que se completó un proceso necesario en tu canalización y que la imagen de contenedor en cuestión está autorizada para la implementación. La certificación es un registro firmado de forma digital que contiene la ruta completa a una versión de la imagen almacenada en el registro de imágenes de contenedor, así como la identidad del certificador.

En este instructivo, tu certificación solo indica que autorizas la implementación de la imagen. Crearás la certificación en el proyecto de certificación.

Para crear una certificación, sigue estos pasos:

  1. Configura las variables que almacenen la ruta de registro y el resumen de la imagen:

    IMAGE_PATH="gcr.io/google-samples/hello-app"
    IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
    
  2. Genera la carga útil de la certificación:

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

    El archivo JSON de carga útil tiene el siguiente contenido:

    {
      "critical": {
        "identity": {
          "docker-reference": "gcr.io/google-samples/hello-app"
        },
        "image": {
          "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
    882eb722c3be4"
        },
        "type": "Google cloud binauthz container signature"
      }
    }
    
  3. Si usas archivos PKIX locales, firma la carga útil con tu clave privada de PKIX local y genera un archivo de firma:

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

    El archivo de firma es una versión con firma digital del archivo JSON de carga útil que creaste antes.

  4. Si usas Cloud KMS, firma la carga útil mediante el servicio de 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. Obtén el ID de la clave pública del certificador

    Puedes ver tu ID de clave pública en cualquier momento con el comando: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

    Para guardar tu ID de clave pública en una variable de entorno, ingresa el siguiente comando:

    PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
    --format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
    
  6. Crea una URL para certificar la imagen:

    IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
    
  7. Crea la certificación:

    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 crear y validar que el certificador provisto pueda verificar la certificación, ejecuta el siguiente comando:

    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. Verifica que se haya creado la certificación:

    gcloud --project=${ATTESTATION_PROJECT_ID} \
        beta container binauthz attestations list \
        --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_PROJECT_ID
    

Para obtener más información sobre cómo crear certificaciones, consulta Crea certificaciones.

Vuelve a probar la política

Prueba la política otra vez mediante la implementación de una imagen de contenedor de muestra en el clúster. Esta vez, debes implementar la imagen mediante el resumen en lugar de una etiqueta, como 1.0 o latest, ya que la autorización binaria usará el resumen y la ruta de la imagen para buscar certificaciones. Aquí, la autorización binaria permite implementar la imagen, ya que se realizó la certificación necesaria.

Para implementar la imagen, ejecuta el siguiente comando:

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

Para verificar que se implementó la imagen, sigue estos pasos:

kubectl get pods

El comando imprime un mensaje similar al siguiente, que indica que la implementación se realizó de forma correcta:

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

Ahora que implementaste de forma correcta la imagen de contenedor y verificaste que la configuración funciona, puedes borrar el clúster que creaste en GKE:

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