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

Crear encargados de la atestación con la CLI de gcloud

En esta página se explica cómo crear un attestor en Autorización binaria mediante la CLI de Google Cloud. También puedes seguir estos pasos con la Google Cloud consola o la API REST. Esta tarea forma parte de la configuración de la autorización binaria.

Usuarios de Cloud Build: pueden usar el built-by-cloud-build attestor para desplegar solo imágenes creadas por Cloud Build.

Un confirmador es un recurso que la autorización binaria usa para verificar una confirmación.Google Cloud Para obtener más información sobre las certificaciones, consulta la descripción general de la autorización binaria.

Para crear un attestor, sigue estos pasos:

Crea una nota en Artifact Analysis para almacenar los metadatos de confianza que se usan en el proceso de certificación.
Configura un par de claves de infraestructura de clave pública (X.509) (PKIX) que se pueda usar para verificar la identidad del attestor. Los pares de claves asimétricas generados por Cloud Key Management Service (Cloud KMS) tienen un formato compatible con PKIX.
Crea el attestor en Binary Authorization y asocia la nota y la clave pública que has creado.

En una configuración de un solo proyecto, creas el encargado de la atestación en el mismo Google Cloud proyecto en el que configuras tu política de autorización binaria. Para ver un tutorial completo de un solo proyecto que incluya estos pasos, consulta Empezar a usar la CLI de Google Cloud o Empezar a usar la consola de Google Cloud Google Cloud.

En una configuración de varios proyectos, te recomendamos que tengas proyectos independientes: un proyecto de implementación, donde se configura tu política; un proyecto de certificador, donde se almacenan tus certificadores; y un proyecto de certificación para las certificaciones. Para ver un tutorial completo sobre cómo configurar varios proyectos que incluye estos pasos, consulta el artículo sobre la configuración de varios proyectos.

Antes de empezar

Antes de crear verificadores, haz lo siguiente:

Configurar el entorno del proyecto

En esta sección, se configuran las variables de entorno.

Configura variables de entorno para almacenar los nombres y números de tus proyectos. Si los proyectos de attestor y deployer son el mismo, usa el mismo ID de proyecto para ambas variables.

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

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

También debe obtener los nombres de las cuentas de servicio de los proyectos:

DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

Crear una nota de Artifact Analysis

La autorización binaria utiliza Artifact Analysis para almacenar metadatos de confianza que se usan en el proceso de autorización. Por cada attestor que cree, debe crear una nota de Artifact Analysis. Cada atestación se almacena como una ocurrencia de esta nota.

Para crear la nota, sigue estos pasos:

Configura variables de entorno para almacenar el ID de la nota y una descripción legible por humanos:
```
NOTE_ID=NOTE_ID
NOTE_URI="projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
DESCRIPTION=DESCRIPTION
```
Haz los cambios siguientes:
- NOTE_ID: nombre interno de la nota en caracteres alfanuméricos sin espacios (por ejemplo, test-attestor-note).
- NOTE_URI: la ruta completa al recurso de la nota
- DESCRIPTION: nombre visible legible por humanos de la nota (por ejemplo, Test Attestor Note).

En un editor de texto, crea un archivo JSON que describa la nota:

cat > /tmp/note_payload.json << EOM
{
  "name": "${NOTE_URI}",
  "attestation": {
    "hint": {
      "human_readable_name": "${DESCRIPTION}"
    }
  }
}
EOM

Crea la nota enviando 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)"  \
    -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
    --data-binary @/tmp/note_payload.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Para verificar que la nota se ha creado correctamente, ejecuta el siguiente comando:

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/"

Definir permisos de gestión de identidades y accesos en la nota

Debes asignar un rol de Gestión de Identidades y Accesos (IAM) a la cuenta de servicio del proyecto de attestor en el recurso de nota de Artifact Analysis. Para ello, añade la cuenta de servicio del proyecto del attestor al rol containeranalysis.notes.occurrences.viewer en la política de gestión de identidades y accesos de la nota.

Para añadir el rol, sigue estos pasos:

Genera un archivo JSON que contenga la información necesaria para definir el rol de gestión de identidades y accesos en tu nota:

cat > /tmp/iam_request.json << EOM
{
  "resource": "${NOTE_URI}",
  "policy": {
    "bindings": [
      {
        "role": "roles/containeranalysis.notes.occurrences.viewer",
        "members": [
          "serviceAccount:${ATTESTOR_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)" \
    -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
```
Nota: Cuando añades un rol a la política con el método anterior, se sustituyen los roles que ya tenga la nota. Si quieres conservar los roles que ya tienes, asegúrate de incluirlos en el archivo de datos JSON anterior.

Uso multiproyecto

Si almacenas el attestor en un proyecto y lo implementas en otro, debes asignar el rol roles/binaryauthorization.attestorsVerifier a la cuenta de servicio asociada al proyecto de implementación en el attestor.

Configurar claves criptográficas

La autorización binaria te permite usar claves PKIX para verificar atestaciones.

Generar un par de claves

En esta guía, se usa el algoritmo de firma digital de curva elíptica (ECDSA) recomendado para generar un par de claves PKIX. También puedes usar pares de claves RSA o PGP. Consulta Propósitos y algoritmos de claves para obtener más información sobre los algoritmos de firma.

Un par de claves PKIX incluye una clave privada que los signatarios usan para firmar las certificaciones y una clave pública que añades al certificador. En el momento de la implementación, Autorización Binaria usa esta clave pública para verificar la atestación.

PKIX (Cloud KMS)

Para crear el par de claves en Cloud KMS, sigue estos pasos:

Para configurar las variables de entorno necesarias para crear el par de claves, ejecuta los siguientes comandos:
```
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
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=KMS_KEY_ALGORITHM
KMS_PROTECTION_LEVEL=KMS_PROTECTION_LEVEL
```
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
- KMS_KEY_ALGORITHM: el algoritmo; ec-sign-p256-sha256 es la opción recomendada
- KMS_PROTECTION_LEVEL: el nivel de protección (por ejemplo, software)

Para crear el conjunto de claves, ejecuta el siguiente comando:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
    --location ${KMS_KEY_LOCATION}

Para crear la clave, ejecuta el siguiente comando:
```
gcloud kms keys create ${KMS_KEY_NAME} \
    --location ${KMS_KEY_LOCATION} \
    --keyring ${KMS_KEYRING_NAME}  \
    --purpose ${KMS_KEY_PURPOSE} \
    --default-algorithm ${KMS_KEY_ALGORITHM} \
    --protection-level ${KMS_PROTECTION_LEVEL}
```
Haz los cambios siguientes:
- KMS_KEY_NAME: el nombre de la clave.
- KMS_KEY_LOCATION: la ubicación de la clave
- KMS_KEYRING_NAME: el nombre del conjunto de claves
- KMS_KEY_PURPOSE: el propósito de la clave, que debe ser ASYMMETRIC_SIGN
- KMS_KEY_ALGORITHM: el algoritmo, ec-sign-p256-sha256 es recomendable
- KMS_PROTECTION_LEVEL: el nivel de protección (por ejemplo, software)

PKIX (clave local)

Para generar un nuevo par de claves asimétricas PKIX local y almacenarlo en un archivo, haz lo siguiente:

Genera la clave privada:

PRIVATE_KEY_FILE es el nombre del archivo que contiene la clave privada utilizada para firmar la carga útil de la certificación.
```
PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
```
Extrae la clave pública de la clave privada y guárdala en un archivo:

PUBLIC_KEY_FILE es el nombre del archivo que contiene la clave pública almacenada en el attestor.
```
PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
```

Crear el encargado de la atestación

Para crear el attestor, sigue estos pasos:

Configura una variable de entorno para almacenar el nombre del attestor tal como se define en Autorización binaria:
```
ATTESTOR_NAME=ATTESTOR_NAME
```
donde ATTESTOR_NAME es el nombre del attestor que quieres crear (por ejemplo, build-secure o prod-qa).

Crea el recurso de 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}"

Añade una vinculación de roles de gestión de identidades y accesos para el proyecto de implementación al encargado de la atestación. La autorización binaria la usa cuando evalúa una política para determinar si el proyecto tiene permisos para acceder a las atestaciones asociadas.
```
gcloud container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier
```
Para añadir la clave pública al attestor, haz lo siguiente:
PKIX (Cloud KMS)
Para añadir la clave pública de un par de claves de Cloud KMS al verificador, ejecuta el siguiente comando:
```
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 añadir una clave pública PKIX almacenada localmente a un attestor, ejecuta el siguiente comando:
```
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
```
Si añade una clave pública a un attestor y no especifica un ID de clave (que puede ser cualquier cadena), se le asignará automáticamente uno con el formato RFC 6920: ni:///sha-256;..., donde ... es un hash codificado de la clave pública. Este valor se devuelve en el campo id de la salida del comando. El ID devuelto se puede guardar en PUBLIC_KEY_ID y se puede usar para crear una certificación.

Guarda el ID de la clave pública

Para crear una certificación, necesitas el ID de la clave pública.

Para guardar el ID de la clave pública, puedes copiarlo de la salida del comando binauthz attestors public-keys add anterior.

También puedes ver el ID de la clave pública de tu attestor en cualquier momento con el siguiente comando:

gcloud container binauthz attestors describe ${ATTESTOR}.

Para guardar el ID de tu clave pública en una variable de entorno, introduce el siguiente comando:

PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)')

Verificar que se ha creado el encargado de la atestación

Para verificar que se ha creado el attestor, ejecuta el siguiente comando:

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

Siguientes pasos

Consulta cómo crear certificaciones para tu certificador.
Actualiza tu política de autorización binaria para requerir certificaciones mediante la Google Cloud consola, la CLI de Google Cloud y la API REST.

Crear encargados de la atestación con la CLI de gcloud Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Configurar el entorno del proyecto

Crear una nota de Artifact Analysis

Definir permisos de gestión de identidades y accesos en la nota

Uso multiproyecto

Configurar claves criptográficas

Generar un par de claves

PKIX (Cloud KMS)

PKIX (clave local)

Crear el encargado de la atestación

PKIX (Cloud KMS)

PKIX (clave local)

Guarda el ID de la clave pública

Verificar que se ha creado el encargado de la atestación

Siguientes pasos

Crear encargados de la atestación con la CLI de gcloud