Conceptos de Autorización binaria

Esta página contiene información sobre conceptos relacionados con la autorización binaria.

Políticas

Una política de autorización binaria, también conocida como política de un solo proyecto, es un conjunto de reglas que rigen el despliegue de imágenes de contenedor.

La validación continua usa un tipo de política diferente, llamada política de plataforma.

Una política consta de las siguientes partes:

• Reglas de despliegue
• Lista de imágenes exentas

Puede configurar una política de una de las siguientes formas:

• Google Cloud consola
• Comandos de gcloud

Cuando usas comandos gcloud, exportas y modificas una definición de la política en formato YAML antes de volver a importarla a tu proyecto. El formato YAML refleja la estructura interna de una política en el almacenamiento de autorización binaria. Para obtener más información sobre este formato, consulta la referencia de las políticas en YAML.

Cada Google Cloud proyecto puede tener exactamente una política. Debes configurar la política en el proyecto en el que ejecutes tu plataforma de implementación. En una configuración de un solo proyecto, la política y todos los recursos subordinados (attestors y attestations) se encuentran en el mismo proyecto. Para establecer la separación de funciones, puedes usar una configuración de varios proyectos. En esta configuración, la plataforma de implementación puede ejecutarse en un proyecto, los verificadores pueden residir en otro proyecto y las certificaciones pueden residir en otro proyecto.

Para configurar y usar la autorización binaria en plataformas compatibles, consulta Configuración por plataforma.

Consulta un ejemplo de configuración de varios proyectos para GKE.

Reglas

Cuando configuras una política, defines sus reglas. Las reglas definen las restricciones que deben cumplir las imágenes para poder desplegarse. Una política tiene una regla predeterminada y puede tener reglas específicas, según la plataforma. Para obtener más información, consulta Tipos de reglas admitidos por plataforma.

Cada regla se puede configurar con un modo de evaluación y un modo de aplicación. Por ejemplo, una regla puede requerir que una imagen tenga una atestación firmada para poder desplegarse.

Regla predeterminada

Cada política tiene una regla predeterminada. Esta regla se aplica a cualquier solicitud de implementación que no coincida con una regla específica. En un archivo YAML de una política, la regla predeterminada se especifica en el nodo defaultAdmissionRule.

Para obtener más información sobre cómo configurar la regla predeterminada, consulta Configurar una política.

Reglas específicas

Se pueden añadir una o varias reglas específicas a una política. Este tipo de regla se aplica a las imágenes que se van a implementar en clústeres, cuentas de servicio o identidades específicos. La compatibilidad con reglas específicas varía en función de la plataforma. Para obtener más información, consulta Tipos de reglas admitidos por plataforma.

En un archivo YAML de una política, cada regla específica de un clúster se especifica en un nodo clusterAdmissionRule.

Tipos de reglas admitidos por plataforma

En la siguiente tabla se muestran los tipos de reglas que se admiten en cada plataforma de implementación.

Modos de evaluación

Cada regla tiene un modo de evaluación que especifica el tipo de restricción que Binary Authorization aplica a la regla. El modo de evaluación de una regla se especifica mediante la propiedad evaluationMode en el archivo YAML de la política.

Hay tres modos de evaluación:

• Permitir todas las imágenes: permite que se implementen todas las imágenes.
• No permitir todas las imágenes: no permite que se implementen todas las imágenes.
• Requerir atestaciones: requiere que un firmante firme digitalmente el resumen de la imagen y cree una atestación antes de la implementación. En el momento de la implementación, el verificador de la autorización binaria usa un encargado de la atestación para verificar la firma de la atestación antes de implementar la imagen asociada.

Modos de cumplimiento

Cada regla también tiene un modo de aplicación, que especifica la acción que lleva a cabo GKE cuando una imagen no cumple la regla. Una regla puede tener los siguientes modos de aplicación:

• Bloquear y registrar: bloquea la implementación de imágenes que no cumplen la regla y escribe un mensaje en el registro de auditoría para indicar por qué no se ha implementado la imagen.

• Prueba: solo registro de auditoría: el modo de prueba es un modo de cumplimiento de una política que permite desplegar imágenes no conformes, pero escribe detalles sobre el despliegue en los registros de auditoría de Cloud. El modo de prueba permite probar una política, por ejemplo, en tu entorno de producción, antes de que se aplique.

La mayoría de las reglas de producción usan el modo de aplicación Bloquear y registrar auditoría. Prueba: solo registro de auditoría se usa principalmente para probar una política en tu entorno antes de que entre en vigor.

El modo de cumplimiento de una regla se especifica mediante la propiedad enforcementMode en el archivo YAML de la política.

Consulta Ver registros de auditoría (GKE, Google Distributed Cloud y Cloud Service Mesh) o Ver registros de auditoría (Cloud Run) para obtener más información sobre los mensajes escritos en Registros de auditoría de Cloud.

Validación continua

La validación continua es una función de la autorización binaria que comprueba periódicamente las imágenes asociadas a los pods en ejecución para verificar que siguen cumpliendo las políticas.

Más información sobre el CV

Imágenes exentas

Una imagen exenta es una imagen que no está sujeta a las reglas de las políticas. La autorización binaria siempre permite que se desplieguen las imágenes exentas. Cada proyecto tiene una lista de imágenes exentas especificadas por la ruta del registro. Las imágenes de las rutas gcr.io/google_containers/* y k8s.gcr.io/**, así como de otras rutas, están exentas de forma predeterminada, ya que contienen recursos necesarios para que GKE pueda iniciar un clúster correctamente con la política predeterminada activa.

Para añadir una imagen exenta a la lista de permitidas, añade lo siguiente al archivo de políticas:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Sustituye EXEMPT_IMAGE_PATH por la ruta de la imagen que quieras excluir. Para excluir más imágenes, añada más entradas - namePattern. Consulta más información sobre admissionWhitelistPatterns.

Patrones de la lista de permitidos

Para incluir en la lista de permitidas todas las imágenes cuya ubicación de registro coincida con la ruta especificada, haz lo siguiente:

gcr.io/example-project/*

Para incluir en la lista de permitidos todas las imágenes cuya ubicación de registro sea cualquier subdirectorio de la ruta especificada (por ejemplo, gcr.io/example-project/my-directory/helloworld):

gcr.io/example-project/**

Para añadir una imagen específica a la lista de permitidas, sigue estos pasos:

gcr.io/example-project/helloworld

Para incluir en una lista de permitidas una versión específica de una imagen por etiqueta, sigue estos pasos:

gcr.io/example-project/helloworld:latest
gcr.io/example-project/helloworld:my-tag

Para incluir en la lista de permitidas todas las versiones y etiquetas de una imagen, sigue estos pasos:

gcr.io/example-project/helloworld@*

Para incluir en la lista de permitidas una versión específica de una imagen por su digest:

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

Consulta más información sobre cómo usar resúmenes de imágenes de contenedor.

Consulta cómo gestionar las imágenes exentas en la consola deGoogle Cloud , con la herramienta de línea de comandos o con la API REST.

Imágenes del sistema mantenidas por Google

La opción Confiar en todas las imágenes del sistema mantenidas por Google hace que la autorización binaria excluya una lista de imágenes del sistema mantenidas por Google de la evaluación de políticas. Si tienes habilitado este ajuste, las imágenes que requiere GKE no se bloquearán por la aplicación de la política. La política del sistema se evalúa antes y además de la política de usuario.

Puedes habilitar o inhabilitar este ajuste mediante la propiedad globalPolicyEvaluationMode en el archivo YAML de la política. Puedes ver el contenido de la política del sistema con el siguiente comando:

gcloud alpha container binauthz policy export-system-policy

Atestaciones

Una atestación es un documento digital que certifica una imagen. Durante el despliegue, la autorización binaria verifica la atestación antes de permitir que se despliegue la imagen.

El proceso de creación de una certificación a veces se denomina firma de una imagen. Una certificación se crea después de compilar una imagen. Cada imagen de este tipo tiene una síntesis única a nivel global. Un firmante firma el resumen de la imagen con una clave privada de un par de claves y usa la firma para crear la certificación. En el momento de la implementación, el verificador de Binary Authorization usa la clave pública del attestor para verificar la firma de la certificación. Normalmente, un verificador corresponde exactamente a un firmante.

Una certificación significa que la imagen asociada se ha creado ejecutando correctamente un proceso específico y obligatorio. Por ejemplo, si el firmante es un representante de tu función de control de calidad, la certificación puede indicar que la imagen ha superado todas las pruebas funcionales integrales necesarias en un entorno de preproducción.

Para habilitar las atestaciones en la autorización binaria, el valor de evaluationMode de tu política debe ser REQUIRE_ATTESTATION.

Consulta cómo crear y usar verificadores y verificaciones.

Firmantes

Un firmante es una persona o un proceso automatizado que crea una atestación firmando un descriptor de imagen único con una clave privada. La atestación se verifica en el momento de la implementación mediante la clave pública correspondiente almacenada en un encargado de la atestación antes de que se implemente la imagen asociada.

Consulta cómo crear y usar verificadores y verificaciones.

Encargados de la atestación

Un encargado de la atestación es un recurso que utiliza la autorización binaria para verificar la atestación en el momento del despliegue de la imagen. Google Cloud Los certificadores contienen la clave pública que corresponde a la clave privada utilizada por un firmante para firmar el resumen de la imagen y crear la certificación. El verificador de la autorización binaria usa el attestor en el momento del despliegue para limitar las imágenes que se pueden desplegar a aquellas que tengan una atestación verificable creada antes del despliegue.

Los certificadores suelen estar gestionados por personal de operaciones de seguridad que también gestiona los pares de claves públicas y privadas, mientras que los firmantes suelen ser ingenieros de software o personal de control de calidad o cumplimiento de DevOps responsables de producir imágenes desplegables, firmarlas con la clave privada y crear las certificaciones antes de intentar desplegarlas.

Los encargados de la atestación tienen lo siguiente:

• Una nota de Artifact Analysis correspondiente
• Una o varias claves públicas criptográficas que corresponden a la clave privada que el firmante ha usado para crear una certificación.

Cuando configures una política que contenga una regla Require Attestations (Requerir certificaciones), debes añadir un certificador por cada persona o proceso que deba verificar que la imagen está lista para el despliegue. Puedes añadir certificadores mediante la consola, la interfaz de gcloud o la API REST de Binary Authorization. Google Cloud

Consulta cómo crear y usar verificadores y verificaciones.

Claves criptográficas

La autorización binaria usa firmas digitales para verificar las imágenes en el momento del despliegue cuando la política contiene una regla Require Attestations (Requerir atestaciones).

Se genera un par de claves. El firmante usa la clave privada para firmar un descriptor de imagen. Se crea una atestación.

A continuación, se crea un verificador y se almacena en la política. La clave pública que corresponde a la clave privada utilizada para la firma se sube y se adjunta al attestor.

Cuando se intenta desplegar una imagen, la autorización binaria usa atestadores en la política para verificar las atestaciones de la imagen. Si se puede verificar la certificación, se implementa la imagen.

La autorización binaria admite dos tipos de claves:

• Infraestructura de clave pública (X.509) (PKIX)
• PGP

Las claves PKIX se pueden almacenar de forma local, externa o en Cloud Key Management Service.

Crea una clave criptográfica y un attestor.

Notas 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 instancia de esta nota.

Cuando la autorización binaria evalúa una regla que requiere que los certificadores hayan verificado una imagen, comprueba el almacenamiento de Artifact Analysis para ver si están presentes las certificaciones necesarias.