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:

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

  2. Configurar la regla predeterminada de la política de la autorización binaria para exigir certificaciones.

  3. Crear un par de claves de infraestructura de clave pública (X.509) (PKIX) para firmar y, luego, verificar la certificación

  4. Crear un certificador que el ejecutor de la autorización binaria usará para verificar la certificación.

  5. Firmar una imagen de ejemplo con la creación de una certificación.

  6. 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 nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Antes de comenzar

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

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

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

  5. To initialize the gcloud CLI, run the following command: 

    gcloud init

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

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Install the Google Cloud CLI.

  9. To initialize the gcloud CLI, run the following command: 

    gcloud init
  10. 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:

  1. Crea el proyecto y habilita la facturación en la consola de Google Cloud si aún no lo hiciste.

  2. 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.

  3. 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)")

  4. 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

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

  1. Crea el proyecto y habilita la facturación en la consola de Google Cloud si aún no lo hiciste.

  2. 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.

  3. 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)")

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

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

  5. 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.

  1. Crea el proyecto y habilita la facturación en la consola de Google Cloud si aún no lo hiciste.

  2. 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.

  3. 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.

  4. 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

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

  2. 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

  3. 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}"

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

  1. 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}

  2. 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.

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

  2. 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.

  1. 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):

      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)

    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:

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

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

  1. 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}

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

    1. 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"
}
}

    2. 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.

    3. 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})

    4. 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.

  3. 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.

  1. Borra el clúster que creaste en GKE:

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

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

¿Qué sigue?