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

Configurar varios proyectos

En este tutorial se describe cómo usar la autorización binaria en una configuración de varios proyectos. Para obtener una configuración más sencilla de un solo proyecto, consulta Empezar a usar la CLI de Google Cloud (GKE).

Para establecer la separación de funciones, puede configurar la autorización binaria en una configuración de varios proyectos. El objetivo de cada proyecto se explica más adelante en este tutorial.

Objetivos

En este tutorial, realizarás las siguientes tareas:

Configura un proyecto diferente para la implementación (GKE), el attestor y la gestión de atestaciones para admitir la separación de funciones.
Configura la regla predeterminada de tu política de autorización binaria para que requiera certificaciones.
Crea un par de claves de infraestructura de clave pública (X.509) (PKIX) para firmar y, más adelante, verificar la certificación.
Crea un attestor que el verificador de la autorización binaria use para verificar la atestación.
Firma una imagen de ejemplo para crear una certificación.
Prueba la política implementando la imagen de ejemplo.

Debes configurar el control de acceso adecuado de cada proyecto mediante Gestión de Identidades y Accesos (IAM).

Para aumentar la seguridad, puedes usar Controles de Servicio de VPC para proteger los recursos que crees en este tutorial. Para obtener más información, consulta el artículo Reforzar la seguridad con Controles de Servicio de VPC.

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.

Configurar el proyecto de implementación

El proyecto de implementación gestiona los clústeres de Google Kubernetes Engine (GKE), donde se despliegan las imágenes, y la política de autorización binaria que esta aplica en el momento de la implementación. Puedes tener más de un proyecto de implementación, en función del tamaño, la complejidad y otros requisitos de tu entorno.

Para configurar el proyecto de implementación:

Crea el proyecto y habilita la facturación en la Google Cloud consola si aún no lo has hecho.
Nota sobre Gestión de Identidades y Accesos: el proyecto de implementación contiene tu clúster de GKE. La configuración de Gestión de Identidades y Accesos de este proyecto debe reflejarlo.

Define variables de entorno para almacenar el Google Cloud proyecto y el número:

DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID

Sustituye DEPLOYER_PROJECT_ID por el ID del proyecto. Google Cloud

DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")

Habilita las APIs:

Artifact Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  artifactregistry.googleapis.com\
  binaryauthorization.googleapis.com

Obtén el nombre de la cuenta de servicio del proyecto de implementación:
```
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Usarás el nombre de la cuenta de servicio en un paso posterior al configurar los permisos de la nota de análisis de artefactos asociada a tu attestor.

Configurar el proyecto de attestor

Un proyecto de encargado de la atestación almacena los encargados de la atestación que pueden verificar que una imagen está lista para el despliegue. A menudo, tienes un solo proyecto de attestor que actúa como almacén centralizado de información sobre las partes de confianza en el proceso de autorización. De esta forma, puedes gestionar de forma centralizada las claves de seguridad necesarias para verificar la identidad de los certificadores y restringir el acceso solo a las partes que las administran.

Para configurar el proyecto de attestor, sigue estos pasos:

Crea el proyecto y habilita la facturación en la Google Cloud consola si aún no lo has hecho.
Nota sobre Gestión de Identidades y Accesos: Como este proyecto contiene tus attestors, solo el personal de seguridad debe tener acceso de escritura.

Define variables de entorno para almacenar el ID y el número del proyecto:

ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID

Sustituye ATTESTOR_PROJECT_ID por el ID del proyecto del attestor.

ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")

Habilita las APIs Artifact Analysis y Binary Authorization:

gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Obtén el nombre de la cuenta de servicio del proyecto de encargado de la atestación:
```
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Usarás el nombre de la cuenta de servicio en un paso posterior al configurar los permisos de la nota de análisis de artefactos asociada a tu attestor.

Configurar el proyecto de certificaciones

Un proyecto de atestación es aquel que almacena atestaciones que hacen los atestadores cuando verifican una imagen. Un proyecto de certificación independiente te permite organizar e inspeccionar las declaraciones sobre la preparación del software más fácilmente.

Crea el proyecto y habilita la facturación en la Google Cloud consola si aún no lo has hecho.
Nota sobre Gestión de Identidades y Accesos: Todos los roles implicados en la autorización binaria deben tener acceso de lectura a las notas y las ocurrencias de análisis de artefactos de este proyecto. Sin embargo, solo los gestores de certificaciones necesitan tener acceso de escritura.
Define una variable de entorno para almacenar el nombre del proyecto:
```
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
```
Sustituye ATTESTATION_PROJECT_ID por el ID del proyecto de certificación.

Habilita las APIs Artifact Analysis y Binary Authorization:

gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Crear un clúster

Ahora puedes crear un clúster de GKE en el proyecto de implementación. Este es el clúster en el que quieres que se ejecuten las imágenes de contenedor desplegadas. Cuando crees el clúster, pasa la marca --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE al comando gcloud container clusters create.

Para crear el clúster, siga estos pasos:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    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.

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 --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Crear un encargado de la atestación

Un verificador es una parte responsable de verificar que se ha completado un proceso necesario para que se pueda implementar una imagen de contenedor. Esta parte puede ser un usuario humano o, lo que es más habitual, un proceso de máquina, como un sistema de compilación y prueba, o tus flujos de procesamiento de integración continua (CI) y despliegue continuo (CD). Crea encargados de la atestación en tu proyecto de encargado de la atestación.

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 el proyecto correspondiente y asocia la nota que has creado
Añade un enlace de rol de gestión de identidades y accesos para la cuenta de servicio del proyecto de implementación al attestor
Definir permisos en la nota de análisis de artefactos

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 la imagen.

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.
- test-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/${ATTESTOR_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/${ATTESTOR_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/${ATTESTOR_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 --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors create ${ATTESTOR_NAME} \
    --attestation-authority-note=${NOTE_ID} \
    --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}

Comprueba que se haya creado el encargado de la atestación:

gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors list

El certificador que has creado aún no se puede usar sin un par de claves PKIX asociado, que puedes crear más abajo.

Añadir una vinculación de roles de gestión de identidades y accesos al proyecto de implementación

Debes añadir un enlace de rol de gestión de identidades y accesos para el proyecto de implementación al attestor. La autorización binaria usa este valor cuando evalúa una política para determinar si el proyecto tiene permisos para acceder a las atestaciones asociadas.

Para añadir la vinculación de roles de gestión de identidades y accesos, siga estos pasos:

gcloud --project ${ATTESTOR_PROJECT_ID} \
    container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Definir permisos en la nota de análisis de artefactos

También debe definir permisos en la nota de Artifact Analysis que ha creado para que sea accesible tanto para el proyecto de implementación como para el proyecto de certificador. Para ello, actualiza la política de gestión de identidades y accesos de la nota para asignar acceso de lector a las cuentas de servicio del proyecto.

Genera un archivo JSON que contenga la información necesaria para definir la política de gestión de identidades y accesos en tu nota.

cat > /tmp/iam_request.json << EOM
{
  'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}',
          'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
        ]
      }
    ]
  }
}
EOM

Añade la cuenta de servicio y los roles de acceso solicitados a la política de gestión de identidades y accesos de la nota que has creado:
```
curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
```
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/).

Configurar claves PKIX

Autorización binaria usa claves criptográficas para verificar de forma segura la identidad de los certificadores. De esta forma, solo las partes verificadas pueden participar en la autorización de una imagen de contenedor. El par de claves consta de una clave privada, que usa el attestor para firmar digitalmente las certificaciones, y una clave pública, que añades al attestor tal como la almacena el servicio Autorización binaria.

En este tutorial, usarás el algoritmo de firma digital de curva elíptica (ECDSA) recomendado para crear el par de claves. 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 asimétricas generadas y almacenadas por Cloud Key Management Service (Cloud KMS) cumplen el estándar PKIX. Consulta Crear verificadores mediante la CLI para obtener más información sobre el uso de claves PKIX y Cloud KMS.

Generar un par de claves

Un par de claves PKIX consta de una clave privada, que el firmante usa para firmar digitalmente las certificaciones, y una clave pública, que añades al certificador. En el momento de la implementación, la autorización binaria usa esta clave pública para verificar la certificación firmada por la clave privada.

Genera la clave privada:

Para generar un nuevo par de claves asimétricas PKIX local y almacenarlo en un archivo, haz lo siguiente:
PKIX (Cloud KMS)
En este paso se muestra cómo realizar una certificación mediante claves generadas y almacenadas en Cloud Key Management Service.
1. Configura variables de entorno para almacenar información sobre el par de claves gestionado por Cloud KMS:
  
  Si ya tienes un par de claves, puedes definir estas variables de entorno y saltarte el paso siguiente.
  KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID KMS_KEY_LOCATION=KMS_KEY_LOCATION KMS_KEYRING_NAME=KMS_KEYRING_NAME KMS_KEY_NAME=KMS_KEY_NAME KMS_KEY_VERSION=KMS_KEY_VERSION
  Haz los cambios siguientes:
  - KMS_KEY_PROJECT_ID: el ID del proyecto en el que se almacenan las claves
  - KMS_KEY_LOCATION: la ubicación de la clave
  - KMS_KEYRING_NAME: el nombre del conjunto de claves
  - KMS_KEY_NAME: el nombre de la clave.
  - KMS_KEY_VERSION: la versión de la clave
2. [Opcional] Configura una clave de KMS:
  
  Nota: Puedes saltarte estos pasos si ya tienes una clave de KMS.
  1. Crea una clave de KMS cuya clave pública se pueda almacenar en un attestor. En este paso también se configuran las variables de entorno que se usan más abajo.
    
    Para crear una clave y configurar las variables de entorno, sigue estos pasos:
    
    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
  2. Crea un conjunto de claves de KMS:
    
    gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
  3. Crea la clave:
    
    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} \ --project ${KMS_KEY_PROJECT_ID}
    
    Para obtener más información sobre cómo crear claves de KMS, consulta Crear una clave asimétrica.
3. Añade la clave pública al encargado de la atestación:
  gcloud --project="${ATTESTOR_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}"
PKIX (clave local)

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.
1. Para generar la clave privada, ejecuta los siguientes comandos:
  PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
  PRIVATE_KEY_FILE es el nombre del archivo que contiene la clave privada almacenada en el attestor.
2. Extrae la clave pública de la clave privada y guárdala en un archivo:
  PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
  PUBLIC_KEY_FILE es el nombre del archivo que contiene la clave pública almacenada en el attestor.
3. Para añadir la clave pública que has exportado al encargado de la atestación, ejecuta el siguiente código.
  gcloud --project="${ATTESTOR_PROJECT_ID}" \ container binauthz attestors public-keys add \ --attestor="${ATTESTOR_NAME}" \ --pkix-public-key-file=${PUBLIC_KEY_FILE} \ --pkix-public-key-algorithm=ecdsa-p256-sha256
  La autorización binaria usa la clave pública del attestor para verificar la atestación.

Configurar la política

Ahora, puede configurar su política en el proyecto de implementación. 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 las imágenes del sistema mantenidas por Google, defina el 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/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

Importa el archivo YAML de la política en la autorización binaria:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    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 mediante la CLI.

Probar la política

En este tutorial, crearás una certificación para imágenes públicas de ejemplo de "Hello World!" de Artifact Registry. Al principio, el verificador impide que se desplieguen las imágenes porque no existe la certificación necesaria.

Para intentar desplegar la imagen, sigue estos pasos:

Artifact Registry

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 una declaración de un attestor que indica que se ha completado un proceso obligatorio en tu canalización y que la imagen de contenedor en cuestión está autorizada para la implementación. La propia certificación es un registro firmado digitalmente que contiene la ruta completa a una versión de la imagen tal como se almacena en el registro de imágenes de contenedor, así como la identidad del certificador.

En este tutorial, tu certificación simplemente indica que autorizas la imagen para el despliegue. La atestación se crea en el proyecto de atestación.

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}

Crear la atestación

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 mediante una clave local, haz lo siguiente:

Genera la carga útil de la atestación:

gcloud --project=${ATTESTATION_PROJECT_ID} \
  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:

Artifact Registry

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

Firma la carga útil.

Si usas archivos PKIX locales, firma la carga útil con tu clave privada PKIX local y genera un archivo de firma:
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
El archivo de salida es una versión firmada del archivo JSON de la carga útil que has creado anteriormente.
Obtén el ID de clave pública del encargado de la atestación.

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

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 ${ATTESTOR_PROJECT_ID})
```

Crea y valida la atestación:

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

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 --project=${ATTESTATION_PROJECT_ID} \
    container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_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

Prueba la política desplegando una imagen de contenedor de ejemplo en el clúster. En esta ocasión, debes desplegar la imagen usando el digest en lugar de una etiqueta como 1.0 o latest, ya que la autorización binaria usa el digest para buscar certificaciones. En este caso, la autorización binaria permite que se despliegue la imagen porque tiene una atestación asociada.

Para desplegar 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

Ahora que has desplegado correctamente la imagen de contenedor y has verificado que tu configuración funciona, puedes eliminar el clúster que has creado en GKE:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

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

También puedes eliminar Google Cloud los proyectos que hayas creado para este tutorial.

Configurar varios proyectos Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Objetivos

Costes

Antes de empezar

Configurar el proyecto de implementación

Artifact Registry

Configurar el proyecto de attestor

Configurar el proyecto de certificaciones

Crear un clúster

Crear un encargado de la atestación

Crear la nota de Artifact Analysis

Crear el encargado de la atestación

Añadir una vinculación de roles de gestión de identidades y accesos al proyecto de implementación

Definir permisos en la nota de análisis de artefactos

Configurar claves PKIX

Generar un par de claves

PKIX (Cloud KMS)

PKIX (clave local)

Configurar la política

Probar la política

Artifact Registry

Crear una atestación

Artifact Registry

PKIX Cloud KMS

PKIX (clave local)

Artifact Registry

Volver a probar la política

Limpieza

Siguientes pasos

Configurar varios proyectos