GSP1183

Descripción general

La Autorización Binaria es un control de seguridad en la fase de implementación que garantiza que solo se implementen imágenes de contenedor confiables en Google Kubernetes Engine (GKE) o Cloud Run. Con la Autorización Binaria, puedes exigir que autoridades de confianza firmen las imágenes durante el proceso de desarrollo y, luego, aplicar la validación de firma de manera forzosa en el momento de la implementación. Aplicar esta validación permite tener un control más estricto sobre tu entorno de contenedores y asegurarte de que solo las imágenes verificadas se integren en el proceso de compilación y lanzamiento.

En el siguiente diagrama, se muestran los componentes de una configuración de Autorización Binaria y Cloud Build:

Canalización de Cloud Build que crea una certificación de Autorización Binaria.

En esta canalización, sucede lo siguiente:

1. El código para compilar la imagen del contenedor se envía a un repositorio de código fuente, como Cloud Source Repositories.
2. Una herramienta de integración continua (CI), Cloud Build, compila y prueba el contenedor.
3. La compilación envía la imagen del contenedor a Container Registry o a otro registro que almacene tus imágenes compiladas.
4. Cloud Key Management Service, que proporciona administración de claves para el par de claves criptográficas, firma la imagen de contenedor. La firma resultante se almacena en una certificación recién creada.
5. En el momento de la implementación, el certificador verifica la certificación usando la clave pública del par de claves. La Autorización Binaria aplica la política a través de la solicitud de certificaciones firmadas para implementar la imagen de contenedor.

En este lab, aprenderás sobre las herramientas y técnicas para proteger los artefactos implementados. Este lab se enfoca en los artefactos (contenedores) después de que se crearon, pero antes de que se implementen en algún entorno específico.

Aprendizajes esperados

• Firma de imágenes
• Políticas de control de admisión
• Firma de imágenes analizadas
• Autorización de imágenes firmadas
• Bloqueo de imágenes sin firmar

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

En este lab práctico, se te proporcionarán credenciales temporales nuevas para acceder a Google Cloud y realizar las actividades en un entorno de nube real, no en uno de simulación o demostración.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)

Nota: Usa una ventana de navegador privada o de incógnito para ejecutar el lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. Haz clic en el botón Comenzar lab. Si debes pagar por el lab, se abrirá una ventana emergente para que selecciones tu forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:

   • El botón Abrir la consola de Google Cloud
   • El tiempo restante
   • Las credenciales temporales que debes usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordena las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Detalles del lab.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Detalles del lab.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses tus credenciales de cuenta de Google Cloud. Nota: Usar tu propia cuenta de Google Cloud para este lab podría generar cargos adicionales.

7. Haz clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para ver un menú con una lista de productos y servicios de Google Cloud, haz clic en el menú de navegación que se encuentra en la parte superior izquierda.

Activa Cloud Shell

Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu Project_ID, . El resultado contiene una línea que declara el Project_ID para esta sesión:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

Resultado:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

4. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Nota: Para obtener toda la documentación de gcloud, en Google Cloud, consulta la guía con la descripción general de gcloud CLI.

Configuración del entorno

En Cloud Shell, configura el ID y el número de tu proyecto. Guárdalos como variables PROJECT_ID y PROJECT_NUMBER.

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format='value(projectNumber)')

Habilita los servicios

Habilita todos los servicios necesarios con el siguiente comando:

gcloud services enable \ cloudkms.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

Tarea 1: Crea un repositorio de Artifact Registry

En este lab, usarás Artifact Registry para almacenar y analizar tus imágenes.

1. Crea el repositorio con el siguiente comando:

gcloud artifacts repositories create artifact-scanning-repo \ --repository-format=docker \ --location={{{ project_0.default_region | "REGION" }}} \ --description="Docker repository"

2. Configura Docker para que utilice tus credenciales de gcloud cuando accedas a Artifact Registry:

gcloud auth configure-docker {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev

3. Crea un directorio de trabajo y cambia a él:

mkdir vuln-scan && cd vuln-scan

4. Luego, define una imagen de muestra. Crea un archivo llamado Dockerfile con el siguiente contenido:

cat > ./Dockerfile << EOF FROM python:3.8-alpine # App WORKDIR /app COPY . ./ RUN pip3 install Flask==2.1.0 RUN pip3 install gunicorn==20.1.0 RUN pip3 install Werkzeug==2.2.2 CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app EOF

5. Crea un archivo llamado main.py con el siguiente contenido:

cat > ./main.py << EOF import os from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): name = os.environ.get("NAME", "Worlds") return "Hello {}!".format(name) if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080))) EOF

6. Usa Cloud Build para compilar y enviar automáticamente tu contenedor a Artifact Registry.

gcloud builds submit . -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

Haz clic en Revisar mi progreso para verificar el objetivo. Crear un repositorio de Artifact Registry

Tarea 2: Firma de imágenes

¿Qué es un certificador?

• Es la persona o proceso responsable de un vínculo en la cadena de confianza del sistema.
• Tiene una clave criptográfica y firma una imagen si pasa su proceso de aprobación.
• Mientras que el creador de políticas determina la política a un nivel alto y abstracto, el certificador es responsable de aplicar de forma concreta algún aspecto de la política.
• Puede ser una persona real, como un verificador de QA o un administrador, o un bot en un sistema de CI.
• La seguridad del sistema depende de su confiabilidad, por lo que es importante que sus claves privadas se mantengan seguras.

Cada uno de estos roles puede representar a una persona individual o a un equipo dentro de tu organización. En un entorno de producción, es probable que estos roles se administren con proyectos separados de Google Cloud y que el acceso a los recursos se comparta entre ellos de forma limitada con Cloud IAM.

Los certificadores de la Autorización Binaria se implementan sobre la API de Cloud Container Analysis, por lo que es importante describir cómo funciona antes de continuar. La API de Container Analysis se diseñó para permitirte asociar metadatos con imágenes de contenedores específicas.

Por ejemplo, se podría crear una nota para hacer un seguimiento de la vulnerabilidad Heartbleed. Luego, los proveedores de seguridad crearían luego escáneres para analizar las imágenes de contenedor en busca de la vulnerabilidad y generarían una ocurrencia asociada a cada contenedor comprometido.

Además de hacer un seguimiento de las vulnerabilidades, Container Analysis se diseñó para ser una API de metadatos genérica. La Autorización Binaria utiliza Container Analysis para asociar firmas con las imágenes de contenedor que está verificando. Una nota de Container Analysis se usa para representar a un solo certificador, se crean ocurrencias asociadas a cada contenedor que ese certificador haya aprobado.

La API de Autorización Binaria usa los conceptos de "certificadores" y "certificaciones", pero estos se implementan con las notas y las ocurrencias correspondientes en la API de Container Analysis.

Crea una nota de certificador

Una nota de certificador es básicamente un pequeño fragmento de datos que actúa como una etiqueta para el tipo de firma que se aplica. Por ejemplo, una nota podría indicar un análisis de vulnerabilidades, mientras que otra podría usarse para la aprobación de QA. Esta nota se consultará durante el proceso de firma.

1. Crea una nota:

cat > ./vulnz_note.json << EOM { "attestation": { "hint": { "human_readable_name": "Container Vulnerabilities attestation authority" } } } EOM

2. Almacena la nota:

NOTE_ID=vulnz_note curl -vvv -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./vulnz_note.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

3. Verifica la nota:

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

Tu nota ahora está guardada en la API de Container Analysis.

4. Crea un certificador

Los certificadores se usan para realizar el proceso de firma de la imagen y adjuntarán una ocurrencia de la nota a la imagen para verificarla más tarde. Para usar tu certificador, también debes registrar la nota con Autorización Binaria:

5. Crea el certificador:

ATTESTOR_ID=vulnz-attestor gcloud container binauthz attestors create $ATTESTOR_ID \ --attestation-authority-note=$NOTE_ID \ --attestation-authority-note-project=${PROJECT_ID}

6. Verifica el certificador:

gcloud container binauthz attestors list

La última línea indica NUM_PUBLIC_KEYS: 0, ya que proporcionarás las claves en un paso posterior.

Cloud Build crea automáticamente el certificador built-by-cloud-build en tu proyecto cuando ejecutas una compilación que genera imágenes. Por lo tanto, el comando anterior devuelve dos certificadores: vulnz-attestor y built-by-cloud-build. Una vez que las imágenes se compilan con éxito, Cloud Build firma y crea certificaciones de forma automática para ellas.

7. La cuenta de servicio de Autorización Binaria necesitará derechos para ver las notas de certificación. Proporciona el acceso al rol de IAM con la siguiente llamada a la API:

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)") BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com" cat > ./iam_request.json << EOM { 'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${BINAUTHZ_SA_EMAIL}' ] } ] } } EOM

8. Usa el archivo para crear la política de IAM:

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

Haz clic en Revisar mi progreso para verificar el objetivo. Crear un certificador

Tarea 3: Agrega una clave de KMS

Antes de que puedas usar este certificador, tu autoridad debe crear un par de claves criptográficas que se usará para firmar las imágenes de contenedor. Esto se puede hacer a través de Google Cloud Key Management Service (KMS).

1. Primero, agrega algunas variables de entorno para describir la nueva clave:

KEY_LOCATION=global KEYRING=binauthz-keys KEY_NAME=codelab-key KEY_VERSION=1

2. Crea un llavero de claves para almacenar un conjunto de claves:

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

3. Crea un nuevo par de claves de firma asimétricas para el certificador:

gcloud kms keys create "${KEY_NAME}" \ --keyring="${KEYRING}" --location="${KEY_LOCATION}" \ --purpose asymmetric-signing \ --default-algorithm="ec-sign-p256-sha256"

Deberías ver tu clave en la página de KMS de la consola de Cloud.

4. Ahora, asocia la clave con tu certificador a través del comando binauthz de gcloud:

gcloud beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

5. Si vuelves a imprimir la lista de autoridades, debería aparecer una clave registrada:

gcloud container binauthz attestors list

Haz clic en Revisar mi progreso para verificar el objetivo. Agregar una clave de KMS

Tarea 4: Crea una certificación firmada

En este momento, las funciones que te permiten firmar imágenes ya están configuradas. Usa el certificador que creaste anteriormente para firmar la imagen de contenedor con la que has estado trabajando.

Una certificación debe incluir una firma criptográfica para indicar que el certificador verificó una imagen de contenedor en particular y que es seguro ejecutarla en tu clúster.

1. Para especificar qué imagen de contenedor vas a certificar, ejecuta el siguiente comando y determina su resumen:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \ --format='get(image_summary.digest)')

2. Ahora, puedes usar gcloud para crear tu certificación. El comando recibe los detalles de la clave que quieres usar para la firma y la imagen de contenedor específica que quieres aprobar:

gcloud beta container binauthz attestations sign-and-create \ --artifact-url="${CONTAINER_PATH}@${DIGEST}" \ --attestor="${ATTESTOR_ID}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

En términos de Container Analysis, esto creará una nueva ocurrencia y la adjuntará a la nota de tu certificador.

3. Ejecuta el siguiente comando para listar tus certificaciones y asegurarte de que todo funcionó como se esperaba:

gcloud container binauthz attestations list \ --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

Tarea 5: Políticas de control de admisión

La Autorización Binaria es una función de GKE y Cloud Run que permite validar reglas antes de que se ejecute una imagen de contenedor. La validación se realiza en cualquier solicitud para ejecutar una imagen, ya sea desde una canalización de CI/CD confiable o cuando un usuario intenta implementarla de forma manual. Esta capacidad te permite proteger tus entornos de ejecución de manera más eficaz que únicamente con las verificaciones de canalización de CI/CD.

Para comprender esta capacidad, modificarás la política predeterminada de GKE y aplicarás una regla de autorización estricta.

1. Crea un clúster de GKE con Autorización Binaria habilitada:

gcloud beta container clusters create binauthz \ --zone {{{ project_0.default_zone | "ZONE" }}} \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

2. Permite que Cloud Build implemente en este clúster:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/container.developer"

Política de permitir todo

Primero, verifica el estado de la política predeterminada y tu capacidad para implementar cualquier imagen.

1. Revisa la política existente:

gcloud container binauthz policy export

2. Ten en cuenta que la política de aplicación está configurada en ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Implementa la muestra para verificar que puedes implementar cualquier imagen:

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

4. Verifica que la implementación haya funcionado:

kubectl get pods

Verás el siguiente resultado:

5. Borra la implementación:

kubectl delete pod hello-server

Política de rechazar todo

Ahora, actualiza la política para no permitir ninguna imagen.

1. Exporta la política actual a un archivo editable:

gcloud container binauthz policy export > policy.yaml

2. En un editor de texto, abre el archivo policy.yaml' y cambia el evaluationMode de `ALWAYS_ALLOW a ALWAYS_DENY:

edit policy.yaml

Asegúrate de que el archivo YAML de política que editaste se vea de la siguiente manera:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

Esta política es relativamente sencilla. La línea globalPolicyEvaluationMode declara que esta política amplía la política global definida por Google. Esto permite que todos los contenedores oficiales de GKE se ejecuten de forma predeterminada. Además, la política declara una defaultAdmissionRule que indica que todos los demás pods serán rechazados. La regla de admisión incluye una línea enforcementMode, que indica que todos los pods que no cumplan con esta regla deben ser bloqueados para ejecutarse en el clúster.

Para obtener instrucciones sobre cómo crear políticas más complejas, consulta la documentación sobre Autorización Binaria.

3. En Cloud Shell, ejecuta el siguiente comando para aplicar la nueva política:

gcloud container binauthz policy import policy.yaml

Espera unos segundos para que se propague el cambio.

4. Intenta implementar una carga de trabajo de muestra:

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

5. La implementación falla con el siguiente mensaje:

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Revierte la política para permitir todo

Antes de pasar a la siguiente sección, revierte los cambios en la política.

1. En un editor de texto, cambia el evaluationMode de ALWAYS_DENY a ALWAYS_ALLOW.

edit policy.yaml

El archivo YAML de políticas que editaste debe aparecer de la siguiente manera:

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_ALLOW enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

2. Aplica la política revertida:

gcloud container binauthz policy import policy.yaml

Haz clic en Revisar mi progreso para verificar el objetivo. Crear un clúster de GKE y actualizar las políticas

Tarea 6: Firma automática de imágenes

Habilitaste la firma de imágenes y usaste manualmente el certificador para firmar tu imagen de muestra. En la práctica, querrás aplicar las certificaciones durante los procesos automatizados, como las canalizaciones de CI/CD.

En esta sección, configurarás Cloud Build para certificar imágenes automáticamente.

Roles necesarios

1. Agrega el rol de visualizador de certificadores de Autorización Binaria a la cuenta de servicio de Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/binaryauthorization.attestorsViewer

2. Agrega el rol de verificador y firmante de CryptoKey de Cloud KMS a la cuenta de servicio de Cloud Build (firma basada en KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/cloudkms.signerVerifier gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ --role roles/cloudkms.signerVerifier

3. Agrega el rol Vinculador de notas de Container Analysis a la cuenta de servicio de Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/containeranalysis.notes.attacher

Proporciona acceso para la cuenta de servicio de Cloud Build

Cloud Build necesitará derechos para acceder a la API de On-Demand Scanning.

• Proporciona acceso con los siguientes comandos:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/ondemandscanning.admin"

Prepara el paso de compilación personalizado de Cloud Build

Vas a usar un paso de compilación personalizado en Cloud Build para simplificar el proceso de certificación. Google proporciona este paso de compilación personalizado que contiene funciones auxiliares para optimizar el proceso. Antes de usarlo, el código para el paso de compilación personalizado se debe compilar en un contenedor y enviar a Cloud Build.

• Para ello, ejecuta los siguientes comandos:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git cd cloud-builders-community/binauthz-attestation gcloud builds submit . --config cloudbuild.yaml cd ../.. rm -rf cloud-builders-community

Agrega un paso de firma a tu cloudbuild.yaml

Agrega el paso de certificación a tu canalización de Cloud Build.

1. Revisa el paso de firma a continuación.

Solo revisión. No copiar

#Firmar la imagen solo si la comprobación de gravedad anterior se supera - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Escribe un archivo cloudbuild.yaml con la canalización completa que se muestra a continuación:

cat > ./cloudbuild.yaml << EOF steps: # compilación - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.'] waitFor: ['-'] # comprobaciones adicionales de CI/CD (no se muestran) #Volver a etiquetar - id: "retag" name: 'gcr.io/cloud-builders/docker' args: ['tag', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #enviar a Artifact Registry - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #Firmar la imagen solo si la comprobación de gravedad anterior se supera - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION' images: - {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good EOF

3. Ejecuta la compilación:

gcloud builds submit

Revisa la compilación en el historial de Cloud Build

En la consola de Cloud, navega a la página Cloud Build > Historial de compilaciones y revisa la compilación más reciente y la ejecución correcta de los pasos de compilación.

Haz clic en Revisar mi progreso para verificar el objetivo. Agregar un paso de firma

Tarea 7: Autorización de imágenes firmadas

Ahora, actualizarás GKE para usar Autorización Binaria y validar que la imagen tenga una firma del análisis de vulnerabilidades antes de permitir que se ejecute.

Actualiza la política de GKE para que requiera la certificación

Requiere que las imágenes estén firmadas por tu certificador agregando clusterAdmissionRules a tu política de Autorización Binaria de GKE

Actualmente, tu clúster ejecuta una política con una regla: permitir contenedores de repositorios oficiales y rechazar todos los demás.

1. Reemplaza la política con la configuración actualizada usando el siguiente comando:

COMPUTE_ZONE={{{ project_0.default_region | "REGION" }}} cat > binauth_policy.yaml << EOM defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: REQUIRE_ATTESTATION requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: ${COMPUTE_ZONE}.binauthz: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor EOM

2. Ahora deberías tener un nuevo archivo en el disco llamado updated_policy.yaml. Ahora, en lugar de que la regla predeterminada rechace todas las imágenes, primero comprueba con tu certificador para ver si hay verificaciones.

3. Sube la nueva política a Autorización Binaria:

gcloud beta container binauthz policy import binauth_policy.yaml

Implementa una imagen firmada

1. Obtén el resumen de imagen correspondiente a la imagen válida:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \ --format='get(image_summary.digest)')

2. Usa el resumen en la configuración de Kubernetes:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

3. Implementa la app en GKE

kubectl apply -f deploy.yaml

En la consola de Cloud, navega a Kubernetes Engine > Cargas de trabajo y revisa la implementación correcta de la imagen.

Haz clic en Revisar mi progreso para verificar el objetivo. Implementar una imagen firmada

Tarea 8: Bloqueo de imágenes sin firmar

Compila una imagen

1. Usa Docker local para compilar la imagen en tu caché local:

docker build -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

2. Envía la imagen sin firmar al repositorio:

docker push {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

3. Obtén el resumen de la imagen correspondiente a la imagen no válida:

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \ --format='get(image_summary.digest)')

4. Usa el resumen en la configuración de Kubernetes:

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

5. Intenta implementar la app en GKE

kubectl apply -f deploy.yaml

Revisa la carga de trabajo en la consola y toma nota del error que indica que se denegó la implementación:

No attestations found that were valid and signed by a key trusted by the attestor

Haz clic en Revisar mi progreso para verificar el objetivo. Implementar una imagen sin firma

¡Felicitaciones!

Aprendiste a crear un certificador para firmar imágenes y validar las reglas antes de permitir que una imagen de contenedor se ejecute. Aprendiste a escribir una política que indique a Cloud Build si debe permitir o denegar el acceso al clúster de GKE y usaste Autorización Binaria con Google Cloud KMS para validar firmas de imágenes y evitar que imágenes sin firmar accedan al clúster de Kubernetes.

Próximos pasos y más información

• Cómo proteger las implementaciones de imágenes en Cloud Run y Google Kubernetes Engine | Documentación de Cloud Build
• Guía de inicio rápido: Configura una política de Autorización Binaria con GKE | Google Cloud

Capacitaciones y certificaciones de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Actualización más reciente del manual: 10 de septiembre de 2024

Prueba más reciente del lab: 11 de julio de 2024

Copyright 2024 Google LLC. Todos los derechos reservados. Google y el logotipo de Google son marcas de Google LLC. El resto de los nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que están asociados.