Empezar a usar la consola de Google Cloud (GKE)

Nota: En este tutorial se presupone que has leído el artículo de información general sobre la autorización binaria.

En este tutorial se muestra cómo configurar y probar una política de autorización binaria que requiera atestaciones. Este tipo de política protege tu cadena de suministro de software basada en contenedores definiendo quién puede desplegar imágenes de contenedor en Google Kubernetes Engine (GKE) y qué imágenes de contenedor puede desplegar GKE.

En el momento del despliegue, la autorización binaria usa encargados de la atestación para verificar las firmas digitales de las atestaciones. Las atestaciones se crearon mediante firmantes como parte del proceso de compilación.

En este tutorial, el clúster de GKE, las certificaciones y los certificadores se encuentran en un mismo proyecto. Una configuración de un solo proyecto es muy útil para probar o experimentar con el servicio. Para ver un ejemplo más práctico, consulta la configuración de varios proyectos.

En los pasos que se indican a continuación se describen las tareas que se realizan desde la consola Google Cloud , así como algunas tareas que se llevan a cabo mediante comandos gcloud. Para llevar a cabo estos pasos con gcloud, consulta Primeros pasos con la CLI de Google Cloud.

Definir el proyecto predeterminado

Para facilitar los comandos que se indican a continuación, almacena el ID de tu proyecto Google Cloud en una variable de entorno de la siguiente manera:

PROJECT_ID=PROJECT_ID

donde PROJECT_ID es el nombre de tu proyecto.

Si no está seleccionado el proyecto predeterminado, configúralo ahora:

gcloud config set project ${PROJECT_ID}

Crear un clúster con la autorización binaria habilitada

Crear el clúster

Ahora puedes crear un clúster de GKE con la autorización binaria habilitada. Aquí, creas un clúster llamado test-cluster en la zona de GKE us-central1-a.

Para crear el clúster, sigue estos pasos:

1. Ve al menú de GKE en la Google Cloud consola.

   Ir a GKE

2. Haz clic en Crear clúster.

3. Introduce test-cluster en el campo Nombre.

4. Selecciona Zonal en las opciones de Tipo de ubicación.

5. Selecciona us-central1-a en la lista desplegable Zona.

6. Haz clic en Disponibilidad, redes, seguridad y otras funciones.

7. En la sección Seguridad, selecciona Habilitar la autorización binaria.

8. Selecciona Solo aplicar.

9. Haz clic en Crear.

Configurar kubectl

También debes actualizar el archivo kubeconfig local de tu instalación de kubectl. De esta forma, se proporcionan las credenciales y la información del endpoint necesarias para acceder al clúster en GKE.

Para actualizar el archivo kubeconfig local, sigue estos pasos:

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Ver la política predeterminada

Una política de autorización binaria es un conjunto de reglas que rigen el despliegue de imágenes de contenedor. Puedes tener una política por proyecto. De forma predeterminada, la política está configurada para permitir que se desplieguen todas las imágenes de contenedor.

Para ver la política predeterminada, siga estos pasos:

1. Ve a la página Autorización binaria de la Google Cloud consola.

   Ir a Autorización binaria

2. Haz clic en Editar política.

3. En Regla predeterminada del proyecto, se muestra la opción Permitir todas las imágenes.

4. Haz clic en Save Policy.

Crear un encargado de la atestación

Un atestador es la autoridad de verificación que el verificador de la autorización binaria usa en el momento del despliegue para decidir si permite que GKE despliegue la imagen de contenedor firmada correspondiente. El attestor contiene la clave pública y, normalmente, lo gestionan las personas responsables de la seguridad de la cadena de suministro de software.

Para crear un encargado de la atestación, debes hacer lo siguiente:

• Crear el encargado de la atestación en Autorización binaria
• Generar automáticamente una nota de attestor asociada en Artifact Analysis para almacenar metadatos de certificación de confianza que se utilizan en el proceso de autorización

En este tutorial, tienes un attestor llamado test-attestor. En un caso práctico, puedes tener cualquier número de certificadores, cada uno de los cuales representa a una parte que participa en el proceso de autorización de la imagen.

Generar un par de claves

La autorización binaria usa claves criptográficas para verificar de forma segura la identidad de los firmantes. De esta forma, solo se podrán desplegar las imágenes de contenedor autorizadas. El par de claves consta de una clave privada y una clave pública. El firmante usa la clave privada para firmar el resumen de la imagen de contenedor, lo que genera una firma que se almacena en una atestación. La clave pública se almacena en el attestor. En el momento de la implementación, el verificador de autorización binaria usa la clave pública del attestor para verificar la firma de la certificación antes de permitir que se implemente el contenedor.

En este tutorial, se usa el formato de infraestructura de clave pública (X.509) (PKIX) para las claves criptográficas. En este tutorial se usa el algoritmo de firma digital de curva elíptica (ECDSA), que es el recomendado, para generar un par de claves PKIX. También puedes usar claves RSA o PGP para firmar. Consulta Propósitos y algoritmos de claves para obtener más información sobre los algoritmos de firma.

Las claves generadas y almacenadas por Cloud Key Management Service (Cloud KMS) cumplen el estándar PKIX. Consulta Crear attestors con la CLI para obtener más información sobre el uso de claves PKIX y Cloud KMS.

Advertencia: Te recomendamos que no utilices pares de claves generados localmente en entornos de producción, ya que suponen un riesgo para la seguridad. En su lugar, le recomendamos que utilice Cloud Key Management Service. Este ejemplo se proporciona únicamente con fines ilustrativos.

Para generar un par de claves PKIX, sigue estos pasos:

1. Crea la clave privada:

   PRIVATE_KEY_FILE="/tmp/ec_private.pem"
   openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
   

2. Extrae la clave pública de la clave privada:

   PUBLIC_KEY_FILE="/tmp/ec_public.pem"
   openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
   

Crear el encargado de la atestación

Ahora puede crear el attestor en Autorización binaria y asociar la clave pública que ha creado.

Para crear el attestor, haz lo siguiente:

1. Vuelve a la página Autorización binaria de la Google Cloud consola.

   Volver a Autorización binaria

2. En la pestaña Encargados de la atestación, haz clic en Crear.

   

3. Rellena los campos de la siguiente manera:

   1. Introduce test-attestor en el campo Nombre del attestor.

   2. Comprueba que la opción Crear automáticamente una nota de análisis de artefactos esté marcada.

   3. Haz clic en Añadir clave pública PKIX.

   4. Abre /tmp/ec_public.pem en un editor de texto. Este es el archivo de clave pública que has creado en el paso anterior. Copia el contenido del archivo en el cuadro de texto Material de clave pública.

   5. Haz clic en Elliptic Curve P-256 - SHA256 Digest en el menú desplegable Algoritmo de firma.

   6. Haz clic en Listo.

4. Haz clic en Crear para crear el attestor.

5. Almacena el ID de la clave pública.

   Para ver el ID de la clave pública de tu attestor después de añadirla al attestor, usa gcloud container binauthz attestors describe ${ATTESTOR_NAME}. Para crear una variable de entorno que almacene el ID de la clave pública, ejecuta el siguiente comando:

   ATTESTOR_NAME=test-attestor
   PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\
     --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
   

Configurar la política

Ahora puedes configurar tu política:

1. Vuelve a la página Autorización binaria en la Google Cloud consola.

2. En la pestaña Política, haga clic en Editar política.

3. Selecciona Permitir solo imágenes aprobadas por los siguientes certificadores.

4. Haz clic en Añadir verificadores.

5. Haz clic en Añadir por proyecto y nombre de encargado de la atestación.

6. Introduce PROJECT_ID en el campo Nombre del proyecto.

7. Introduce test-attestor en el campo Nombre del attestor.

8. Haz clic en Añadir 1 certificador.

9. Haz clic en Save Policy.

Nota: La política puede tardar unos minutos en aplicarse.

Para obtener más información, consulta Configurar una política con la consola.

Probar la política

Puedes probar la política que has configurado anteriormente intentando desplegar una imagen de contenedor de ejemplo en el clúster. La política bloqueará la implementación porque no se ha realizado la certificación obligatoria.

En este tutorial, puedes usar imágenes de ejemplo de Artifact Registry. La imagen de Artifact Registry se encuentra en la ruta us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. La ruta contiene una imagen pública creada por Google que incluye una aplicación de ejemplo "Hello, World!".

Para intentar desplegar la imagen, ejecuta el siguiente comando:

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080

Ahora, comprueba que la autorización binaria ha bloqueado el despliegue:

kubectl get pods

El comando imprime el siguiente mensaje, que indica que la imagen no se ha desplegado:

No resources found.

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

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

Verá una respuesta similar a la siguiente:

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by ATTESTOR_NAME: No attestations found

En este resultado:

• POD_NAME: el nombre del pod.
• IMAGE_NAME: el nombre de la imagen.
• ATTESTOR_NAME: el nombre del encargado de la atestación.

Elimina la implementación para poder continuar con el siguiente paso:

kubectl delete deployment hello-server

Crear una atestación

Una atestación es un documento digital creado por un firmante que certifica que GKE tiene permiso para desplegar la imagen de contenedor asociada. El proceso de creación de una certificación a veces se denomina "firmar una imagen".

En este tutorial, crearás una certificación para imágenes de ejemplo de Artifact Registry.

Para crear una certificación, sigue estos pasos:

1. Define variables que almacenen la ruta del registro y el digest de la imagen, así como el nombre del verificador:

   Artifact Registry

   IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
   IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
   ATTESTOR="test-attestor"
   IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
   

2. Genera la carga útil de la atestación:

   Nota: En el siguiente comando, aunque se necesita un ${IMAGE_PATH} para crear la carga útil de la firma de la certificación, solo se usa el ${IMAGE_DIGEST} en el momento de la implementación. Esto significa que puedes implementar una imagen de contenedor idéntica desde varias ubicaciones con la misma certificación.

   Artifact Registry

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

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

   {
   "critical": {
     "identity": {
       "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
     },
     "image": {
       "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
     },
     "type": "Google cloud binauthz container signature"
   }
   }
   

3. Firma la carga útil con tu clave privada PKIX y genera un archivo de firma:

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

   El archivo de firma es una versión firmada digitalmente del archivo JSON de carga útil que has creado anteriormente.

4. Crea y valida la atestación:

   gcloud container binauthz attestations create \
       --project="${PROJECT_ID}" \
       --artifact-url="${IMAGE_TO_ATTEST}" \
       --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
       --signature-file=/tmp/ec_signature \
       --public-key-id="${PUBLIC_KEY_ID}" \
       --validate
   

   donde PUBLIC_KEY_ID es el ID de la clave pública que has encontrado en la sección Generar un par de claves PKIX de arriba.

   La marca validate comprueba que la certificación se puede verificar mediante el certificador que has configurado en tu política.

5. Verifica que se haya creado la certificación:

   gcloud container binauthz attestations list \
       --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID
   

Para obtener más información sobre cómo crear certificaciones, consulta el artículo Crear certificaciones.

Volver a probar la política

Vuelve a probar la política desplegando una imagen de contenedor de ejemplo en el clúster. En esta ocasión, debes implementar la imagen con el digest en lugar de con una etiqueta como 1.0 o latest, ya que la autorización binaria usará el digest para buscar las certificaciones. En este caso, la autorización binaria permite que se despliegue la imagen porque se ha realizado la atestación necesaria.

Para desplegar la imagen, ejecuta el siguiente comando:

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

Para verificar que la imagen se ha implementado, ejecuta el siguiente comando:

kubectl get pods

El comando muestra un mensaje similar al siguiente, que indica que la implementación se ha realizado correctamente:

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

Para eliminar el pod, ejecuta el siguiente comando:

kubectl delete pod hello-server