Esta página se ha traducido con Cloud Translation API.

Empezar a usar la CLI de Google Cloud (GKE)

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 la guía 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.
Firmar un digest de 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.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

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 (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

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 (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

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 kubectl para interactuar con GKE.

Habilitar la autorización binaria

Definir el proyecto predeterminado

El primer paso es definir el Google Cloud proyecto predeterminado que usa 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ñada 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 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 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:

Crea una nota en Artifact Analysis para almacenar metadatos de confianza que se usen en el proceso de autorización.
Crea el encargado de la atestación en la autorización binaria y asocia la nota que has creado.

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, puede haber 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

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.json que 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"
    }
  }
}
EOM

Para 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}"
```
Precaución: La autorización binaria no admite el análisis de artefactos almacenamiento regional ni endpoints regionales. Te recomendamos que uses el endpoint de la API global Artifact Analysis (https://containeranalysis.googleapis.com/).

Comprueba 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}"

Crear el encargado de la atestación

Ahora puedes crear el attestor:

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

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.

En una configuración de varios proyectos, debes definir los permisos de la nota ContainerAnalysis tal como se describe en la sección Configuración de varios proyectos. No es necesario en un escenario de un solo proyecto, ya que el proyecto tiene el roles/containeranalysis.notes.occurrences.viewer necesario de forma predeterminada.

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

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=1

Para 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}  \
  --purpose ${KMS_KEY_PURPOSE} \
  --default-algorithm ${KMS_KEY_ALGORITHM} \
  --protection-level ${KMS_PROTECTION_LEVEL}

Para añadir la clave pública al attestor, ejecuta el siguiente comando:

gcloud --project="${PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

Obtén el ID de clave pública del attestor de la siguiente manera:

Puedes ver el ID de tu clave pública en cualquier momento con el comando: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

Para guardar el ID de tu clave pública en una variable de entorno, introduce este comando:
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${PROJECT_ID})
```

PKIX (clave local)

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

Crea la clave privada:

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

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}

Añade la clave pública al encargado de la atestación.

Ahora, añade la clave pública que has exportado al attestor para que la autorización binaria pueda usarla para verificar la identidad:
```
gcloud --project="${PROJECT_ID}" \
    beta container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --pkix-public-key-file=${PUBLIC_KEY_FILE} \
    --pkix-public-key-algorithm=ecdsa-p256-sha256
```
Nota: Este comando muestra el PUBLIC_KEY_ID que usas al crear una certificación. Se encuentra en el campo id del resultado y tiene el siguiente aspecto:ni:///sha-256;ybf_gINTzsBKLCaRIeQnExNhKFkGONXXXlr63QeZY-Q.
Guarda el ID de la clave pública.

Para guardar el ID de la clave pública, puedes copiarlo de la salida de public-keys add anterior. Para ver el ID de la clave pública de tu attestor después de añadirlo al attestor, usa gcloud container binauthz attestors describe ${ATTESTOR_NAME}:
```
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. En este paso, exportará el archivo YAML de la política a su sistema local y modificará la regla predeterminada para que requiera una certificación del certificador que ha definido anteriormente.

Para configurar la política, sigue estos pasos:

Crea un archivo de política que permita imágenes del sistema mantenidas por Google, defina evaluationMode en REQUIRE_ATTESTATION y añada un nodo llamado requireAttestationsBy que haga referencia al attestor que has creado:

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${PROJECT_ID}/policy
EOM

Importa el archivo YAML de la política en la autorización binaria:
```
gcloud container binauthz policy import /tmp/policy.yaml
```

Para obtener más información sobre cómo configurar una política, consulta el artículo Configurar una política con la CLI de gcloud.

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 atestació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!".

Primero, intenta desplegar la imagen:

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 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 puede desplegar la imagen de contenedor asociada. El proceso de creación de una certificación a veces se denomina "firmar una imagen". Un firmante puede ser una persona o, lo que es más habitual, un proceso automatizado que se ejecuta cuando se crea una imagen de contenedor. La firma se crea con la clave privada de un par de claves. En el momento del despliegue, el verificador de la autorización binaria usa la clave pública del atestador para verificar la firma de la atestación.

En este tutorial, tu certificación simplemente indica que autorizas la imagen para el despliegue.

Para crear una certificación, sigue estos pasos:

Define variables que almacenen la ruta del registro y el digest de la imagen:

Artifact Registry

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

Para crear la certificación, haz lo siguiente:

PKIX Cloud KMS

Para crear la certificación con la clave de Cloud KMS, ejecuta el siguiente comando:

gcloud beta container binauthz attestations sign-and-create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

PKIX (clave local)

Para crear la certificación con la clave local, sigue estos pasos:

Genera la carga útil de la atestación:

gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_TO_ATTEST} > /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:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}

Para firmar la carga útil con tu clave privada PKIX y generar un archivo de firma, ejecuta el siguiente comando:
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
El archivo de firma es la versión firmada del archivo JSON de la carga útil que has creado anteriormente en esta guía.
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
```
Sustituye PUBLIC_KEY_ID por 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.

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 implementar la imagen, sigue estos pasos:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

Para verificar que la imagen se ha implementado, sigue estos pasos:

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

Limpieza

Para evitar que los recursos utilizados en este tutorial se cobren en tu cuenta de Google Cloud, elimina el proyecto que contiene los recursos o conserva el proyecto y elimina los recursos.

Elimina el clúster que has creado en GKE:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

Siguientes pasos

Más información sobre la autorización binaria
Familiarizarse con los conceptos clave que se usan en la autorización binaria
Utiliza el built-by-cloud-build attestor para desplegar solo imágenes creadas por Cloud Build (vista previa).
Habilitar el modo de prueba para inhabilitar la aplicación
Usar el acceso de emergencia para saltarse la implementación obligatoria

Empezar a usar la CLI de Google Cloud (GKE) Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Objetivos

Costes

Antes de empezar

Habilitar la autorización binaria

Definir el proyecto predeterminado

Habilitar las APIs necesarias

Artifact Registry

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

Crear el clúster

Configurar kubectl

Ver la política predeterminada

Crear un encargado de la atestación

Crear la nota de Artifact Analysis

Crear el encargado de la atestación

Generar un par de claves

PKIX (Cloud KMS)

PKIX (clave local)

Configurar la política

Probar la política

Crear una atestación

Artifact Registry

PKIX Cloud KMS

PKIX (clave local)

Volver a probar la política

Limpieza

Siguientes pasos

Empezar a usar la CLI de Google Cloud (GKE)

Configurar `kubectl`