GSP479

Descripción general

Una de las principales preocupaciones de seguridad al ejecutar clústeres de Kubernetes es saber qué imágenes de contenedor se ejecutan en cada Pod y poder dar cuenta de su origen. Establecer la "procedencia del contenedor" significa tener la capacidad de realizar un seguimiento de la fuente de un contenedor hasta un punto de origen confiable y garantizar que tu organización siga los procesos deseados durante la creación del artefacto (contenedor).

Las siguientes son algunas de las inquietudes principales:

• Origen seguro: ¿Cómo garantizas que todas las imágenes de contenedor que se ejecutan en el clúster provengan de una fuente aprobada?
• Coherencia y validación: ¿Cómo garantizas que se hayan completado de forma correcta todos los pasos de validación deseados para cada compilación y cada implementación de un contenedor?
• Integridad: Una vez probada su procedencia, ¿cómo garantizas que no se hayan modificado los contenedores antes de su ejecución?

Desde el punto de vista de la seguridad, no aplicar controles en relación con el origen de las imágenes presenta varios riesgos:

• Si no se aplican controles, un agente malicioso que haya comprometido un contenedor podría obtener privilegios de clúster suficientes para lanzar otros contenedores desde una fuente desconocida.
• Un usuario autorizado con permisos para crear Pods podría ejecutar un contenedor no deseado directamente dentro de un clúster, por accidente o de forma malintencionada.
• Un usuario autorizado podría reemplazar, por accidente o de forma malintencionada, una etiqueta de imagen de Docker por un contenedor funcional con un código no deseado agregado silenciosamente. En este caso, Kubernetes extraería e implementaría el contenedor de forma automática como parte de una implementación.

Para ayudar a los operadores de sistemas a evitar estos problemas, Google Cloud ofrece una función llamada Autorización Binaria. Es un servicio administrado por Google Cloud que trabaja estrechamente con GKE para aplicar controles de seguridad en el momento de la implementación a fin de garantizar que solo se implementen imágenes de contenedor confiables. Con la Autorización Binaria, puedes incluir registros de contenedores en la lista de entidades permitidas, exigir que autoridades confiables firmen las imágenes y aplicar esas políticas de manera centralizada. Aplicar esta política permite ejercer un mayor control sobre tu entorno de contenedores, ya que te asegurarás de que solo se integren las imágenes aprobadas o verificadas al proceso de compilación y actualización.

En este lab, implementaremos un clúster de Kubernetes Engine con la función de Autorización Binaria habilitada, demostraremos cómo incluir registros de contenedores aprobados en la lista de entidades permitidas y explicaremos el proceso de creación y ejecución de un contenedor con firma.

Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor la Autorización Binaria de GKE. Te invitamos a hacer cualquier aporte que creas conveniente.

Arquitectura

Las API de Binary Authorization y Container Analysis se basan en los proyectos de código abierto Grafeas y Kritis.

• Grafeas define una especificación de API para administrar metadatos sobre recursos de software, como imágenes de contenedor, imágenes de máquinas virtuales (VM), archivos JAR y secuencias de comandos. Puedes utilizar Grafeas para definir y agregar información sobre los componentes de tu proyecto.
• Kritis define una API para garantizar que se evite una implementación a menos que el artefacto (imagen de contenedor) cumpla con la política central y, de manera opcional, tenga las certificaciones necesarias.

En una canalización de implementación de contenedores simplificada como esta:

El contenedor transita 4 pasos como mínimo:

1. El código fuente para crear el contenedor se almacena en el control de origen.
2. Cuando se confirma un cambio en el control de origen, se compila y se prueba el contenedor.
3. Si se completan los pasos de compilación y prueba, el artefacto de imagen de contenedor se coloca en un registro central de Container Registry, listo para su implementación.
4. Cuando se envíe una implementación de esa versión del contenedor a la API de Kubernetes, el entorno de ejecución del contenedor extraerá esa imagen de Container Registry y la ejecutará como un Pod.

En la canalización de compilación de contenedores, existe la posibilidad de insertar procesos adicionales para indicar o "certificar" que se completó cada paso correctamente. Estos son algunos ejemplos: ejecución de pruebas de unidades, verificaciones de análisis de control de origen, análisis de vulnerabilidad, entre otros. A cada paso se le podría otorgar la facultad o la "autoridad de certificación" para firmar una vez que se haya completado. Una "autoridad de certificación" es una persona o un sistema con la clave de PGP correcta y la capacidad de registrar la "certificación" con la API de Container Analysis.

Mediante el uso de claves de PGP por separado, diferentes personas, sistemas o pasos de compilación de la canalización podrían realizar cada paso de la certificación (1). Cada clave de PGP se asocia con una "nota de certificación" que se almacena en la API de Container Analysis. Cuando un paso de compilación "firma" una imagen, se firma un fragmento de metadatos JSON de esa imagen a través de PGP y se envía a la API como un "caso de nota".

Una vez que se haya creado la imagen de contenedor y se hayan almacenado las certificaciones necesarias de manera centralizada (2), pueden consultarse como parte de un proceso de decisiones de políticas. En este caso, cuando un controlador de admisión de Kubernetes recibe una solicitud a la API para crear (create) o actualizar (update) un Pod:

1. Envía un webhook a la API de Binary Authorization para una decisión de políticas.
2. A continuación, se consulta la política de Autorización Binaria.
3. Si es necesario, también se consulta la API de Container Analysis sobre los casos de certificación necesarios.
4. Si la imagen de contenedor cumple con la política, puede ejecutarse.
5. Si la imagen de contenedor no cumple con la política, el cliente de la API recibe un error con un mensaje que describe por qué se evitó.

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs cuentan con un temporizador que no se puede pausar. El temporizador, 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.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

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 del navegador privada o de incógnito (opción recomendada) para ejecutar el lab. Así evitarás conflictos 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: Usa solo la cuenta de estudiante para este lab. Si usas otra cuenta de Google Cloud, es posible que se apliquen cargos a esa 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á un diálogo para que selecciones la forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:

   • El botón para 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 las credenciales de tu 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 acceder a los productos y servicios de Google Cloud, haz clic en el menú de navegación o escribe el nombre del servicio o producto en el campo Buscar.

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.

2. Haz clic para avanzar por las siguientes ventanas:

   • Continúa en la ventana de información de Cloud Shell.
   • Autoriza a Cloud Shell para que use tus credenciales para realizar llamadas a la API 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.

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

gcloud auth list

4. Haz clic en Autorizar.

Resultado:

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

5. 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.

Tarea 1: Copia los recursos

1. Ahora, debes copiar los recursos necesarios para este lab ejecutando el siguiente comando:

gsutil -m cp -r gs://spls/gke-binary-auth/* .

2. Ve al directorio de esta demostración:

cd gke-binary-auth-demo

Configura tu región y zona

Algunos recursos de Compute Engine se encuentran en regiones y zonas. Una región es una ubicación geográfica específica donde puedes ejecutar tus recursos. Cada región tiene una o más zonas.

Nota: Para obtener más información sobre las regiones y zonas y ver una lista de todas ellas, consulta esta documentación.

Ejecuta el siguiente comando para configurar una región y zona para tu lab (puedes usar la región/zona más adecuada para tu caso):

gcloud config set compute/region {{{ project_0.default_region | REGION }}} gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

Actualiza los permisos de los archivos

• Cambia los permisos de algunos archivos necesarios para este lab para que se puedan leer, escribir y ejecutar:

chmod +x create.sh chmod +x delete.sh chmod 777 validate.sh

Tarea 2: Establece la versión predeterminada del clúster

• Cambia la variable GKE_VERSION de create.sh a defaultClusterVersion, como se indica a continuación:

sed -i 's/validMasterVersions\[0\]/defaultClusterVersion/g' ./create.sh Nota: La versión predeterminada del clúster será compatible con otras dependencias de este lab.

Tarea 3: Pasos para la implementación

NOTA: Las siguientes instrucciones se aplican a las implementaciones realizadas con y sin Cloud Shell.

• Para implementar el clúster, ejecuta el siguiente comando. Puedes cambiar el texto my-cluster-1 por el nombre del clúster que deseas crear.

./create.sh -c my-cluster-1

Se mostrará el siguiente mensaje cuando se complete la secuencia de comandos create:

kubeconfig entry generated for my-cluster-1. NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS my-cluster-1 {{{project_0.default_zone | Zone}}} 1.14.8-gke.17 104.154.181.211 n1-standard-1 1.14.8-gke.17 2 RUNNING Fetching cluster endpoint and auth data. kubeconfig entry generated for my-cluster-1.

La secuencia de comandos hará lo siguiente:

1. Habilitará las API necesarias en tu proyecto; específicamente, container, containerregistry, containeranalysis y binaryauthorization.
2. Creará un clúster de Kubernetes Engine nuevo en la Zona, VPC y red predeterminadas.
3. Recuperará las credenciales de tu clúster para habilitar el uso de comandos de kubectl.

Puedes omitir las advertencias.

Tarea 4: Validación

• La siguiente secuencia de comandos validará que se haya implementado correctamente la demostración:

./validate.sh -c my-cluster-1

Si falla la secuencia de comandos, se mostrará el siguiente mensaje:

Validation Failed: the BinAuthZ policy was NOT available

Y/o

Validation Failed: the Container Analysis API was NOT available

Si pasa la secuencia de comandos, se mostrará el siguiente resultado:

Validation Passed: the BinAuthZ policy was available Validation Passed: the Container Analysis API was available

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si creaste de forma correcta un clúster de Kubernetes con Autorización Binaria, verás una puntuación de evaluación.

Crear un clúster de Kubernetes con Autorización Binaria

Tarea 5: Usa Autorización Binaria

Administra la política de Autorización Binaria

Para acceder a la IU de configuración de la política de Autorización Binaria, sigue estos pasos:

1. En la consola de Google Cloud, navega a Seguridad > Autorización Binaria.

2. Haz clic en Editar política (Edit Policy).

Nota: Para acceder a la configuración de la política de Autorización Binaria a través de gcloud:

Ejecuta gcloud beta container binauthz policy export > policy.yaml.

Realiza las modificaciones necesarias a policy.yaml.

Ejecuta gcloud beta container binauthz policy import policy.yaml.

La política que está editando corresponde a la “predeterminada” y se aplica a todos los clústeres de GKE del proyecto de Google Cloud, a menos que esté vigente una política específica del clúster.

Se recomienda crear políticas específicas para cada clúster y lograr una operación correcta (incluye registros en la lista de entidades permitidas según sea necesario) y, luego, usar la configuración “Inhabilitar todas las imágenes” para la política predeterminada a nivel de proyecto. Cualquier clúster nuevo en este proyecto necesitará su propia política específica del clúster.

3. Luego de hacer clic en Editar política, aparecerá lo siguiente.

La regla de la política predeterminada es Permitir todas las imágenes. Esta regla se comporta como si no estuviera habilitada la Autorización Binaria en el clúster.

Si se cambia la regla predeterminada a Inhabilitar todas las imágenes o Permitir solo las imágenes aprobadas por todos los certificadores que se indican a continuación, se bloquearán las imágenes que no coincidan con las rutas de acceso de las imágenes de registro exentas o que no tengan las certificaciones requeridas, respectivamente.

A continuación, realizarás algunas modificaciones en la política:

4. Cambia la Regla predeterminada de tu proyecto a Inhabilitar todas las imágenes.

5. Pulsa en Crear reglas específicas en la configuración adicional para implementaciones de GKE y Anthos.

6. Pulsa en Seleccionar clúster de GKE en el menú desplegable y haz clic en Cambiar.

7. En Reglas específicas del clúster de GKE, haz clic en Agregar regla específica.

8. En el campo Agrega una regla específica para el clúster de GKE, ingresa tu ubicación y el nombre del clúster con el formato ubicación.nombredelclúster. Por ejemplo .my-cluster-1 que corresponde a la zona y al nombre del clúster my-cluster-1.

9. Selecciona la regla predeterminada Permitir todas las imágenes para tu clúster.

10. Haz clic en AGREGAR.

11. Haz clic en Guardar política.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de Autorización Binaria y agregaste la regla Inhabilitar todas las imágenes a nivel de proyecto y Permitir todas las imágenes a nivel de clúster, verás una puntuación de evaluación.

Actualizar la política de Autorización Binaria para agregar la regla Inhabilitar todas las imágenes a nivel de proyecto y Permitir todas las imágenes a nivel de clúster

Tarea 6: Crea una imagen de GCR privada

1. Para simular una configuración real, crea una imagen de contenedor de GCR privada en tu proyecto.

2. Extrae el contenedor de nginx del proyecto nginx y envíalo a tu propio repositorio de GCR sin modificaciones.

3. En Cloud Shell, extrae el contenedor latest de nginx:

docker pull nginx:latest

4. Autentica Docker en el proyecto:

gcloud auth configure-docker

Cuando se te pregunte, Do you want to continue (Y/n)? Ingresa Y.

5. Configura la variable de shell PROJECT_ID:

PROJECT_ID="$(gcloud config get-value project)"

6. Etiquétalo y envíalo al GCR del proyecto actual:

docker tag nginx "gcr.io/${PROJECT_ID}/nginx:latest" docker push "gcr.io/${PROJECT_ID}/nginx:latest"

7. Enumera la imagen nginx "privada" en tu repositorio de GCR:

gcloud container images list-tags "gcr.io/${PROJECT_ID}/nginx"

Tarea 7: Inhabilita todas las imágenes

Para comprobar que la política de inhabilitación de imágenes funcionará según lo previsto, primero verifica que se aplique la regla allow específica del clúster y que permita que se ejecuten todos los contenedores.

1. Para hacer esto, lanza un solo Pod de nginx:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Deberías ver un mensaje que indique lo siguiente: pod/nginx created.

2. Enumera los Pods:

kubectl get pods

Resultado:

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 1m

Si esto falla, verifica la región y el nombre del clúster otra vez y vuelve a intentarlo.

3. Ahora, borra el siguiente Pod:

kubectl delete pod nginx

4. A continuación, verifica que la política de Autorización Binaria pueda bloquear la ejecución de imágenes no deseadas en el clúster.

En la página Autorización Binaria, haz clic en Editar política.

5. Haz clic en los tres puntos verticales a la derecha de tu regla específica del clúster de GKE y, luego, haz clic en Editar.

6. A continuación, selecciona Inhabilitar todas las imágenes y haz clic en Enviar.

Tu política debería ser similar a la siguiente:

7. Por último, haz clic en Guardar política para aplicar los cambios.

Importante: Antes de continuar, espera al menos 30 segundos para permitir que surta efecto la política.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de Autorización Binaria a la regla Inhabilitar todas las imágenes a nivel de clúster, verás una puntuación de evaluación.

Actualizar la política específica del clúster a la regla Inhabilitar todas las imágenes

8. A continuación, ejecuta el mismo comando que antes para crear el Pod de nginx estático:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Sin embargo, esta vez, deberías recibir un mensaje del servidor de la API que indique que la política impidió que este Pod se ejecutara correctamente:

Error from server (VIOLATES_POLICY): error when creating "STDIN": admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/qwiklabs-gcp-00-ce851250686b/nginx:latest denied by Binary Authorization cluster admission rule for {{{project_0.default_zone | Zone}}}.my-cluster-1. Denied by always_deny admission rule

Para poder ver cuándo la política de Autorización Binaria bloquea todas las imágenes, ve a los registros de auditoría de GKE en Stackdriver y filtra los mensajes de error relacionados con esta actividad.

9. En la consola de Google Cloud, navega hasta el menú de navegación > Logging > Explorador de registros.
10. Propaga el Compilador de consultas (Query builder) con la siguiente información:

resource.type="k8s_cluster" protoPayload.response.reason="VIOLATES_POLICY"

11. Haz clic en Ejecutar consulta (Run Query).
12. Deberías ver errores correspondientes al bloqueo de ejecución del Pod de nginx.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si verificaste correctamente la regla de admisión del clúster, verás una puntuación de evaluación.

Crear un Pod de Nginx para verificar que se aplique la regla de admisión del clúster para inhabilitar todas las imágenes (niega la creación)

Tarea 8: Inhabilita las imágenes, excepto aquellas de los registros de contenedores incluidos en la lista de entidades permitidas

1. Supongamos que, en realidad, deseas permitir que se ejecute solo ese contenedor de nginx. Para ello, lo más rápido es incluir en la lista de entidades permitidas el registro del que proviene.

2. Usarás el resultado del siguiente comando como la ruta de acceso de tu imagen:

echo "gcr.io/${PROJECT_ID}/nginx*"

3. Copia el resultado de la ruta de acceso de la imagen en tu búfer.

4. Ve al menú de navegación > Seguridad > Autorización Binaria.

5. Edita la Política de Autorización Binaria, bajo Reglas de exención personalizadas (Custom exemption rules), muestra las rutas de las imágenes, luego haz clic en Agregar un patrón de imagen (Add an Image Pattern).

6. Pega la ruta de acceso de la imagen que copiaste anteriormente. En la siguiente imagen, se muestra un ejemplo de ruta de acceso.

7. Haz clic en Guardar política y, luego, ejecuta lo siguiente:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Ahora deberías poder iniciar este Pod y comprobar que la inclusión de registros en la lista de entidades permitidas funciona correctamente.

8. Ejecuta el siguiente comando para limpiar y prepararte para los siguientes pasos:

kubectl delete pod nginx

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de Autorización Binaria para incluir el registro de contenedor en la lista de entidades permitidas, verás una puntuación de evaluación.

Actualizar la política de Autorización Binaria para inhabilitar imágenes, excepto de los registros de contenedores en la lista de entidades permitidas (el registro de contenedor de tu proyecto)

Tarea 9: Aplica certificaciones

Incluir registros de imágenes de contenedor en la lista de entidades permitidas es un buen punto de partida para evitar que se ejecuten imágenes de contenedor no deseadas dentro de un clúster, pero puedes hacer aún más para asegurarte de que el contenedor se haya compilado de forma correcta.

Puedes verificar de manera criptográfica que se aprobó la implementación de una imagen de contenedor determinada. Esto se logra mediante una "autoridad de certificación", que declara o certifica que se completó un determinado paso. Para esto, la autoridad de certificación usa una clave de PGP para firmar un fragmento de metadatos que describe el hash SHA256 de una imagen de contenedor y lo envía a un repositorio central de metadatos: la API de Container Analysis.

Más tarde, cuando el controlador de admisión valide si se permite la ejecución de una imagen de contenedor mediante la consulta de una política de Autorización Binaria que requiera que una imagen tenga certificaciones, verificará si la API de Container Analysis contiene los fragmentos firmados de metadatos que indican qué pasos se completaron. Con esa información, el controlador de admisión sabrá si debe permitir o denegar la ejecución de ese Pod.

A continuación, realiza una certificación manual de una imagen de contenedor. Asumirás la función de una autoridad de certificación humana y realizarás todos los pasos para firmar una imagen de contenedor, crear una política que requiera que las imágenes que se ejecutan dentro de tu clúster tengan una certificación y, luego, ejecutar correctamente esa imagen en un Pod.

Configura las variables necesarias

1. Nombre y dirección de correo electrónico del certificador:

ATTESTOR="manually-verified" # No spaces allowed ATTESTOR_NAME="Manual Attestor" ATTESTOR_EMAIL="$(gcloud config get-value core/account)" # This uses your current user/email

2. ID de la nota de Container Analysis y descripción de la autoridad de certificación:

NOTE_ID="Human-Attestor-Note" # No spaces NOTE_DESC="Human Attestation Note Demo"

3. Nombres de los archivos que crearán cargas útiles o solicitudes:

NOTE_PAYLOAD_PATH="note_payload.json" IAM_REQUEST_JSON="iam_request.json"

Crea una nota de certificación

El primer paso consiste en registrar la autoridad de certificación como una nota de Container Analysis con la API de Container Analysis. Primero, crea una nota ATTESTATION y envíala a la API.

1. Crea la carga útil de la nota ATTESTATION:

cat > ${NOTE_PAYLOAD_PATH} << EOF { "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}", "attestation_authority": { "hint": { "human_readable_name": "${NOTE_DESC}" } } } EOF

2. Envía la nota ATTESTATION a la API de Container Analysis:

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

Deberías ver que el resultado del comando anterior muestra la nota que se creó, pero el siguiente comando también mostrará esta nota:

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

Crea una clave de firma de PGP

Dado que tu autoridad de certificación usa una clave de PGP para realizar la firma criptográfica de los metadatos de la imagen, crea una clave de PGP nueva y exporta la clave pública.

Nota: Este mensaje de error está relacionado con esta actividad. En este ejercicio, la clave de PGP no está protegida con una contraseña. En un sistema de producción, asegúrate de proteger adecuadamente tus claves de PGP privadas.

1. Configura otra variable de shell:

PGP_PUB_KEY="generated-key.pgp"

2. Crea la clave de PGP:

sudo apt-get install rng-tools sudo rngd -r /dev/urandom gpg --quick-generate-key --yes ${ATTESTOR_EMAIL}

3. (Presiona Intro para usar una frase de contraseña vacía y confirmar la recepción de las advertencias).

4. Extrae la clave de PGP pública:

gpg --armor --export "${ATTESTOR_EMAIL}" > ${PGP_PUB_KEY}

Registra el certificador en la API de Binary Authorization

El paso siguiente consiste en crear el "certificador" en la API de Binary Authorization y agregarle la clave de PGP pública.

1. Crea el certificador en la API de Binary Authorization:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors create "${ATTESTOR}" \ --attestation-authority-note="${NOTE_ID}" \ --attestation-authority-note-project="${PROJECT_ID}"

2. Agrega la clave de PGP al certificador:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR}" \ --pgp-public-key-file="${PGP_PUB_KEY}"

3. Indica el certificador que se acaba de crear:

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

El resultado debería ser similar al siguiente:

NAME: manually-verified NOTE: projects//notes/Human-Attestor-Note NUM_PUBLIC_KEYS: 1

Tarea 10: "Firma" una imagen de contenedor

Los pasos anteriores solo se deben realizar una vez. A partir de ahora, este es el único paso que debe repetirse para cada imagen de contenedor nueva.

Ya se compiló y se encuentra disponible la imagen de nginx en nginx:latest. Realiza las certificaciones manuales como si fuera tu propia imagen compilada por procesos propios y evita tener que compilarla.

1. Establece algunas variables de shell:

GENERATED_PAYLOAD="generated_payload.json" GENERATED_SIGNATURE="generated_signature.pgp"

2. Obtén la huella digital de PGP:

PGP_FINGERPRINT="$(gpg --list-keys ${ATTESTOR_EMAIL} | head -2 | tail -1 | awk '{print $1}')"

3. Obtén el resumen de SHA256 de la imagen de contenedor:

IMAGE_PATH="gcr.io/${PROJECT_ID}/nginx" IMAGE_DIGEST="$(gcloud container images list-tags --format='get(digest)' $IMAGE_PATH | head -1)"

4. Crea una carga útil de firma con formato JSON:

gcloud beta container binauthz create-signature-payload \ --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" > ${GENERATED_PAYLOAD}

5. Visualiza la carga útil de firma que se generó:

cat "${GENERATED_PAYLOAD}"

6. "Firma" la carga útil con la clave de PGP:

gpg --local-user "${ATTESTOR_EMAIL}" \ --armor \ --output ${GENERATED_SIGNATURE} \ --sign ${GENERATED_PAYLOAD}

7. Visualiza la firma generada (mensaje de PGP):

cat "${GENERATED_SIGNATURE}"

8. Crea la certificación:

gcloud beta container binauthz attestations create \ --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \ --signature-file=${GENERATED_SIGNATURE} \ --public-key-id="${PGP_FINGERPRINT}"

9. Visualiza la certificación que se acaba de crear:

gcloud beta container binauthz attestations list \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}"

Tarea 11: Ejecuta una imagen con la función de aplicación de certificación habilitada

El siguiente paso consiste en cambiar la política de Autorización Binaria para establecer que la certificación debe estar presente en todas las imágenes que no coincidan con los patrones incluidos en la lista de entidades permitidas.

1. Para modificar la política de modo tal que exija certificación, ejecuta el siguiente comando y, luego, copia la ruta de acceso o el nombre completo de la autoridad de certificación:

echo "projects/${PROJECT_ID}/attestors/${ATTESTOR}" # Copy this output to your copy/paste buffer

2. A continuación, edita la política de Autorización Binaria para modificar la regla específica del clúster de GKE con el comando edit.

Haz clic en los tres puntos que se encuentran junto al nombre de tu clúster y selecciona Editar para modificar las reglas específicas del clúster.

3. Selecciona Solicitar certificaciones (permitir solo imágenes verificadas por los siguientes certificadores) (Require attestations (Allow only images that have been verified by all of the following attestors) en lugar de No permitir ninguna imagen (Disallow all images) en la ventana emergente.

4. Después, haz clic en Agregar certificadores (Add Attestors) seguido de Agregar por ID de recurso del certificador. Ingresa el contenido de tu portapapeles en el formato de projects/${PROJECT_ID}/attestors/${ATTESTOR}, luego haz clic en Agregar 1 certificador, después en Enviar y, finalmente, haz clic enGuardar política.

La política predeterminada aún debería tener la regla Inhabilitar todas las imágenes (Disallow all images), pero la regla específica del clúster debería requerir certificación.

5. Ahora, obtén el resumen SHA256 más reciente de la imagen firmada de los pasos anteriores:

IMAGE_PATH="gcr.io/${PROJECT_ID}/nginx" IMAGE_DIGEST="$(gcloud container images list-tags --format='get(digest)' $IMAGE_PATH | head -1)"

6. Espera al menos 30 segundos desde el momento en que actualizaste la política de Autorización Binaria, ejecuta el Pod y comprueba que se realizó de forma correcta:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "${IMAGE_PATH}@${IMAGE_DIGEST}" ports: - containerPort: 80 EOF

¡Felicitaciones! Ya certificaste manualmente una imagen de contenedor y aplicaste una política para esa imagen dentro de tu clúster de GKE.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si actualizaste correctamente la política de Autorización Binaria para modificar la regla específica del clúster y permitir solo imágenes aprobadas por certificadores, verás una puntuación de evaluación.

Actualizar la política de Autorización Binaria para modificar la regla específica del clúster y permitir solo imágenes aprobadas por certificadores

Tarea 12: Maneja situaciones de emergencia

Desde la perspectiva de un usuario, la política de Autorización Binaria podría bloquear una imagen de forma incorrecta o podría producirse otro problema en el buen funcionamiento del webhook del controlador de admisión.

En este caso de "urgencia", existe una función de emergencia que aprovecha una anotación específica para indicarle al controlador de admisión que debe ejecutar el Pod y omitir la aplicación de la política.

Nota: Cuando esto ocurra, deberás notificar a un equipo de seguridad, ya que podrían aprovecharlo usuarios malintencionados si tienen la capacidad de crear un Pod.

Sin embargo, en este caso sus procedimientos de respuesta se pueden iniciar en cuestión de segundos después de que se produzca la actividad. Los registros están disponibles en Stackdriver:

1. Para ejecutar un contenedor de nginx sin firma con la anotación de emergencia, ejecuta el siguiente comando:

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx-alpha annotations: alpha.image-policy.k8s.io/break-glass: "true" spec: containers: - name: nginx image: "nginx:latest" ports: - containerPort: 80 EOF

2. En la consola de Google Cloud, ve al menú de navegación > Logging > página Explorador de registros.

3. Propaga el cuadro Compilador de consultas con la información de más abajo y haz clic en Ejecutar consulta.

   resource.type="k8s_cluster" protoPayload.request.metadata.annotations."alpha.image-policy.k8s.io/break-glass"="true"

4. Deberías ver eventos cuando el controlador de admisión permitió un Pod, ya que está presente la anotación. Desde este filtro, puedes crear un Receptor que envíe registros que coincidan con este filtro a un destino externo.

Nota: Espera entre 5 y 10 minutos para que aparezcan los registros.

Tarea 13: Eliminación

Qwiklabs eliminará todos los recursos que creaste en este lab, pero es bueno saber cómo limpiar tu entorno.

1. Con la siguiente secuencia de comandos, se destruirá el clúster de Kubernetes Engine:

./delete.sh -c my-cluster-1

Si, al comienzo del lab, creaste tu propio nombre de clúster, úsalo. En este ejemplo, se utilizó el nombre my-cluster-1.

Las últimas líneas del resultado se verán así:

Deleting cluster Nota: El comando de eliminación del clúster se ejecuta de forma asincrónica, por lo que eliminar el clúster tardará unos minutos. Si lo deseas, usa la IU de la consola de Cloud o el comando gcloud container clusters list para realizar un seguimiento del progreso. Espera hasta que se elimine el clúster.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si eliminaste correctamente tu clúster, verás una puntuación de evaluación.

Eliminar (borrar clúster)

Con los siguientes comandos, se eliminarán los recursos restantes.

2. Borra la imagen de contenedor que se envió a GCR con el siguiente comando:

gcloud container images delete "${IMAGE_PATH}@${IMAGE_DIGEST}" --force-delete-tags

3. Si se te pregunta Do you want to continue (Y/n)?, ingresa Y.

4. Borra el certificador con el siguiente comando:

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors delete "${ATTESTOR}"

5. Borra la nota de Container Analysis con el siguiente comando:

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

Soluciona problemas en tu propio entorno

1. Si actualizas la política de Autorización Binaria y rápidamente intentas lanzar un Pod o un contenedor nuevo, es posible que la política no tenga tiempo de aplicarse. Quizás debas esperar 30 segundos o más para que se active el cambio de política. Para volver a intentarlo, borra tu Pod con el comando kubectl delete <nombredepod> y vuelve a enviar el comando de creación de Pod.
2. Ejecuta el comando gcloud container clusters list para verificar el estado del clúster.
3. Si habilitas funciones adicionales, como --enable-network-policy, --accelerator, --enable-tpu o --enable-metadata-concealment, es posible que debas agregar registros adicionales a la lista de entidades permitidas de tu política de Autorización Binaria para que se puedan ejecutar estos Pods. Usa kubectl describe pod <nombredelpod> para encontrar la ruta de registro de la especificación de la imagen y agregarla a la lista de entidades permitidas con el formato gcr.io/example-registry/* y guardar la política.
4. Si recibes errores sobre las cuotas, aumenta tu cuota en el proyecto. Obtén más información sobre cuotas de Recursos en la documentación de cuotas de recursos.

Materiales relevantes

1. Cuotas de Google Cloud
2. Registrarse en Google Cloud
3. Google Cloud Shell
4. Autorización Binaria en GKE
5. Notas de Container Analysis
6. Controlador de admisión de Kubernetes
7. Etapas de lanzamiento

¡Felicitaciones!

En este lab, aprendiste a implementar un clúster de Kubernetes Engine con la Autorización Binaria para proteger tu entorno.

Última actualización del manual: 27 de febrero de 2025

Prueba más reciente del lab: 27 de febrero de 2025

Copyright 2024 Google LLC. Este software se proporciona tal como está, sin garantías ni declaraciones para ningún uso o propósito. El uso que hagas de él está sujeto a tu acuerdo con Google.