En esta página, se incluye información sobre conceptos fundamentales relacionados con Autorización Binaria.
Políticas
Una política de Autorización Binaria, también conocida como política singleton de proyecto, es un conjunto de reglas que rigen la implementación de imágenes de contenedor.
La validación continua (CV) usa un tipo diferente de política, llamada política de plataforma.
Una política está compuesta por las siguientes partes:
- Reglas de implementación
- Lista de imágenes exentas
Puedes configurar una política mediante una de las siguientes opciones:
- Consola de Google Cloud
- Comandos
gcloud
Cuando usas comandos de 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 la autorización binaria.
Para obtener más información sobre este formato, consulta la Referencia sobre las políticas en formato YAML.
Cada proyecto de Google Cloud puede tener exactamente una política. Debes configurar la política en el proyecto en el que ejecutas la plataforma de implementación. En una configuración de un solo proyecto, la política y todos los recursos subordinados (certificadores y certificaciones) residen en el mismo proyecto. Para establecer la separación de obligaciones, puedes usar una configuración de varios proyectos. En esta configuración, la plataforma de implementación puede ejecutarse en un proyecto, los certificadores pueden residir en otro proyecto y las certificaciones pueden estar en otro proyecto.
Para configurar y usar la autorización binaria en plataformas compatibles, consulta Configura por plataforma.
Consulta un ejemplo de una configuración de varios proyectos para GKE.
Reglas
Cuando configuras una política, debes definir sus reglas. Las reglas definen restricciones que las imágenes deben satisfacer antes de que se puedan implementar. Una política tiene una regla predeterminada y puede tener reglas específicas, según la plataforma. Para obtener más información, consulta los Tipos de reglas compatibles 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 certificación firmada antes de que se pueda implementar.
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 política, la regla predeterminada se especifica en el nodo defaultAdmissionRule.
Para obtener más información sobre la configuración de la regla predeterminada, consulta Configura una política.
Reglas específicas
Se pueden agregar una o más reglas específicas a una política. Este tipo de regla se aplica a las imágenes que se implementan en clústeres, cuentas de servicio o identidades específicos. La compatibilidad con reglas específicas varía según la plataforma. Para obtener más información, consulta los Tipos de reglas compatibles por plataforma.
En un archivo YAML de política, cada regla específica del clúster se especifica en un nodo clusterAdmissionRule.
Tipos de reglas compatibles por plataforma
En la siguiente tabla, se muestran los tipos de reglas que se admiten para cada plataforma de implementación.
| Plataforma | Regla predeterminada | Regla específica |
|---|---|---|
| GKE | Admitido | Clústeres Espacios de nombres de Kubernetes Cuentas de servicio de Kubernetes |
| Cloud Run | Admitido | No compatible |
| Clústeres conectados de GKE | Admitido | Clústeres Espacios de nombres de Kubernetes Cuentas de servicio de Kubernetes |
| GKE en AWS | Admitido | Clústeres Espacios de nombres de Kubernetes Cuentas de servicio de Kubernetes |
| GKE en Bare Metal | Admitido | Clústeres Espacios de nombres de Kubernetes Cuentas de servicio de Kubernetes |
| GKE en VMware | Admitido | Clústeres Espacios de nombres de Kubernetes Cuentas de servicio de Kubernetes |
| Cloud Service Mesh | Admitido | Identidades del servicio de Cloud Service Mesh |
Modos de evaluación
Cada regla tiene un modo de evaluación que especifica el tipo de restricción que la autorización binaria aplica a la regla. El modo de evaluación de una regla se especifica mediante la propiedad evaluationMode en el archivo YAML de política.
Existen tres modos de evaluación:
- Permitir todas las imágenes: Permite que se implementen todas las imágenes.
- Inhabilitar todas las imágenes: No permite que se implementen todas las imágenes.
- Solicitar certificaciones: Requiere que un firmante firme de forma digital el resumen de la imagen y cree una certificación antes de la implementación. En el momento de la implementación, el ejecutor de la autorización binaria usa un certificador para verificar la firma en la certificación antes de implementar la imagen asociada.
Modos de aplicación
Cada regla también tiene un modo de aplicación, que especifica la acción que realiza GKE cuando una imagen no cumple con la regla. Una regla puede tener los siguientes modos de aplicación:
Bloqueo y registro de auditoría: Se bloquea la implementación de imágenes que no cumplen con la regla y se escribe un mensaje en el registro de auditoría para indicar por qué no se implementó la imagen.
Ejecución de prueba: Solo para el registro de auditoría: El modo de ejecución de prueba es un modo de aplicación en una política que permite que se implementen imágenes que no cumplen con las especificaciones, pero se escriben detalles sobre la implementación en los Registros de auditoría de Cloud. El modo de ejecución de prueba te permite probar una política, por ejemplo, en tu entorno de producción, antes de que la aplicación entre en vigencia.
La mayoría de las reglas de producción usan el modo de aplicación Bloqueo y registro de auditoría. Por lo general, la Ejecución de prueba: Solo para el registro de auditoría se usa a fin de probar una política en tu entorno antes de que entre en vigor.
El modo de aplicación de una regla se especifica mediante la propiedad enforcementMode en el archivo YAML de la política.
Consulta Visualiza los registros de auditoría (GKE, clústeres de GKE, Cloud Service Mesh) o Visualiza los registros de auditoría (Cloud Run) para obtener más información sobre los mensajes escritos en los Registros de auditoría de Cloud.
Validación continua
La validación continua (CV) es una función de la autorización binaria que verifica de forma periódica las imágenes asociadas con los Pods en ejecución para garantizar el cumplimiento continuo de las políticas.
Obtén más información sobre la CV.
Imágenes exentas
Una imagen exenta es una imagen que está exenta de las reglas de política.
La autorización binaria siempre permite que se implementen imágenes exentas Cada proyecto tiene una lista de imágenes exentas admitidas que la ruta de registro específica. De forma predeterminada, las imágenes en la ruta gcr.io/google_containers/*, k8s.gcr.io/** y las rutas adicionales están exentas, ya que contienen los recursos necesarios para que GKE pueda iniciar un clúster de manera correcta con la política predeterminada activa.
Para agregar una imagen exenta a la lista de entidades permitidas, agrega lo siguiente al archivo de políticas:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Reemplaza EXEMPT_IMAGE_PATH por la ruta de acceso a la imagen que se exime. Para eximir imágenes adicionales, agrega entradas - namePattern adicionales. Obtén más información sobre admissionWhitelistPatterns.
Patrones de la lista de entidades permitidas
Para incluir en la lista de entidades permitidas todas las imágenes cuya ubicación de registro coincida con la ruta especificada, sigue estos pasos:
gcr.io/example-project/*
Para incluir en la lista de entidades permitidas todas las imágenes cuya ubicación de registro es cualquier subdirectorio de la ruta de acceso especificada (p. ej., gcr.io/example-project/my-directory/helloworld), haz lo siguiente:
gcr.io/example-project/**
Para incluir una imagen específica en la lista de entidades permitidas, haz lo siguiente:
gcr.io/example-project/helloworld
Para incluir en la lista de entidades 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 entidades permitidas todas las versiones o etiquetas de una imagen, haz lo siguiente:
gcr.io/example-project/helloworld:*
Para incluir en la lista de entidades permitidas una versión específica de una imagen según su resumen, sigue estos pasos:
gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
Obtén más información sobre cómo usar resúmenes de imágenes de contenedores.
Obtén información para administrar imágenes exentas en la consola de Google Cloud, con la herramienta de línea de comandos o con la API de REST.
Imágenes del sistema mantenidas por Google
Confiar en todas las imágenes del sistema mantenidas por Google provoca que la autorización binaria exima una lista de imágenes del sistema mantenidas por Google de una evaluación de políticas más detallada. Cuando tienes esta configuración habilitada, la aplicación de las políticas no bloquea las imágenes que requiere GKE. La política del sistema se evalúa antes de la evaluación de la política del usuario y además de ella.
Puedes habilitar o inhabilitar esta configuración mediante la propiedad globalPolicyEvaluationMode en el archivo YAML de la política. Puedes ver el contenido de la política del sistema mediante el siguiente comando:
gcloud alpha container binauthz policy export-system-policy
Certificaciones
Una certificación es un documento digital que certifica una imagen. Durante la implementación, la autorización binaria verifica la certificación antes de que se implemente la imagen.
A veces, el proceso para crear una certificación se denomina firmar una imagen. Una certificación se crea después de que se compila una imagen. Cada imagen tiene un resumen único a nivel global. Un firmante firma el resumen de la imagen mediante una clave privada a partir de un par de claves, y usa la firma para crear la certificación. En el momento de la implementación, el ejecutor de Autorización Binaria usa la clave pública del certificador para verificar la firma de la certificación. Por lo general, un certificador corresponde a un solo firmante.
Una certificación indica que la imagen asociada se compiló mediante la ejecución correcta de un proceso obligatorio específico. Por ejemplo, si el firmante es un representante de la función de garantía de calidad (QA), la certificación puede indicar que la imagen aprobó todas las pruebas funcionales de extremo a extremo en un entorno de etapa de pruebas.
Para habilitar las certificaciones en la autorización binaria, el evaluationMode de tu política se establece como REQUIRE_ATTESTATION.
Obtén más información sobre cómo crear y usar certificadores y certificaciones.
Firmantes
Un firmante es una persona o un proceso automatizado que crea una certificación mediante la firma de un descriptor de imagen de contenedor único con una clave privada. La certificación se verifica en el momento de la implementación mediante la clave pública correspondiente almacenada un certificador antes de que se implemente el contenedor asociado.
Obtén más información sobre cómo crear y usar certificadores y certificaciones.
Certificadores
Un certificador es un recurso de Google Cloud que la autorización binaria usa para verificar la certificación durante la implementación de la imagen. Los certificadores incluyen la clave pública que corresponde a la clave privada que usa un firmante para firmar el resumen de la imagen y crear la certificación. El ejecutor de la autorización binaria usa el certificador en el momento de la implementación a fin de limitar las imágenes que se pueden implementar en aquellas con una certificación comprobable adjunta creada antes de la implementación.
El personal de operaciones de seguridad puede administrar los certificadores y también administrar los pares de claves públicas y privadas, mientras que los firmantes suelen ser ingenieros de software, QA de DevOps o personal de cumplimiento responsable de producir imágenes implementables, firmarlas con la clave privada y crear las certificaciones antes de intentar implementarlas.
Los certificadores tienen los siguientes recursos:
- Una nota de Artifact Analysis correspondiente
- Una o más claves públicas criptográficas que corresponden a la clave privada que el firmante usó para crear una certificación
Cuando configuras una política que contiene una regla a fin de Solicitar certificaciones, debes agregar un certificador en cada persona o proceso que deba verificar que la imagen esté lista para la implementación. Puedes agregar certificadores mediante la consola de Google Cloud, la interfaz de gcloud o la API de REST de la autorización binaria.
Obtén más información sobre cómo crear y usar certificadores y certificaciones.
Claves criptográficas
La autorización binaria usa firmas digitales a fin de verificar imágenes en el momento de la implementación cuando la política contiene una regla para Solicitar certificaciones.
Se genera un par de claves. El firmante usa la clave privada para firmar un descriptor de imagen. Esto crea una certificación.
Luego, se crea un certificador y se almacena en la política. La clave pública que corresponde a la clave privada que se usó para firmar se sube y se adjunta al certificador.
Cuando se intenta realizar una implementación de una imagen, Autorización Binaria usa certificadores en la política para verificar las certificaciones de la imagen. Si se puede verificar la certificación, se implementa la imagen.
La autorización binaria admite dos tipos de claves:
Las claves de PKIX pueden almacenarse de forma local, externa o en Cloud Key Management Service.
Crea una clave criptográfica y un certificador.
Notas de Artifact Analysis
Autorización Binaria usa Artifact Analysis para almacenar los metadatos de confianza que se usan en el proceso de autorización. En cada certificador que creas, se debe crear una nota de Artifact Analysis. Cada certificación se almacena como un caso de esta nota.
Cuando Autorización Binaria evalúa una regla que requiere que los certificadores tengan una imagen verificada, comprueba el almacenamiento de Artifact Analysis para ver si las certificaciones necesarias están presentes.