Implementa la autorización binaria mediante Cloud Build y GKE


En este instructivo, se muestra cómo ajustar, configurar y usar la autorización binaria para Google Kubernetes Engine (GKE). La autorización binaria es un proceso que consiste en crear certificaciones en imágenes de contenedor con el fin de verificar que se cumplan ciertos criterios antes de implementar las imágenes en GKE

Por ejemplo, la autorización binaria puede verificar que una app superó las pruebas de unidades o que se compiló mediante un conjunto específico de sistemas. Para obtener más información, consulta Descripción general de Software Delivery Shield.

Este instructivo está dirigido a profesionales que desean comprender mejor el análisis de vulnerabilidades de contenedores y la autorización binaria, además de su implementación y aplicación en una canalización de IC/IC.

En este instructivo, se da por sentado que tienes un conocimiento básico sobre los siguientes temas y tecnologías:

  • La integración y la implementación continuas
  • El análisis de vulnerabilidades y riesgos comunes (CVE)
  • GKE
  • Artifact Registry
  • Cloud Build
  • Cloud Key Management Service (Cloud KMS)

Objetivos

  • Implementar clústeres de GKE para la etapa de pruebas y la producción
  • Crear varios certificadores y certificaciones
  • Implementar una canalización de IC/EC con Cloud Build
  • Probar la canalización de la implementación
  • Desarrollar un proceso de emergencia

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

  1. Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
  2. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

    Ir al selector de proyectos

  3. Comprueba que la facturación esté habilitada en tu proyecto.

    Descubre cómo puedes habilitar la facturación

  4. Habilita las API de Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.

    Habilita las API

  5. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

    Ir al selector de proyectos

  6. Comprueba que la facturación esté habilitada en tu proyecto.

    Descubre cómo puedes habilitar la facturación

  7. Habilita las API de Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.

    Habilita las API

  8. En la consola de Google Cloud, activa Cloud Shell.

    Activar Cloud Shell

    En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI ya instalada y con valores ya establecidos para el proyecto actual. La sesión puede tardar unos segundos en inicializarse.

  9. Todos los comandos de este instructivo se ejecutan en Cloud Shell.

Arquitectura de la canalización de IC/EC

Un aspecto importante del ciclo de vida del desarrollo de software (SDLC) es garantizar y exigir que las implementaciones de apps sigan los procesos aprobados de la organización. Un método para establecer estas verificaciones y equilibrios es usar la autorización binaria en GKE. En primer lugar, la autorización binaria adjunta notas a las imágenes de contenedor. Luego, GKE verifica que las notas obligatorias estén presentes para que puedas implementar la app.

Estas notas, o certificaciones, realizan declaraciones sobre la imagen. Las certificaciones se pueden configurar por completo; los siguientes son algunos ejemplos comunes:

  • La app aprobó las pruebas de unidades.
  • El equipo de control de calidad (QA) verificó la app.
  • La app se analizó en busca de vulnerabilidades y no se encontró ninguna.

En el siguiente diagrama, se muestra un SDLC en el que se aplica una sola certificación una vez que finaliza el análisis de vulnerabilidades, sin vulnerabilidades conocidas.

Arquitectura de SDLC con una sola certificación aplicada

En este instructivo, crearás una canalización de CI/CD mediante Cloud Source Repositories, Cloud Build, Artifact Registry y GKE. En el siguiente diagrama, se ilustra la canalización de CI/CD.

Arquitectura de canalización de IC/EC con tres productos de Google Cloud

Esta canalización de IC/EC consta de los siguientes pasos:

  1. Compila una imagen de contenedor con el código fuente de la app.

  2. Envía la imagen de contenedor a Artifact Registry.

  3. Artifact Analysis analiza la imagen de contenedor en busca de vulnerabilidades de seguridad conocidas o CVE.

Si la imagen no contiene CVE con una puntuación de gravedad mayor que cinco, se certifica que no tiene CVE críticas y se implementa de forma automática en etapa de pruebas. Una puntuación superior a cinco indica una vulnerabilidad de rango medio a crítico y, por lo tanto, no se certifica ni se implementa.

Un equipo de control de calidad inspecciona la app en el clúster de etapa de pruebas. Si cumple con los requisitos, se aplica una certificación manual que indica que la imagen del contenedor es de calidad suficiente para la implementación en producción. Los manifiestos de producción se actualizan, y la app se implementa en el clúster de GKE de producción.

Los clústeres de GKE están configurados para examinar las imágenes de contenedor en busca de certificaciones y rechazar las implementaciones que no cuenten con las certificaciones necesarias. El clúster de GKE de etapa de pruebas solo requiere la certificación de análisis de vulnerabilidades, pero el clúster de GKE de producción requiere un análisis de vulnerabilidades y una certificación de control de calidad.

En este instructivo, debes ingresar fallas en la canalización de CI/CD para probar y verificar esta aplicación. Por último, debes implementar un procedimiento de emergencia para omitir estas verificaciones de implementación en GKE en caso de emergencia.

Configura tu entorno

En este instructivo, se usan las siguientes variables de entorno. Puedes cambiar estos valores para que coincidan con tus requisitos, pero en todos los pasos del instructivo, se supone que estas variables de entorno existen y contienen valores válidos.

  1. En Cloud Shell, configura el proyecto de Google Cloud en el que implementarás y administrarás todos los recursos que se usan en este instructivo:

    export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
    gcloud config set project ${PROJECT_ID}
    
  2. Configura la región en la que implementarás estos recursos:

    export REGION="us-central1"
    

    El clúster de GKE y las claves de Cloud KMS residen en esta región. En este instructivo, la región es us-central1. Para obtener más información acerca de las regiones, consulta Geografía y regiones.

  3. Configura el número del proyecto de Cloud Build:

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
      --format='value(projectNumber)')"
    
  4. Configura el correo electrónico de la cuenta de servicio de Cloud Build:

    export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
    

Crea clústeres de GKE

Crea dos clústeres de GKE y otorga permisos de administración de identidades y accesos (IAM) para que Cloud Build implemente apps en GKE. Crear clústeres de GKE puede llevar unos minutos.

  1. En Cloud Shell, crea un clúster de GKE para la etapa de pruebas:

    gcloud container clusters create "staging-cluster" \
      --project "${PROJECT_ID}" \
      --machine-type "n1-standard-1" \
      --region "${REGION}" \
      --num-nodes "1" \
      --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
    
  2. Crea un clúster de GKE para la producción:

    gcloud container clusters create "prod-cluster" \
      --project "${PROJECT_ID}" \
      --machine-type "n1-standard-1" \
      --region "${REGION}" \
      --num-nodes "1" \
      --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
    
  3. Otorga a la cuenta de servicio de Cloud Build permiso para implementar en GKE:

    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role "roles/container.developer"
    

Crea claves de firma

Crea dos claves asimétricas de Cloud KMS para firmar certificaciones.

  1. En Cloud Shell, crea un llavero de claves de Cloud KMS con el nombre binauthz:

    gcloud kms keyrings create "binauthz" \
      --project "${PROJECT_ID}" \
      --location "${REGION}"
    
  2. Crea una clave asimétrica de Cloud KMS con el nombre vulnz-signer, que se usará para firmar y verificar certificaciones de análisis de vulnerabilidades:

    gcloud kms keys create "vulnz-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --purpose "asymmetric-signing" \
      --default-algorithm "rsa-sign-pkcs1-4096-sha512"
    
  3. Crea una clave asimétrica de Cloud KMS con el nombre qa-signer para firmar y verificar las certificaciones del control de calidad:

    gcloud kms keys create "qa-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --purpose "asymmetric-signing" \
      --default-algorithm "rsa-sign-pkcs1-4096-sha512"
    

Configura certificaciones

Crea las notas que se adjuntan a las imágenes de contenedor y otorga permisos a la cuenta de servicio de Cloud Build para ver y adjuntar notas y crear los certificadores mediante las claves mencionadas en los pasos anteriores.

Crea la certificación del análisis de vulnerabilidades

  1. En Cloud Shell, crea una nota de Artifact Analysis llamada vulnz-note:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \
      --request "POST" \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "name": "projects/${PROJECT_ID}/notes/vulnz-note",
          "attestation": {
            "hint": {
              "human_readable_name": "Vulnerability scan note"
            }
          }
        }
    EOF
    
  2. Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver y adjuntar la nota vulnz-note a las imágenes de contenedor:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \
      --request POST \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "resource": "projects/${PROJECT_ID}/notes/vulnz-note",
          "policy": {
            "bindings": [
              {
                "role": "roles/containeranalysis.notes.occurrences.viewer",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              },
              {
                "role": "roles/containeranalysis.notes.attacher",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              }
            ]
          }
        }
    EOF
    
  3. Crea el certificador de análisis de vulnerabilidades:

    gcloud container binauthz attestors create "vulnz-attestor" \
      --project "${PROJECT_ID}" \
      --attestation-authority-note-project "${PROJECT_ID}" \
      --attestation-authority-note "vulnz-note" \
      --description "Vulnerability scan attestor"
    
  4. Agrega la clave pública de la clave de firma del certificador:

    gcloud beta container binauthz attestors public-keys add \
      --project "${PROJECT_ID}" \
      --attestor "vulnz-attestor" \
      --keyversion "1" \
      --keyversion-key "vulnz-signer" \
      --keyversion-keyring "binauthz" \
      --keyversion-location "${REGION}" \
      --keyversion-project "${PROJECT_ID}"
    
  5. Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver las certificaciones que realizó vulnz-attestor:

    gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \
      --project "${PROJECT_ID}" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role "roles/binaryauthorization.attestorsViewer"
    
  6. Otorga permiso a la cuenta de servicio de Cloud Build para que pueda firmar objetos mediante la clave vulnz-signer:

    gcloud kms keys add-iam-policy-binding "vulnz-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role 'roles/cloudkms.signerVerifier'
    

Crea la certificación de QA

  1. En Cloud Shell, crea una nota de Artifact Analysis llamada qa-note:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \
      --request "POST" \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "name": "projects/${PROJECT_ID}/notes/qa-note",
          "attestation": {
            "hint": {
              "human_readable_name": "QA note"
            }
          }
        }
    EOF
    
  2. Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver y adjuntar la nota qa-note a las imágenes de contenedor:

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \
      --request POST \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "resource": "projects/${PROJECT_ID}/notes/qa-note",
          "policy": {
            "bindings": [
              {
                "role": "roles/containeranalysis.notes.occurrences.viewer",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              },
              {
                "role": "roles/containeranalysis.notes.attacher",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              }
            ]
          }
        }
    EOF
    
  3. Crea el certificador de QA:

    gcloud container binauthz attestors create "qa-attestor" \
      --project "${PROJECT_ID}" \
      --attestation-authority-note-project "${PROJECT_ID}" \
      --attestation-authority-note "qa-note" \
      --description "QA attestor"
    
  4. Agrega la clave pública de la clave de firma del certificador:

    gcloud beta container binauthz attestors public-keys add \
      --project "${PROJECT_ID}" \
      --attestor "qa-attestor" \
      --keyversion "1" \
      --keyversion-key "qa-signer" \
      --keyversion-keyring "binauthz" \
      --keyversion-location "${REGION}" \
      --keyversion-project "${PROJECT_ID}"
    
  5. Otorga permiso a la cuenta de servicio de Cloud Build para que pueda ver las certificaciones que realizó qa-attestor:

    gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \
      --project "${PROJECT_ID}" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role "roles/binaryauthorization.attestorsViewer"
    
  6. Otorga al equipo de control de calidad permiso para firmar certificaciones:

    gcloud kms keys add-iam-policy-binding "qa-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --member "group:qa-team@example.com" \
      --role 'roles/cloudkms.signerVerifier'
    

Configura la política de autorización binaria

Aunque creaste los clústeres de GKE con --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE, debes autorizar una política que indique a GKE qué certificaciones deben ejecutar los objetos binarios en el clúster. Las políticas de autorización binaria existen a nivel de proyecto, pero tienen la configuración del nivel de clúster.

La política que se muestra a continuación modifica la política predeterminada de las siguientes maneras:

  • Cambia el evaluationMode predeterminado a ALWAYS_DENY. Solo las imágenes exentas o las que cuentan con las certificaciones requeridas pueden ejecutarse en el clúster.

  • Habilita globalPolicyEvaluationMode, que cambia la lista de anunciantes permitidos predeterminada para que solo incluya las imágenes del sistema que proporciona Google.

  • Define las siguientes reglas de admisión de clústeres:

    • staging-cluster requiere certificaciones de vulnz-attestor.

    • prod-cluster requiere certificaciones de vulnz-attestor y qa-attestor.

Para obtener más información sobre las políticas de autorización binaria, consulta Referencia de la política de YAML.

  1. En Cloud Shell, crea un archivo YAML que describa la política de autorización binaria del proyecto de Google Cloud:

    cat > ./binauthz-policy.yaml <<EOF
    admissionWhitelistPatterns:
    - namePattern: docker.io/istio/*
    defaultAdmissionRule:
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      evaluationMode: ALWAYS_DENY
    globalPolicyEvaluationMode: ENABLE
    clusterAdmissionRules:
      # Staging cluster
      ${REGION}.staging-cluster:
        evaluationMode: REQUIRE_ATTESTATION
        enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
        requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/vulnz-attestor
    
      # Production cluster
      ${REGION}.prod-cluster:
        evaluationMode: REQUIRE_ATTESTATION
        enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
        requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/vulnz-attestor
        - projects/${PROJECT_ID}/attestors/qa-attestor
    EOF
    
  2. Sube la política nueva al proyecto de Google Cloud:

    gcloud container binauthz policy import ./binauthz-policy.yaml \
      --project "${PROJECT_ID}"
    

Crea el verificador del análisis de vulnerabilidades y habilita la API

Crea una imagen de contenedor que se use como paso de compilación en Cloud Build. Este contenedor compara las puntuaciones de gravedad de las vulnerabilidades detectadas en función del límite configurado. Si la puntuación está dentro del límite, Cloud Build crea una certificación en el contenedor. Si la puntuación se encuentra fuera del límite, la compilación falla, y no se crea ninguna certificación.

  1. En Cloud Shell, crea un repositorio nuevo de Artifact Registry para almacenar la imagen del certificador:

    gcloud artifacts repositories create cloudbuild-helpers \
      --repository-format=DOCKER --location=${REGION}
    
  2. Clona las herramientas de autorización binaria y la fuente de la aplicación de muestra:

    git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
    
  3. Compila y envía el contenedor del certificador del análisis de vulnerabilidades llamado attestor a cloudbuild-helpers Artifact Registry:

    gcloud builds submit \
      --project "${PROJECT_ID}" \
      --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \
      ~/binauthz-tools
    

Configura la canalización de Cloud Build

Crea un repositorio de Cloud Source Repositories y un activador de Cloud Build para la app de muestra y los manifiestos de Kubernetes.

Crea los repositorios de Cloud Source Repositories y Artifact Registry de hello-app

  1. En Cloud Shell, crea un repositorio de Cloud Source Repositories para la app de muestra:

    gcloud source repos create hello-app \
      --project "${PROJECT_ID}"
    
  2. Clona el repositorio en el entorno local:

    gcloud source repos clone hello-app ~/hello-app \
      --project "${PROJECT_ID}"
    
  3. Copia el código de muestra en el repositorio:

    cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
    
  4. Crea un repositorio nuevo de Artifact Registry para almacenar imágenes de aplicaciones:

    gcloud artifacts repositories create applications \
      --repository-format=DOCKER --location=${REGION}
    

Crea el activador de Cloud Build para hello-app

  1. En la consola de Google Cloud, ve a la página Activadores.

    Ir a Activadores

  2. Haz clic en Administrar repositorios.

  3. Para el repositorio hello-app, haz clic en ... y selecciona Agregar activador.

  4. En la ventana Configuración del activador, ingresa los siguientes detalles:

    • En el campo Nombre, ingresa build-vulnz-deploy.
    • En Evento, elige Enviar a una rama.
    • En el campo Repositorio, elige hello-app en el menú.
    • En el campo Rama, ingresa master.
    • En Configuración, selecciona Archivo de configuración de Cloud Build (yaml or json).
    • En Ubicación, selecciona Repositorio y, luego, ingresa el valor predeterminado /cloudbuild.yaml.
  5. Agrega los siguientes pares de Variables de sustitución:

    • _COMPUTE_REGION con el valor us-central1 (o la región que elegiste al principio)
    • _KMS_KEYRING con el valor binauthz
    • _KMS_LOCATION con el valor us-central1 (o la región que elegiste al principio)
    • _PROD_CLUSTER con el valor prod-cluster
    • _QA_ATTESTOR con el valor qa-attestor
    • _QA_KMS_KEY con el valor qa-signer
    • _QA_KMS_KEY_VERSION con el valor 1
    • _STAGING_CLUSTER con el valor staging-cluster
    • _VULNZ_ATTESTOR con el valor vulnz-attestor
    • _VULNZ_KMS_KEY con el valor vulnz-signer
    • _VULNZ_KMS_KEY_VERSION con el valor 1
  6. Haga clic en Crear.

Prueba la canalización de Cloud Build

Para probar la canalización de CI/CD, confirma y envía la app de muestra al repositorio de Cloud Source Repositories. Cloud Build detecta el cambio, compila la app y la implementa en staging-cluster. La canalización espera hasta 10 minutos para la verificación del control de calidad. Después de que el equipo de control de calidad verifica la implementación, el proceso continúa, los manifiestos de producción de Kubernetes se actualizan, y Cloud Build implementa la app en prod-cluster.

  1. En Cloud Shell, confirma y envía los archivos hello-app al repositorio de Cloud Source Repositories para activar una compilación:

    cd ~/hello-app
    
    git add .
    git commit -m "Initial commit"
    git push origin master
    
  2. En la consola de Google Cloud, ve a la página Historial (History).

    Ir a la página Historial

  3. Para ver el progreso de la compilación, haz clic en la ejecución más reciente de Cloud Build.

    Información de compilación

  4. Cuando finalice la implementación en staging-cluster, ve a la página Servicios.

    Ir a la página Servicios

  5. A fin de verificar que la aplicación esté funcionando, haz clic en el vínculo Extremos para la aplicación.

  6. Ve a la página Repositorios.

    Ir a la página Imágenes

  7. Haz clic en applications.

  8. Haz clic en hello-app.

  9. Haz clic en la imagen que validaste en la implementación de la etapa de pruebas.

    Nombre de la imagen validada

  10. Copia el valor Resumen de los detalles de la imagen. Esta información se necesita en el siguiente paso.

    Valor de resumen de la imagen

  11. Para aplicar la certificación manual del control de calidad, reemplaza ... por el valor que copiaste de los detalles de la imagen. La variable DIGEST debe tener el formato sha256:hash-value.

    El paso de compilación Await QA attestation también generará un comando que se puede copiar y pegar, que se muestra a continuación.

    DIGEST="sha256:..." # Replace with your value
    
    gcloud beta container binauthz attestations sign-and-create \
      --project "${PROJECT_ID}" \
      --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \
      --attestor "qa-attestor" \
      --attestor-project "${PROJECT_ID}" \
      --keyversion "1" \
      --keyversion-key "qa-signer" \
      --keyversion-location "${REGION}" \
      --keyversion-keyring "binauthz" \
      --keyversion-project "${PROJECT_ID}"
    
  12. Para verificar que la app se haya implementado, ve a la página Servicios.

    Ir a la página Servicios

  13. Para ver la aplicación, haz clic en el vínculo del extremo.

Implementa una imagen no certificada

Hasta ahora, la app de muestra no tenía ninguna vulnerabilidad. Actualiza la app para generar un mensaje diferente y cambiar la imagen base.

  1. En Cloud Shell, cambia la salida de Hello World a Binary Authorization y la imagen base de distroless a debian:

    cd ~/hello-app
    sed -i "s/Hello World/Binary Authorization/g" main.go
    sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile
    
  2. Confirma y envía los cambios:

    git add .
    git commit -m "Change message and base image"
    git push origin master
    
  3. Para supervisar el estado de la canalización de IC/EC, ve a la página Historial (History) en la consola de Google Cloud.

    Ir a la página Historial

    Esta compilación falla debido a que se detectan CVE en la imagen.

  4. Para examinar las CVE identificadas, ve a la página Images (Imágenes).

    Ir a la página Imágenes

  5. Haz clic en hello-app.

  6. Para revisar las CVE identificadas, haz clic en el resumen de vulnerabilidades de la imagen más reciente.

    Vínculo de resumen de vulnerabilidad para una imagen reciente.

  7. En Cloud Shell, intenta implementar la imagen nueva en producción sin la certificación del análisis de vulnerabilidades:

    export SHA_DIGEST="[SHA_DIGEST_VALUE]"
    
    cd ~/hello-app
    sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \
        sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \
        sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
    
    gcloud container clusters get-credentials \
        --project=${PROJECT_ID} \
        --region="${REGION}" prod-cluster
    
    kubectl apply -f kubernetes
    
  8. En la consola de Google Cloud, ve a la página Cargas de trabajo (Workloads).

    Ir a la página Cargas de trabajo

    Estado de error de la imagen

    La imagen no se pudo implementar porque no estaba firmada por vulnz-attestor ni qa-attestor.

Procedimiento de emergencia

A veces, debes permitir cambios que estén fuera del flujo de trabajo normal. Para permitir implementaciones de imágenes sin las certificaciones necesarias, la definición del pod se anota con una marca de política de emergencia. Habilitar esta marca hace que GKE verifique las certificaciones necesarias, pero permitirá que se implemente la imagen de contenedor y que se registren las infracciones.

Para obtener más información sobre cómo omitir las verificaciones de certificación, consulta Anula una política.

  1. En Cloud Shell, quita el comentario de la anotación de emergencia en el manifiesto de Kubernetes:

    sed -i "31s/^#//" kubernetes/deployment.yaml
    
  2. Usa kubectl para aplicar los cambios:

    kubectl apply -f kubernetes
    
  3. Para verificar que el cambio se haya implementado en prod-cluster, ve a la página Cargas de trabajo (Workloads) en la consola de Google Cloud.

    Ir a la página Cargas de trabajo

    Ahora no aparece el mensaje de error de implementación.

  4. Para verificar que la aplicación se implementó, ve a la página Servicios.

    Ir a la página Servicios

  5. Para ver la aplicación, haz clic en el vínculo del extremo.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra el proyecto

  1. En la consola de Google Cloud, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?