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 la cadena de suministro de software basada en contenedores verificando que una imagen de contenedor tenga una certificación firmada antes de permitir que se despliegue.
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 las crean los firmantes, normalmente como parte de un flujo de integración continua (CI).
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 debes realizar en la línea de comandos. Para seguir estos pasos con la consola de Google Cloud , consulta Empezar a usar la consola de Google Cloud .
Objetivos
En este tutorial, aprenderás a hacer lo siguiente:
- Crea un clúster de Google Kubernetes Engine (GKE) con la autorización binaria habilitada.
- Crea un attestor que el verificador de autorización binaria use para verificar la firma de una atestación.
- Configurar una política que requiera una certificación
- Crea un par de claves criptográficas para firmar atestaciones y verificarlas más adelante.
- Firma el digest de una imagen de contenedor para crear una firma
- Crear una certificación mediante la firma
- Probar la política desplegando una imagen de contenedor en GKE
Costes
En este documento, se utilizan los siguientes componentes facturables de Google Cloud:
Para generar una estimación de costes basada en el uso previsto,
utiliza la calculadora de precios.
Antes de empezar
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.
-
Para inicializar gcloud CLI, ejecuta el siguiente comando:
gcloud init -
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
-
Install the Google Cloud CLI.
-
Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.
-
Para inicializar gcloud CLI, ejecuta el siguiente comando:
gcloud init - Instala
kubectlpara interactuar con GKE. - Crea una nota en Artifact Analysis para almacenar los metadatos de confianza que se usan en el proceso de autorización.
- Crea el encargado de la atestación en Binary Authorization y asocia la nota que has creado
Define variables que almacenen el nombre de tu attestor y de la nota de Artifact Analysis:
ATTESTOR_NAME=test-attestor NOTE_ID=test-attestor-note
Sustituye:
- test-attestor: nombre del encargado de la atestación que elijas.
- attestor-note: nombre de la nota del encargado de la atestación que elijas.
Crea un archivo JSON en
/tmp/note_payload.jsonque describa la nota de Container Analysis:cat > /tmp/note_payload.json << EOM { "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}", "attestation": { "hint": { "human_readable_name": "Attestor Note" } } } EOMPara crear la nota, envía una solicitud HTTP a la API REST de Artifact Analysis:
curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @/tmp/note_payload.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"Verifica que se haya creado la nota:
curl \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"Crea el encargado de la atestación en Autorización binaria:
gcloud container binauthz attestors create ${ATTESTOR_NAME} \ --attestation-authority-note=${NOTE_ID} \ --attestation-authority-note-project=${PROJECT_ID}Comprueba que se haya creado el encargado de la atestación:
gcloud container binauthz attestors list
Configura las variables de entorno necesarias para crear el par de claves.
KMS_KEY_PROJECT_ID=${PROJECT_ID} KMS_KEYRING_NAME=my-binauthz-keyring KMS_KEY_NAME=my-binauthz-kms-key-name KMS_KEY_LOCATION=global KMS_KEY_PURPOSE=asymmetric-signing KMS_KEY_ALGORITHM=ec-sign-p256-sha256 KMS_PROTECTION_LEVEL=software KMS_KEY_VERSION=1Para crear el conjunto de claves, ejecuta el siguiente comando:
gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION}Para crear la clave, ejecuta el siguiente comando:
gcloud kms keys create ${KMS_KEY_NAME} \ --location ${KMS_KEY_LOCATION} \ --keyring ${KMS_KEYRING_NAME
Habilitar la autorización binaria
Definir el proyecto predeterminado
El primer paso es definir el proyecto Google Cloud predeterminado que utiliza el comando gcloud:
PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
donde PROJECT_ID es el nombre de tu proyecto.
Habilitar las APIs necesarias
Habilita las APIs de:
Artifact Registry
gcloud --project=${PROJECT_ID} \
services enable\
container.googleapis.com\
artifactregistry.googleapis.com\
binaryauthorization.googleapis.com
Crear un clúster con la autorización binaria habilitada
Crear el clúster
Crea un clúster de GKE con la autorización binaria habilitada. Este es el clúster en el que quieres que se ejecuten tus imágenes de contenedor desplegadas. Cuando creas el clúster, pasas la marca --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE al comando gcloud container clusters create.
Para crear el clúster, sigue estos pasos:
gcloud container clusters create \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
--zone us-central1-a \
test-cluster
Aquí, creas un clúster llamado test-cluster en la zona de GKE us-central1-a.
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.
La autorización binaria te permite exportar e importar un archivo de política en formato YAML. Este formato refleja la estructura de una política tal como la almacena el servicio. Cuando configuras una política con comandos gcloud, editas este archivo.
Para ver la política predeterminada, exporta el archivo YAML de la política:
gcloud container binauthz policy export
De forma predeterminada, el archivo tiene el siguiente contenido:
defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_ALLOW globalPolicyEvaluationMode: ENABLE name: projects/PROJECT_ID/policy
La regla predeterminada se define en el nodo defaultAdmissionRule. evaluationMode especifica que la política permite todos los intentos de despliegue de imágenes. En este tutorial, actualizarás la regla predeterminada para que requiera certificaciones.
globalPolicyEvaluationMode
exime a las imágenes del sistema gestionadas por Google de la aplicación de la autorización binaria.
Para añadir una imagen exenta a la lista de permitidas, añade lo siguiente al archivo de políticas:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Sustituye EXEMPT_IMAGE_PATH por la ruta de la imagen que quieras excluir. Para excluir más imágenes, añade más entradas - namePattern. Consulta más información sobre admissionWhitelistPatterns.
Para obtener más información sobre la estructura de una política, consulta la referencia de las políticas en YAML.
Crear un encargado de la atestación
Un atestador es la autoridad de verificación que el verificador de autorización binaria utiliza 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 gestiona el personal de tu organización responsable de la seguridad de la cadena de suministro de software.
Para crear un encargado de la atestación, debes hacer lo siguiente:
En este tutorial, tienes un attestor llamado test-attestor y una nota de análisis de contenedor llamada test-attestor-note. En un caso práctico, puedes tener cualquier número de verificadores, cada uno de los cuales representa a una parte que participa en el proceso de autorización de una imagen de contenedor.
Crear la nota de Artifact Analysis
Crear el encargado de la atestación
Ahora puedes crear el attestor:
El attestor que has creado aún no se puede usar sin un par de claves asociado, que crearás más adelante en esta guía.
Generar un par de claves
Autorización binaria usa claves criptográficas para verificar de forma segura la identidad de los firmantes. De esta forma, solo se pueden 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 del contenedor, lo que genera una firma que se almacena en una atestación. La clave pública se almacena en el encargado de la atestación. En el momento de la implementación, el verificador de autorización binaria usa la clave pública del attestor para verificar la firma en 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) recomendado para generar un par de claves PKIX. También puedes usar claves RSA o PGP para firmar imágenes.
Para obtener más información sobre los algoritmos de firma, consulte Propósitos y algoritmos de claves.
Las claves generadas y almacenadas por Cloud Key Management Service (Cloud KMS) cumplen el estándar PKIX. Para obtener más información sobre cómo usar claves PKIX y Cloud KMS, consulta Crear verificadores mediante la CLI de gcloud.
PKIX (Cloud KMS)
Para crear el par de claves en Cloud KMS, sigue estos pasos: