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 y casos de uso, consulta Ayuda a proteger las cadenas de suministro de software en Google Kubernetes Engine.

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
  • Container 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 instructivo, se usan 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 sean aptos para obtener una prueba gratuita.

Cuando finalices este instructivo, podrás borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta cómo hacer una limpieza.

Antes de comenzar

  1. Accede a tu Cuenta de Google.

    Si todavía no tienes una cuenta, regístrate para obtener una nueva.

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

    Ir a la página del 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, Container Registry, Container Analysis, Resource Manager, and Cloud Source Repositories.

    Habilita las API

  5. En Cloud Console, activa Cloud Shell.

    Activar Cloud Shell

    En la parte inferior de Cloud Console, 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 que tiene el SDK de Cloud preinstalado, incluida la herramienta de línea de comandos de gcloud, y valores ya establecidos para el proyecto actual. La inicialización de la sesión puede tomar unos minutos.

  6. 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, Container 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 Container Registry.

  3. Container 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 Cloud en el que implementarás y administrarás todos los recursos que se usan en este instructivo:

    export PROJECT_ID="${DEVSHELL_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" \
      --enable-binauthz
    
  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" \
      --enable-binauthz
    
  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 Container 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/v1beta1/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 verificar 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.attestorsVerifier"
    
  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 Container 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/v1beta1/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 verificar 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.attestorsVerifier"
    
  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 --enable-binauthz, 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 blanca 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 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 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, 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
    
  2. Compila y envía el contenedor del certificador del análisis de vulnerabilidades llamado cloudbuild-attestor a Container Registry:

    gcloud builds submit \
      --project "${PROJECT_ID}" \
      --tag "gcr.io/${PROJECT_ID}/cloudbuild-attestor" \
      ~/binauthz-tools
    
  3. Habilita la API de análisis de vulnerabilidades:

    gcloud services enable containerscanning.googleapis.com
    

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 para 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
    

Crea el activador de Cloud Build para hello-app

  1. En Cloud Console, ve a la página Activadores.

    Ir a Activadores

  2. Haz clic en Crear activador.

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

    • En el campo Repositorio, elige hello-app en el menú.
    • En el campo Nombre, ingresa build-vulnz-deploy.
    • En Tipo de activador, elige Rama.
    • En el campo Rama (regex), ingresa master.
    • En Configuración de compilación, selecciona Archivo de configuración de Cloud Build.
    • En la ubicación del archivo de configuración de Cloud Build, ingresa el valor predeterminado /cloudbuild.yaml.
  4. 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
  5. Haz clic en Crear activador.

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 Cloud Console, ve a la página Historial.

    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 Images (Imágenes).

    Ir a la página Imágenes

  7. Haz clic en hello-app.

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

    Nombre de la imagen validada

  9. En la página Detalles del resumen (Digest Details), copia el valor Resumen (Digest) de los detalles de la imagen. Esta información se necesita en el siguiente paso.

    Valor de resumen de la imagen

  10. 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 "gcr.io/${PROJECT_ID}/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}"
    
  11. Para verificar que la app se haya implementado, ve a la página Servicios.

    Ir a la página Servicios

  12. 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/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 CI/CD, ve a la página Historial en Cloud Console.

    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/GOOGLE_CLOUD_PROJECT/${DEVSHELL_PROJECT_ID}/g" \
        kubernetes/deployment.yaml.tpl | sed -e  \
        "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
    
    gcloud container clusters get-credentials \
        --project=${DEVSHELL_PROJECT_ID} \
        --zone=${COMPUTE_ZONE} prod-cluster
    
    kubectl apply -f kubernetes
    
  8. En Cloud Console, ve a la página Workloads (Cargas de trabajo).

    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 en Cloud Console.

    Ir a la página Cargas de trabajo

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

  4. Para verificar que la app se haya implementado, 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

Sigue estos pasos para evitar que se apliquen cargos a tu cuenta de Google Cloud Platform por los recursos que usaste en este instructivo:

Borra el proyecto

  1. En Cloud Console, ve a la página Administrar recursos.

    Ir a la página Administrar recursos

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

Próximos pasos