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.
Crear un par de claves 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:
- Artifact Registry or Container Registry
- Binary Authorization
- GKE
- Container Registry
- Optional: Cloud Key Management Service
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Antes de comenzar
- Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
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 consola de Google Cloud 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 de Google Cloud.
DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \ --format="value(projectNumber)")
Habilita las API:
Container Registry
gcloud --project=${DEPLOYER_PROJECT_ID} \ services enable\ container.googleapis.com\ containerregistry.googleapis.com\ binaryauthorization.googleapis.com
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 consola de Google Cloud 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 consola de Google Cloud 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}"
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"
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.
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.
Configura una clave de KMS (opcional):
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
Crea un llavero de claves de KMS.
gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
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.
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)
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.
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.
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
enREQUIRE_ATTESTATION
y agrega un nodo llamadorequireAttestationsBy
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 Container Registry y 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:
Container Registry
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
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:
Container Registry
IMAGE_PATH="gcr.io/google-samples/hello-app" IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
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:
Container Registry
{ "critical": { "identity": { "docker-reference": "gcr.io/google-samples/hello-app" }, "image": { "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea 882eb722c3be4" }, "type": "Google cloud binauthz container signature" } }
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
Limpia
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 los proyectos de Google Cloud que creaste para este instructivo.