La validación continua (CV) con políticas de plataforma basadas en comprobaciones es una función de la autorización binaria que te permite monitorizar los pods que se ejecutan en Google Kubernetes Engine (GKE) para asegurarte de que sus imágenes de contenedor asociadas sigan cumpliendo las políticas de plataforma basadas en comprobaciones de la autorización binaria que especifiques.
Cuando CV determina que los pods infringen las políticas de la plataforma, registra las infracciones en Cloud Logging.
La verificación continua con políticas de la plataforma sustituye a la verificación continua antigua (obsoleta).
¿Por qué usar CV?
Aunque la aplicación de la autorización binaria proporciona validaciones de imágenes únicas cuando despliegas imágenes de contenedor, CV monitoriza continuamente que las imágenes asociadas a los pods en ejecución sigan cumpliendo tus políticas.
Por este motivo, cuando habilitas tanto la aplicación de la autorización binaria como la verificación de contenedores con políticas basadas en comprobaciones, puedes asegurarte de que la conformidad con las políticas se valida durante todo el ciclo de vida de la orquestación.
La verificación de contenido es útil en los siguientes casos:
Cambios en las políticas: cuando actualizas tus políticas de aplicación de un solo proyecto de autorización binaria, la autorización binaria solo valida las imágenes que se despliegan después de la actualización. Los pods que ya estén en ejecución no se verán afectados. Seguirán ejecutándose aunque la autorización binaria, con la política actualizada, ahora impida que se despliegue la misma imagen.
Por este motivo, cuando actualices la política de singleton de proyecto de Autorización Binaria, te recomendamos que también crees o actualices una política de plataforma de CV para que coincida con la política de singleton de proyecto. De esta forma, el CV te informa de los pods en ejecución que infringen tus políticas actualizadas.
Monitorización de metadatos de imágenes: la verificación de contenido proporciona comprobaciones específicas para detectar cambios en los metadatos de las imágenes, como los siguientes:
- Atestaciones: registra los cambios en el estado de las atestaciones de las imágenes de los pods.
- Actualización: registra cuándo detecta que las imágenes de los pods ya no están actualizadas.
- Procedencia: CV puede comprobar que las imágenes de los pods se han creado con un compilador de confianza mediante configuraciones de compilación que se encuentran en un repositorio de origen de confianza.
- Firmas de Sigstore: registros de CV cuando las imágenes de los pods no tienen una firma de Sigstore válida.
- Directorio de confianza: registros de CV cuando las imágenes de los pods se encuentran en un directorio de repositorio que no figura en tu política de la plataforma.
- Vulnerabilidades: registra las vulnerabilidades cuando se identifican en las imágenes de los pods.
Monitorización de prueba: cuando habilitas la prueba, la autorización binaria permite que se desplieguen todas las imágenes. Si habilitas la verificación de la conformidad con una política de plataforma que coincida con la política de un solo proyecto, la verificación de la conformidad registrará periódicamente las imágenes que infrinjan la política de plataforma.
Monitorización de acceso de emergencia: cuando implementas pods con acceso de emergencia, Binary Authorization omite la aplicación de la política de un solo proyecto y registra un solo evento en Registros de auditoría de Cloud. Sin embargo, al usar una política de plataforma coincidente, CV sigue registrando periódicamente los pods que infringen las políticas, incluidos los pods implementados mediante Breakglass.
Cómo funciona la conversión
Para usar CV, debes habilitarlo en tus clústeres de GKE.
Después de desplegar imágenes en tu clúster, CV monitoriza los pods asociados para asegurarse de que cumplen tu política de plataforma basada en comprobaciones.
CV no admite etiquetas de imagen, excepto las que se especifican en las imágenes exentas.
CV revisa periódicamente los pods en ejecución
Para monitorizar los pods en ejecución, la revisión de CV analiza las imágenes asociadas a cada pod al menos cada 24 horas. CV también monitoriza los contenedores init y los contenedores efímeros.
Durante cada revisión, CV obtiene una lista de imágenes asociadas a cada pod. A continuación, CV verifica que la información de la imagen cumple la política de la plataforma.
Los registros de CV infringen las políticas de la plataforma
Cuando CV determina que las imágenes infringen una política de la plataforma, registra las infracciones y otros resultados en Cloud Logging. Se escribe una entrada de registro independiente para cada política de la plataforma que se infringe en cada pod.
Cuando CV evalúa las imágenes de un pod mediante una política de la plataforma, es posible que las imágenes cumplan algunos requisitos y no otros. CV genera una entrada de registro cada vez que una imagen de un pod infringe alguna comprobación. La entrada de registro solo contiene las imágenes de Pod que infringen la política de la plataforma. Si todas las imágenes cumplen todos los requisitos, no se generará ninguna entrada de registro.
CV sigue registrando infracciones de las políticas hasta que finaliza un pod con imágenes que no cumplen las políticas. Cuando se terminan los pods que no cumplen las políticas durante el intervalo entre validaciones, las entradas de registro finales generadas por CV pueden aparecer después de la finalización, durante la siguiente evaluación de CV.
Los pods que no cumplan las políticas deben registrarse al menos una vez, incluso si son de corta duración.
CV no finaliza los pods en ejecución.
CV usa un recurso de feed
Para obtener información sobre los pods que se ejecutan en tu clúster de GKE, CV crea un recurso de feed llamado binauthz-cv-cai-feed.
Políticas de la plataforma de CV
Para usar CV, primero debes configurar las políticas de la plataforma.
Las políticas de la plataforma son diferentes de las políticas de autorización binaria antiguas, también llamadas políticas de un solo proyecto. Aunque el proyecto de implementación solo puede tener una política de singleton de proyecto antiguo, puedes configurar varias políticas de plataforma. Cada política de plataforma puede residir en uno o varios proyectos.
Las políticas de plataforma solo funcionan con CV y no admiten la aplicación de la autorización binaria. Por este motivo, te recomendamos que, si quieres usar tanto la aplicación de la autorización binaria como la monitorización de CV, crees una política de un solo proyecto para la aplicación y una política de plataforma para la monitorización.
Por ejemplo, supongamos que quieres configurar la autorización binaria para exigir que tus imágenes tengan una certificación antes de que se puedan desplegar y que también quieres asegurarte de que tus pods en ejecución cumplan el mismo requisito. Para ello, configura una política de cumplimiento de un solo proyecto con un attestor. A continuación, crea una política de plataforma con una comprobación de atestación de firma simple que tenga un autenticador basado en la misma nota y clave pública que el encargado de la atestación.
Las políticas de la plataforma son específicas de cada plataforma. GKE es la única plataforma compatible.
Puedes configurar comprobaciones en las políticas de la plataforma. Las comprobaciones se agrupan en uno o varios conjuntos de comprobaciones. Cada conjunto de comprobaciones puede especificar una o varias comprobaciones.
Las políticas de la plataforma pueden eximir a las imágenes de la evaluación por parte de la visión artificial.
Permisos obligatorios
Para enumerar o describir las políticas de la plataforma, necesitas el rol binaryauthorization.policyViewer. Para crear, modificar y eliminar políticas de plataforma, necesitas el rol binaryauthorization.policyEditor.
Para obtener más información, consulta el artículo Gestionar políticas de la plataforma.
Actualizaciones de las políticas
Al actualizar una política de plataforma, se sobrescribe la política actual con un descriptor de política que proporciones en el archivo YAML. Para añadir una nueva comprobación a una política de plataforma, te recomendamos que describas la política, la guardes en un archivo YAML, añadas la nueva comprobación y, a continuación, actualices la política con el archivo actualizado.
Políticas de varias plataformas
Puedes crear políticas de plataforma en el mismo proyecto que el clúster (una política de plataforma local) o en cualquier otro proyecto.
Como puede configurar varias políticas de plataforma, debe asignar a cada una un nombre de recurso único. Cuando ejecutas un comando de la CLI de gcloud, haces referencia a la política de la plataforma local mediante su ID. Cuando haces referencia a una política de plataforma en otro proyecto, usas el nombre del recurso con el siguiente formato:
projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID
Puedes elegir qué política de plataforma quieres asociar a cada clúster de GKE, ya sea una política de plataforma local o una de otro proyecto.
Varias comprobaciones por política de plataforma
Puede configurar varias comprobaciones en cada política de la plataforma añadiéndolas al bloque checks de la política. Para obtener más información sobre las comprobaciones específicas que puede configurar, consulte Comprobaciones.
Si la política de tu plataforma de CV especifica más de una comprobación, las imágenes que se evalúan mediante una comprobación seguirán evaluándose mediante las demás.
La autorización binaria evalúa todas las comprobaciones configuradas en la política de la plataforma para cada imagen, a menos que la imagen coincida con un patrón de lista de permitidas de imágenes exentas. Para obtener más información, consulta el artículo sobre imágenes exentas.
Configuración de un solo proyecto
Puedes configurar la verificación de la edad en un solo proyecto.
En una configuración de un solo proyecto, la autorización binaria configura automáticamente los roles necesarios en el agente de servicio de autorización binaria.
Si los clústeres de GKE, las políticas de plataforma vinculadas a los clústeres y los metadatos que requieren las comprobaciones residen en el mismo proyecto, no se necesitan roles de gestión de identidades y accesos (IAM) adicionales.
Para obtener más información sobre cómo configurar una configuración de varios proyectos para aumentar la seguridad, consulta el artículo Separación de responsabilidades.
Configuración multiproyecto
Cuando configuras una configuración de verificación de contenedores de varios proyectos con políticas de plataforma, las políticas de plataforma, las imágenes, el clúster de GKE y otros tipos de recursos dependientes de la verificación de contenedores pueden residir en proyectos diferentes.
En la configuración multiproyecto, es importante conocer el propósito de cada proyecto y los recursos a los que necesita acceder el servicio de verificación de la identidad para configurar los roles y permisos de gestión de identidades y accesos necesarios.
Cómo usar CV
Para usar la verificación de la tarjeta, normalmente debes hacer lo siguiente:
- Decide qué comprobaciones quieres usar.
- Redacta una o varias políticas de plataforma mediante un archivo YAML de políticas. El archivo especifica las comprobaciones que quieres usar.
- Crea la política de la plataforma. La política se puede almacenar en el proyecto que elijas.
- Elige si quieres habilitar la actualización de controladores en clústeres individuales o en una flota.
- Consulta los registros de CV en Logging para ver los eventos.
- Revisa los registros y actualiza tu compilación y otros procesos para generar imágenes que cumplan los requisitos.
Cheques
En esta sección se describen las comprobaciones específicas que ofrece CV.
Las políticas basadas en comprobaciones tienen el siguiente formato canónico:
gkePolicy:
checkSets:
- checks:
- CHECK_TYPE1:
CHECK_TYPE1_PARAMETERS
displayName: CHECK_TYPE1_DISPLAY_NAME
- CHECK_TYPE2:
CHECK_TYPE2_PARAMETERS
displayName: CHECK_TYPE2_DISPLAY_NAME
displayName: CHECK_SET_DISPLAY_NAME
El campo displayName de checks y checkSets es opcional. Solo se usa cuando el valor de confianza en el envío registra infracciones de las políticas. Se omite en algunos de los ejemplos que se muestran más adelante en esta guía.
Comprobación de denegación siempre
La comprobación de denegación siempre garantiza que todas las imágenes sujetas a esta comprobación no superen la evaluación. Cada vez que CV revisa los pods en ejecución con esta comprobación, se genera una entrada de registro para cada uno de los pods.
Puede combinar la comprobación de denegación siempre con listas de permitidos o varios conjuntos de comprobaciones para asegurarse de que la autorización binaria siempre genere registros de pods en determinados casos.
Para usar la comprobación de denegación siempre, añade alwaysDeny: true en el bloque checks, como se indica a continuación:
gkePolicy:
checkSets:
- displayName: "My check set"
checks:
- alwaysDeny: true
El valor de alwaysDeny no puede ser false. En su lugar, quita la marca.
Para ver ejemplos de cómo se puede usar la comprobación de denegación siempre, consulta Usar varios conjuntos de comprobaciones.
Comprobación de la actualización de la imagen
La comprobación de la actualización de la imagen calcula la duración durante la que se ha estado ejecutando una imagen y registra cuándo se ha superado el umbral, maxUploadAgeDays.
En el siguiente ejemplo de YAML de la política de la plataforma, se registran los pods con imágenes que se subieron al repositorio desde el que se desplegaron hace más de 30 días.
gkePolicy:
checkSets:
checks:
- imageFreshnessCheck:
maxUploadAgeDays: 30
displayName: "My image freshness check"
displayName: "My check set"
Comprobación de atestación de firma sencilla
Puedes usar la comprobación de atestación de firma simple de CV para comprobar que cada una de las imágenes de un pod tiene una atestación válida y firmada.
Esta comprobación equivale a la evaluación de la certificación en una política de aplicación de la autorización binaria. Puedes configurar esta comprobación con las mismas notas y claves que hayas usado en tu attestor. Te recomendamos que utilices esta comprobación en lugar de la validación continua antigua (obsoleta).
A continuación, se muestra un ejemplo de una política de plataforma con una comprobación de atestación de firma sencilla:
gkePolicy:
checkSets:
checks:
simpleSigningAttestationCheck:
containerAnalysisAttestationProjects:
- "projects/my-attestation-project1"
- "projects/my-attestation-project2"
attestationAuthenticators:
pkixPublicKeySet:
pkixPublicKeys:
publicKeyPem: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
-----END PUBLIC KEY-----
signatureAlgorithm: ECDSA_P256_SHA256
En lugar de encargados de la atestación de autorización binaria, las comprobaciones de atestación de CV tienen autenticadores. Puedes especificar los autenticadores directamente en la política, en el bloque attestationAuthenticators.
En una política de plataforma, simpleSigningAttestationCheck puede tener varios attestationAuthenticators y varias claves en cada pkixPublicKeySet. La comprobación se realiza correctamente cuando cada una de las imágenes de los pods tiene una certificación válida firmada con cualquier clave de cualquier autenticador pkixPublicKeySet.
Las políticas de la plataforma de CV se diferencian de las políticas de cumplimiento de singleton de proyectos en los siguientes aspectos:
- No se admiten las claves PGP.
- No es necesario que haya encargados de la atestación. En su lugar, crea las claves manualmente y, a continuación, describe una política de plataforma para obtener el ID de clave que usarás para crear la atestación.
- Crea y firma manualmente la carga útil, crea el archivo JSON de atestación y crea la atestación mediante la API Artifact Analysis.
- Seguirás creando una nota de análisis de artefactos, pero no la especificarás en la política. En su lugar, CV busca
atestaciones en todos los proyectos que se incluyan en el campo
containerAnalysisAttestationProjects. - Las certificaciones se siguen almacenando en las ocurrencias de Artifact Analysis, pero se pueden almacenar en más de un proyecto.
- Debes especificar explícitamente uno o varios proyectos que contengan certificaciones mediante el nombre de recurso
projects/ATTESTATION_PROJECT_ID.
CV no admite etiquetas de imagen, excepto las especificadas en exempt images.
Si las imágenes se implementan con una etiqueta de imagen en lugar de con un digest, CV primero la evalúa en comparación con las imágenes exentas, ya que las listas de permitidas pueden incluir etiquetas. Si la imagen no está exenta, el CV intenta encontrar el resumen de la imagen. Como no hay ninguna, la imagen infringe la comprobación.
Comprobación de SLSA
La comprobación de SLSA verifica la procedencia especificada por SLSA de las imágenes de los pods.
A continuación, se muestra un ejemplo de configuración YAML de una política de plataforma de CV:
gkePolicy:
checkSets:
checks:
imageAllowlist:
allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
- slsaCheck:
rules:
trustedBuilder: GOOGLE_CLOUD_BUILD
attestationSource:
- containerAnalysisAttestationProjects: "projects/attestation-project1"
- containerAnalysisAttestationProjects: "projects/attestation-project2"
# Require that images were built using a checked-in top-level config file.
configBasedBuildRequired: true
# Which repos the config file can be from.
trustedSourceRepoPatterns:
- "source.cloud.google.com/my-project/my-source-repo"
- "github.com/my-github-user/*"
displayName: "My SLSA check"
displayName: "My check set"
Cuando la CV revisa imágenes mediante esta política de la plataforma, comprueba lo siguiente:
Las imágenes deben haber sido creadas por un creador de confianza. Cloud Build es el único compilador de confianza que admite la comprobación de SLSA.
Cloud Build debe haber generado las atestaciones en
attestation-project1oattestation-project2.Las imágenes deben crearse con un archivo de configuración de nivel superior de uno de los siguientes repositorios de confianza:
- El repositorio
source.cloud.google.com/my-project/my-source-repo/ - Cualquier repositorio de
github.com/my-github-user/
- El repositorio
Las imágenes de
gcr.io/my-images/not-built-by-GCB/o sus subdirectorios (que no se han creado con Cloud Build) están exentas de la comprobación, ya que la infringirían.
Comprobación de la firma de Sigstore
La comprobación de la firma de Sigstore verifica que las imágenes se han firmado con firmas de Sigstore.
Esta comprobación solo admite imágenes alojadas en Artifact Registry. Comprueba si se puede verificar correctamente alguna firma obtenida de Artifact Registry con alguna clave de la política.
En la siguiente política de plataforma de ejemplo se describe cómo configurar una comprobación de firma de Sigstore:
gkePolicy:
checkSets:
- checks:
- displayName: sigstore-signature-check
sigstoreSignatureCheck:
sigstoreAuthorities:
- displayName: sigstore-authority
publicKeySet:
publicKeys:
publicKeyPem: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
-----END PUBLIC KEY-----
En la política de la plataforma, sigstoreSignatureCheck puede tener varios sigstoreAuthorities y varias claves en cada publicKeySet. La comprobación se realiza cuando cada una de las imágenes de los pods tiene una certificación válida firmada con cualquier clave de cualquier autenticador publicKeySet.
Comprobación de directorio de confianza
La comprobación de directorios de confianza verifica que las imágenes de los pods se encuentran en uno de los directorios de confianza proporcionados que especifiques en una política de plataforma.
Cuando uses esta comprobación, te recomendamos que también protejas los repositorios que incluyas como directorios de confianza en tu política frente a accesos no autorizados.
En la siguiente política de la plataforma se describe cómo configurar una comprobación de directorios de confianza:
gkePolicy:
checkSets:
checks:
trustedDirectoryCheck:
trustedDirPatterns:
- "gcr.io/my-project/gcr-directory"
- "us-central1-docker.pkg.dev/my-project/ar-directory"
displayName: "My trusted directory check"
displayName: "My check set"
En la política de plataforma de ejemplo, trustedDirPatterns enumera los directorios de confianza. Si todas las imágenes de los pods se encuentran en los directorios indicados, cumplen la política. Las imágenes de pods que no se encuentren en los directorios indicados infringen la política y el registro de CV registra las infracciones.
Comprobación de vulnerabilidades
La comprobación de vulnerabilidades usa el análisis de vulnerabilidades de Artifact Analysis para comprobar si las imágenes de los pods contienen vulnerabilidades. Esto incluye las nuevas vulnerabilidades que se identifican mediante el análisis de vulnerabilidades desde que se desplegó el pod. En la comprobación de vulnerabilidades, puedes configurar umbrales de nivel de gravedad de las vulnerabilidades y vulnerabilidades específicas (como CVEs). Las imágenes con vulnerabilidades que infringen la comprobación de vulnerabilidades se registran en Logging.
Para usar esta comprobación, primero debe habilitar el análisis de vulnerabilidades en Artifact Analysis.
La siguiente configuración de la política de plataforma de ejemplo contiene una comprobación de vulnerabilidades:
gkePolicy:
checkSets:
- displayName: "Default check set"
checks:
- vulnerabilityCheck:
maximumFixableSeverity: MEDIUM
maximumUnfixableSeverity: HIGH
allowedCves:
- "CVE-2022-11111"
- "CVE-2022-22222"
blockedCves:
- "CVE-2022-33333"
- "CVE-2022-44444"
containerAnalysisVulnerabilityProjects: "projects/my-project"
En el ejemplo, maximumUnfixableSeverity y maximumFixableSeverity definen los niveles de gravedad del sistema de puntuación Common Vulnerability Scoring System (CVSS) asociados a cualquier vulnerabilidad que pueda identificar Artifact Analysis.
Además, blockedCves incluye una lista de vulnerabilidades y exposiciones comunes (CVEs) específicas. Si una vulnerabilidad identificada supera uno de los niveles de gravedad especificados o coincide con una de las CVEs que se indican en blockedCves y no coincide con ninguna de las CVEs que se indican en allowedCves, CV registra una entrada en Logging.
Validar las políticas actualizadas
Después de actualizar una política de la plataforma de CV, le recomendamos que valide que la autorización binaria y CV sigan funcionando como espera.
Validar la configuración
Para comprobar la configuración, inspecciona las políticas de singleton de proyecto de Autorización binaria y las políticas de la plataforma de CV.
Validar operación
Para validar que la autorización binaria y la verificación de contenedores funcionan como esperas, puedes implementar pods de prueba y, a continuación, consultar las entradas de autorización binaria en Logging.
Eximir imágenes con listas de permitidos
Cuando creas una política de plataforma, puedes excluir imágenes de las comprobaciones añadiendo sus URLs a una lista de permitidos. Una lista de permitidos a nivel de política exime a las imágenes de toda la política. Una lista de permitidos a nivel de conjunto de comprobaciones exime de la comprobación y solo se aplica cuando se evalúa ese conjunto de comprobaciones. Una lista de permitidas dentro de una comprobación solo exime a las imágenes de esa comprobación.
Los patrones de lista de permitidos son patrones que coinciden con una o varias URLs de imagen. Un patrón de lista de permitidos puede ser uno de los siguientes:
- Un prefijo de nombre de imagen que termine en el comodín
*o**. - Solo el nombre de la imagen, sin etiqueta ni resumen.
- Nombre de una imagen con una etiqueta (o prefijo de etiqueta con el comodín
*). - Nombre de una imagen con un digest.
- Nombre de una imagen con una etiqueta y un digest.
Estos son algunos ejemplos de patrones de lista de permitidos:
us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8ccoincide con el nombre, la etiqueta y el digest de una imagen exactos.us-central1.pkg.dev/my-project/my-image:latestcoincide con el nombre y la etiqueta, con cualquier resumen (o sin resumen).us-central1.pkg.dev/my-image:foo*coincide con el nombre y el prefijo de la etiqueta (comomyimage:fooymyimage:foobar), con cualquier resumen (o sin resumen).us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8ccoincide con el nombre y el resumen, con cualquier etiqueta (o sin etiqueta).us-central1.pkg.dev/my-project/my-imagecoincide con el nombre, con cualquier etiqueta o digestión.
Los comodines * y ** se pueden usar para buscar coincidencias con cualquier nombre que tenga un prefijo determinado. * coincide con los sufijos que no incluyen /. ** coincide con
sufijos que pueden incluir /, pero ** solo se puede usar después de /. Tenga en cuenta que * y ** no se pueden usar con etiquetas ni resúmenes.
Por ejemplo:
us-central1.pkg.dev/my-project/my-image*coincide conus-central1.pkg.dev/myproject/my-image,us-central1.pkg.dev/myproject/my-image1yus-central1.pkg.dev/myproject/my-image2, con cualquier etiqueta o resumen.us-central1.pkg.dev/my-project/**coincide conus-central1.pkg.dev/myproject/my-imageyus-central1.pkg.dev/my-project/some-directory/other-image, con cualquier etiqueta o digest.
Ten en cuenta que los prefijos de nombre y de etiqueta no pueden estar vacíos. Por lo tanto, * o ** por sí solos
no son patrones válidos, ni tampoco us-central1.pkg.dev/my-image:*.
Exención a nivel de gkePolicy
En el siguiente ejemplo se muestra cómo excluir imágenes a nivel de política de la plataforma. Todas las imágenes de los directorios exempt-images1 y exempt-images2
y sus subdirectorios se excluyen de la monitorización de CV.
gkePolicy:
imageAllowlist:
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checkSets:
checks:
...
En la política, las imágenes que se indican en imageAllowlist están exentas de todos los conjuntos de comprobaciones (checkSets) que se indican en gkePolicy.
checkSet-level exemption
En el siguiente ejemplo se muestra cómo excluir imágenes a nivel de conjunto de comprobaciones:
gkePolicy:
checkSets:
imageAllowlist:
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checks:
...
En la política, las imágenes que se indican en imageAllowlist están exentas de todas las comprobaciones que se indican en checkSets.
exención a nivel de comprobaciones
En el siguiente ejemplo se muestra cómo excluir imágenes a nivel de comprobación:
gkePolicy:
checkSets:
checks:
imageAllowlist:
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
...
Usar varios conjuntos de comprobaciones
Una política basada en la comprobación de CV puede contener más de un conjunto de comprobaciones. CV evalúa un conjunto de comprobaciones cada vez que evalúa la política. Los conjuntos de comprobaciones se pueden considerar como subpolíticas que deben evaluarse en diferentes situaciones. Por ejemplo, si quieres aplicar comprobaciones diferentes en entornos de desarrollo y en entornos de producción, puedes poner las comprobaciones de cada entorno en un conjunto de comprobaciones independiente. De esta forma, un conjunto se evaluará solo en el entorno de desarrollo y el otro, en el de producción.
Cada conjunto de comprobaciones se limita a un espacio de nombres de Kubernetes o a una cuenta de servicio de Kubernetes. El ámbito determina a qué pods se aplica el conjunto de comprobaciones.
Cuando se configura un conjunto de comprobaciones con un ámbito, solo se aplica a los pods que se ejecutan en ese ámbito.
Cuando un conjunto de comprobaciones no tiene ámbito, se denomina conjunto de comprobaciones predeterminado, lo que significa que las comprobaciones se aplican a todos los pods, independientemente de su espacio de nombres de Kubernetes o del ámbito de la cuenta de servicio.
La mayoría de las políticas de ejemplo de las guías de verificación de contenido solo usan un conjunto de comprobaciones predeterminado.
La siguiente configuración de política de ejemplo configura tres conjuntos de comprobaciones:
gkePolicy:
checkSets:
- displayName: "Prod check set"
scope:
kubernetesNamespace: "prod-namespace"
checks:
- trustedDirectoryCheck:
trustedDirPatterns: "gcr.io/my-project/prod-images"
- imageFreshnessCheck:
maxUploadAgeDays: 30
- displayName: "Dev check set"
scope:
kubernetesNamespace: "dev-namespace"
checks:
- trustedDirectoryCheck:
trustedDirPatterns: "gcr.io/my-project/dev-images"
- displayName: "Default check set"
checks:
- alwaysDeny: true
En la configuración de ejemplo, el primer conjunto de comprobaciones se limita a prod-namespace, por lo que sus comprobaciones solo afectan a los pods que se ejecutan en ese ámbito. El segundo conjunto de comprobaciones se limita a dev-namespace, por lo que sus comprobaciones solo afectan a los pods que se ejecutan en ese ámbito.
El tercer conjunto de comprobaciones es un conjunto de comprobaciones predeterminado. Sus comprobaciones se aplican a todos los pods del clúster que se ejecutan fuera de los ámbitos prod-namespace y dev-namespace.
Cuando CV evalúa el conjunto de comprobaciones llamado Prod check set, comprueba lo siguiente en las imágenes de los pods que se ejecutan en el espacio de nombres prod-namespace de Kubernetes:
- Las imágenes se almacenan en el directorio de confianza
prod-images. - Las imágenes se han subido en los últimos 30 días.
Cuando CV evalúa el conjunto de comprobaciones llamado Dev check set, evalúa los pods que se ejecutan en el espacio de nombres de Kubernetes dev-namespace y comprueba si las imágenes del pod proceden del directorio dev-images.
El conjunto de comprobaciones predeterminado actúa como comodín. La comprobación de denegación siempre garantiza que CV registre todos los pods que se ejecutan en cualquier otro espacio de nombres.
Para usar una cuenta de servicio de Kubernetes como ámbito de un conjunto de comprobaciones, sustituye la clave
kubernetesNamespace del ejemplo por kubernetesServiceAccount. El valor tiene el formato my-namespace:my-service-account.
Comprueba que los ámbitos definidos cumplan las siguientes reglas:
Solo puede haber un conjunto de comprobaciones por ámbito en una política de plataforma.
Si una política contiene conjuntos de comprobaciones con ámbito de espacio de nombres y con ámbito de cuenta de servicio, el conjunto de comprobaciones con ámbito de cuenta de servicio debe aparecer en primer lugar, seguido del conjunto de comprobaciones con ámbito de espacio de nombres.
Solo puede haber un conjunto de comprobaciones predeterminado, que debe aparecer en último lugar.
Si una política de la plataforma contiene algún conjunto de comprobaciones, debe contener al menos un conjunto de comprobaciones predeterminado. Se permite una política de plataforma sin conjuntos de comprobaciones, pero, como no hay comprobaciones que infringir, CV no genera ninguna entrada de registro.
CV antiguo
En esta sección se describen las políticas de CV antiguas. Si es la primera vez que usa la verificación de contenido, le recomendamos que utilice la verificación de contenido con políticas basadas en comprobaciones.
Para admitir a los usuarios de versiones anteriores de CV, se puede habilitar CV en proyectos que ejecuten GKE. A continuación, CV usa la política de aplicación de la autorización binaria para comprobar todos los pods que se ejecutan en todos los clústeres del proyecto, incluidos los clústeres en los que no está habilitada la aplicación de la autorización binaria.
Consulta cómo usar la versión antigua de CV (obsoleta) y ver eventos de la versión antigua de CV en Cloud Logging.
Siguientes pasos
- Usar la comprobación de la actualización de imágenes
- Usar la comprobación de atestación de firma sencilla
- Usar la comprobación de firmas de Sigstore
- Usar la comprobación de SLSA
- Usar la comprobación de directorios de confianza
- Usar la comprobación de vulnerabilidades
- Ver registros de conversión
- Consulta información sobre la autorización binaria.