Se usó la API de Cloud Translation para traducir esta página.

Establece una configuración de varios proyectos

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

Para establecer la separación de obligaciones, puedes configurar la autorización binaria en una configuración de varios proyectos. El propósito de cada proyecto se analiza más adelante en este instructivo.

Objetivos

En este instructivo, completarás las siguientes tareas:

Configurar un proyecto diferente para la implementación (GKE), el certificador y la administración de certificación, a fin de admitir la separación de obligaciones.
Configurar la regla predeterminada de la política de la autorización binaria para exigir certificaciones.
Crea un par de claves de infraestructura de clave pública (X.509) (PKIX) para firmar y, luego, verificar la certificación.
Crear un certificador que el ejecutor de la autorización binaria usará para verificar la certificación.
Firmar una imagen de ejemplo con la creación de una certificación.
Implementar la imagen de ejemplo para probar la política.

Debes configurar el control de acceso adecuado de cada proyecto a través de Identity and Access Management (IAM).

A fin de obtener una mayor seguridad, puedes usar Controles del servicio de VPC para proteger mejor los recursos que creas en este instructivo. Para obtener más información, consulta Protege con Controles del servicio de VPC.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios Google Cloud nuevos cumplan con los requisitos para obtener una prueba gratuita.

Antes de comenzar

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.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a gcloud CLI con tu identidad federada.

Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a gcloud CLI con tu identidad federada.

Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

gcloud init

Instala kubectl para interactuar con GKE.

Configura el proyecto de implementador

El proyecto de implementador administra los clústeres de Google Kubernetes Engine (GKE), en los que implementas imágenes, y la política de autorización binaria que aplica la autorización binaria en el momento de la implementación. Puedes tener más de un proyecto de implementador, según el tamaño, la complejidad y otros requisitos de tu entorno.

Para configurar el proyecto de implementación, sigue estos pasos:

Crea el proyecto y habilita la facturación en la Google Cloud consola si aún no lo hiciste.
Nota sobre la administración de identidades y accesos: El proyecto de implementador contiene el clúster de GKE. La configuración de Identity and Access Management de este proyecto debe reflejar eso.

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

DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID

Reemplaza DEPLOYER_PROJECT_ID por el ID del proyecto Google Cloud .

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

Habilita las API:

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 implementador:
```
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 cuando configures los permisos en la nota de Artifact Analysis asociada con tu certificador.

Configura el proyecto del certificador

Un proyecto de certificador almacena los certificadores que pueden verificar que una imagen está lista para la implementación. A menudo, tienes un solo proyecto de certificador que actúa como un almacenamiento centralizado de información sobre las partes de confianza del proceso de autorización. Esto te permite administrar de forma centralizada las llaves de seguridad necesarias para verificar la identidad de los certificadores y restringir el acceso a solo las partes que los administran.

A fin de configurar el proyecto del certificador, sigue estos pasos:

Crea el proyecto y habilita la facturación en la Google Cloud consola si aún no lo hiciste.
Nota sobre la administración de identidades y accesos: Debido a que este proyecto contiene tus certificadores, solo el personal de seguridad debería tener acceso de escritura.

Configura las variables de entorno para almacenar el nombre y el ID del proyecto:

ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID

Reemplaza ATTESTOR_PROJECT_ID por el ID del proyecto de certificador.

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

Habilita las APIs de Artifact Analysis y Autorización Binaria:

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

Obtén el nombre de la cuenta de servicio del proyecto del certificador:
```
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 cuando configures los permisos en la nota de Artifact Analysis asociada con tu certificador.

Configura el proyecto de certificaciones

Un proyecto de certificación es el que almacena las certificaciones que realizan los certificadores cuando verifican una imagen. Un proyecto de certificación diferente te permite inspeccionar y organizar declaraciones sobre la preparación del software con mayor facilidad.

Crea el proyecto y habilita la facturación en la Google Cloud consola si aún no lo hiciste.
Nota sobre la administración de identidades y accesos: Todos los roles involucrados en la Autorización Binaria deben tener acceso de lectura a casos y notas de Artifact Analysis en este proyecto. Sin embargo, solo los administradores de la certificación deben tener acceso de escritura.
Establece una variable de entorno para almacenar el nombre del proyecto:
```
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
```
Reemplaza ATTESTATION_PROJECT_ID por el ID del proyecto de certificación.

Habilita las APIs de Artifact Analysis y Autorización Binaria:

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

Crea un clúster

Ahora puedes crear un clúster de GKE en el proyecto de implementador. Este es el clúster en el que se recomienda que se ejecuten las imágenes de contenedor que implementaste. Cuando creas el clúster, debes pasar la marca --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE al comando gcloud container clusters create.

Para ello, sigue estos pasos:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

Aquí, crearás un clúster llamado test-cluster en la zona de GKE us-central1-a.

También debes actualizar el archivo local kubeconfig de tu instalación de kubectl. Esto proporciona las credenciales y la información del extremo 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

Crea un certificador

Un certificador es una parte responsable de certificar que se completó un proceso obligatorio antes de que se pueda implementar una imagen de contenedor. Esta parte puede ser un usuario humano o, casi siempre, un proceso de máquina, como un sistema de compilación y prueba, o tus canalizaciones de integración continua (CI) e implementación continua (CD). Debes crear certificadores en tu proyecto de certificador.

Para crear un certificador, debes hacer lo siguiente:

Crea una nota en Artifact Analysis para almacenar los metadatos de confianza que se usan en el proceso de autorización.
Crea el certificador en el proyecto de certificador y asocia la nota que creaste.
Agrega una vinculación de función de IAM para la cuenta de servicio del proyecto de implementador al certificador
Establece permisos en la nota de Artifact Analysis

Para este instructivo, debes tener un certificador llamado test-attestor y una nota de Container Analysis llamada test-attestor-note. En una situación real, puedes tener cualquier cantidad de certificadores, cada uno representa a una parte que participa en el proceso de autorización de la imagen.

Crea la nota de Artifact Analysis

Establece las variables que almacenan el nombre del certificador y la nota de Artifact Analysis:
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
Reemplaza lo siguiente:
- test-attestor: Es el nombre del certificador que elijas.
- test-attestor-note: Es el nombre de la nota del certificador 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

Envía una solicitud HTTP a la API de REST de Artifact Analysis para crear la nota:
```
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: autorización binaria no admite el almacenamiento regional ni los extremos regionales de Artifact Analysis. Te recomendamos que uses el extremo de API global de Artifact Analysis (https://containeranalysis.googleapis.com/).

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

Crea el certificador

Ahora, puedes crear el certificador:

Crea el certificador en la 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}

Verifica que se haya creado el certificador:

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

El certificador que creaste aún no se puede usar sin un par de claves PKIX asociado, que puedes crear, a continuación.

Agrega una vinculación de función de IAM para el proyecto de implementador

Debes agregar una vinculación de función de IAM para el proyecto de implementador al certificador. La autorización binaria usa esta vinculación cuando evalúa una política a fin de determinar si el proyecto tiene permisos para acceder a las certificaciones asociadas.

Para agregar la vinculación de función de IAM, sigue 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

Establece permisos en la nota de Artifact Analysis

También debes establecer permisos en la nota de Artifact Analysis que creaste a fin de que sea accesible para el proyecto de implementador y el de certificador. Para ello, actualiza la política de IAM de la nota a fin de asignar el acceso de visualizador a las cuentas de servicio del proyecto.

Genera un archivo JSON que contenga la información necesaria para establecer la política de IAM en la 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

Agrega la cuenta de servicio y las funciones de acceso solicitadas a la política de IAM para la nota que creaste:
```
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: autorización binaria no admite el almacenamiento regional ni los extremos regionales de Artifact Analysis. Te recomendamos que uses el extremo de API global de Artifact Analysis (https://containeranalysis.googleapis.com/).

Configura claves de PKIX

La autorización binaria usa claves criptográficas para verificar de forma segura la identidad de los certificadores. Esto garantiza que solo las partes verificadas puedan participar en la autorización de una imagen de contenedor. El par de claves consta de una clave privada, que el certificador usa para firmar de forma digital las certificaciones, y una clave pública, que se agrega al certificador que almacenó el servicio de autorización binaria.

En este instructivo, usarás el Algoritmo de firma digital de curva elíptica (ECDSA) que se recomienda para crear el par de claves. También puedes usar las claves de RSA o PGP para firmar. Consulta Algoritmos y propósitos de clave para obtener más información sobre los algoritmos de firma.

Las claves asimétricas que Cloud Key Management Service (Cloud KMS) genera y almacena son compatibles con PKIX. Consulta Crea certificadores mediante la CLI para obtener más información sobre el uso de claves de PKIX y Cloud KMS.

Genera un par de claves

Un par de claves de PKIX consta de una clave privada, que el firmante usa para firmar de forma digital las certificaciones, y una clave pública, que agregas al certificador. En el momento de la implementación, la autorización binaria usa esta clave pública para verificar la certificación que firma la clave privada.

Genera la clave privada:

Sigue estos pasos a fin de generar un par nuevo y local de claves de PKIX asimétricas y almacenarlo en un archivo:
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 las variables de entorno para almacenar información sobre el par de claves administradas por Cloud KMS:
  
  Si ya tienes un par de claves, puedes configurar estas variables de entorno y omitir el siguiente paso.
  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
  Reemplaza lo siguiente:
  - KMS_KEY_PROJECT_ID: es el ID del proyecto en el que se almacenan las claves.
  - KMS_KEY_LOCATION: es la ubicación de la clave.
  - KMS_KEYRING_NAME: es el nombre del llavero de claves.
  - KMS_KEY_NAME: el nombre de la clave.
  - KMS_KEY_VERSION: es la versión de la clave.
2. Configura una clave de KMS (opcional):
  Nota: Puedes omitir estos pasos si ya tienes una clave de KMS.
  1. Crea una clave de KMS cuya clave pública se pueda almacenar en un certificador. En este paso, también se configuran las variables de entorno que usarás a continuación.
    
    Sigue estos pasos para crear una clave y configurar las variables de entorno:
    
    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 llavero 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 Crea una clave asimétrica.
3. Agrega la clave pública al certificador:
  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: Recomendamos que no uses pares de claves generados localmente en entornos de producción, ya que presentan un riesgo de seguridad. Te recomendamos que, en cambio, uses Cloud Key Management Service. Este ejemplo se proporciona solo 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 que se almacena en el certificador.
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 que se almacena en el certificador.
3. Para agregar la clave pública que exportaste al certificador, 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
  Autorización Binaria usa la clave pública del certificador para verificar la certificación.

Configura la política

Ahora, puedes configurar la política en el proyecto de implementador. En este paso, exportarás el archivo YAML de la política a tu sistema local y modificarás la regla predeterminada para que necesite una certificación del certificador que definiste antes.

Para configurar la política, sigue estos pasos:

Crea un archivo de política nuevo que permita imágenes del sistema mantenidas por Google, establece el evaluationMode en REQUIRE_ATTESTATION y agrega un nodo llamado requireAttestationsBy que hace referencia al certificador que creaste:

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 política a 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 Configura una política mediante la CLI.

Prueba la política

En este instructivo, crearás una certificación, por ejemplo, imágenes públicas de “Hello World!” de Artifact Registry. Inicialmente, el ejecutor bloquea la implementación de las imágenes porque la certificación necesaria no existe.

Para intentar implementar 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, verifica que la autorización binaria haya bloqueado la implementación:

kubectl get pods

El comando imprime el siguiente mensaje, que indica que la imagen no se implementó:

No resources found.

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

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

Verás 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, se ilustra lo siguiente:

POD_NAME: Es el nombre del Pod.
IMAGE_NAME: Es el nombre de la imagen.
ATTESTOR_NAME: Es el nombre del certificador.

Asegúrate de borrar la implementación para poder continuar con el siguiente paso:

kubectl delete deployment hello-server

Crea una certificación

Una certificación es una declaración de un certificador que constata que se completó un proceso necesario en tu canalización y que la imagen de contenedor en cuestión está autorizada para la implementación. La certificación es un registro firmado de forma digital que contiene la ruta completa a una versión de la imagen almacenada en el registro de imágenes de contenedor, así como la identidad del certificador.

En este instructivo, tu certificación solo indica que autorizas la implementación de la imagen. Crearás la certificación en el proyecto de certificación.

Para crear una certificación, sigue estos pasos:

Configura las variables que almacenen la ruta de registro y el resumen 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}

Crea la certificació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 con una clave local, haz lo siguiente:

Genera la carga útil de la certificación:

gcloud --project=${ATTESTATION_PROJECT_ID} \
  container binauthz create-signature-payload \
  --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

El archivo JSON de 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 de 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 carga útil que creaste antes.
Obtén el ID de la clave pública del certificador.

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

Para guardar tu ID de clave pública en una variable de entorno, ingresa el siguiente 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 certificació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 el certificador que configuraste en la política pueda verificar la certificación.

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 Crea certificaciones.

Vuelve a probar la política

Prueba la política mediante la implementación de una imagen de contenedor de muestra en el clúster. Esta vez, debes implementar la imagen con el resumen en lugar de una etiqueta, como 1.0 o latest, ya que la autorización binaria usa el resumen para buscar certificaciones. Aquí, la autorización binaria permite implementar la imagen, ya que tiene una certificación asociada.

Para implementar la imagen, ejecuta el siguiente comando:

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

Para verificar que se implementó la imagen, sigue estos pasos:

kubectl get pods

El comando imprime un mensaje similar al siguiente, que indica que la implementación se realizó de forma correcta:

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

Ahora que implementaste de forma correcta la imagen de contenedor y verificaste que la configuración funciona, puedes borrar el clúster que creaste en GKE:

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

Libera espacio

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra el clúster que creaste en GKE:

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

También puedes borrar Google Cloud los proyectos que creaste para este instructivo.

Establece una configuración de varios proyectos Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Objetivos

Costos

Antes de comenzar

Configura el proyecto de implementador

Artifact Registry

Configura el proyecto del certificador

Configura el proyecto de certificaciones

Crea un clúster

Crea un certificador

Crea la nota de Artifact Analysis

Crea el certificador

Agrega una vinculación de función de IAM para el proyecto de implementador

Establece permisos en la nota de Artifact Analysis

Configura claves de PKIX

Genera un par de claves

PKIX (Cloud KMS)

PKIX (clave local)

Configura la política

Prueba la política

Artifact Registry

Crea una certificación

Artifact Registry

PKIX (Cloud KMS)

PKIX (clave local)

Artifact Registry

Vuelve a probar la política

Libera espacio

¿Qué sigue?

Establece una configuración de varios proyectos