Las Condiciones del Servicio de Google Cloud Platform (sección 1.4(d), “Interrupción de los servicios”) definen la política de baja que se aplica a Binary Authorization. Esta política de baja solo se aplica a los servicios, las funciones o los productos que aparecen en el documento en cuestión.
Después de que un servicio, una función o un producto deja de estar disponible de forma oficial, seguirá disponible durante al menos el período definido en las Condiciones del Servicio. Luego de este período, se programará la baja del servicio.
La Autorización Binaria dejará de ser compatible con la validación continua heredada (CV heredada) con políticas singleton de proyecto para GKE.
- A partir del 15 de abril de 2024, no puedes habilitar la CV heredada para Google Kubernetes Engine (GKE) en proyectos nuevos.
- La CV heredada seguirá supervisando tus Pods de GKE a través de políticas singleton de proyecto para los proyectos existentes en los que ya está habilitada hasta el 1 de mayo de 2025. Después del 1 de mayo de 2025, la CV heredada ya no supervisará tus Pods y las entradas de Cloud Logging ya no se producirán para las imágenes de Pods que no cumplan con la política de Autorización Binaria singleton de proyecto.
Reemplazo: Validación continua (CV) con políticas de plataforma basadas en verificaciones
Supervisa tus Pods con la validación continua (CV) con políticas de plataforma basadas en verificaciones.
Además de admitir certificaciones, las políticas de plataforma basadas en verificaciones te permiten supervisar los metadatos de las imágenes de contenedor asociadas con tus Pods para ayudarte a mitigar posibles problemas de seguridad. Las políticas basadas en verificaciones de CV proporcionan verificaciones que incluyen lo siguiente:
- Verificación de vulnerabilidades: Se verifica la imagen en busca de vulnerabilidades de seguridad que tengan un nivel de gravedad que definas.
- Verificación de Sigstore: La imagen tiene certificaciones firmadas por Sigstore.
- Verificación de SLSA: La imagen se compiló a partir de la fuente en un directorio de confianza y por un compilador de confianza.
- Verificación del directorio de confianza: La imagen debe residir en un directorio de confianza dentro de un repositorio de imágenes de confianza.
Al igual que la validación continua heredada, la CV con políticas basadas en verificaciones también registra los Pods con imágenes que no cumplen con las políticas en Logging.
Si usas la validación continua heredada (CV heredada), consulta Migración.
Para obtener más información sobre cómo usar la CV con políticas de plataforma basadas en verificaciones, consulta la descripción general de la validación continua.
Migración
Para migrar de una política de proyecto singleton de CV heredada a una política de plataforma equivalente basada en la verificación, haz lo siguiente:
- Para una política singleton de proyecto
ALWAYS_ALLOW, crea una política de plataforma basada en verificaciones sin ningún bloquecheckSet. - Para una política singleton de proyecto
ALWAYS_DENY, crea una política de plataforma basada en verificaciones con un solo bloquecheckSetque tenga una verificaciónalwaysDeny. - Para una política singleton de proyecto que requiere certificaciones, crea una sola política basada en verificaciones y, para cada certificador en la política singleton de proyecto, agrega una SimpleSigningAttestationCheck a la política basada en verificaciones. Cuando usas el mismo par de claves, la verificación sigue funcionando con tus certificaciones existentes y registra solo las imágenes de Pod que no tienen certificaciones válidas.
Las políticas de plataforma basadas en verificaciones tienen permisos en un clúster de GKE, en lugar de un proyecto de Google Cloud. Después de crear una política de plataforma basada en verificaciones, puedes aplicarla a uno o más clústeres.
Para habilitar la CV con políticas de plataforma basadas en verificaciones en un clúster, la configuración de Autorización Binaria del clúster se debe configurar durante el proceso de creación o actualización del clúster.