La validación continua (CV) es una función de Autorización Binaria que te permite supervisar Pods que se ejecutan en Google Kubernetes Engine (GKE) para garantizar que sus imágenes de contenedor asociadas continúen cumpliendo con las las políticas de plataforma basadas en la verificación de Autorización Binaria que especifiques.
Cuando la CV determina que los Pods infringen las políticas de la plataforma, registra las infracciones en Cloud Logging.
La CV con políticas de plataforma sustituye la validación continua heredada.
¿Por qué usar la CV?
Aunque la aplicación de Autorización Binaria proporciona validaciones de imágenes únicas cuando implementas imágenes de contenedor, la CV supervisa de forma continua que las imágenes asociadas con los Pods en ejecución sigan cumpliendo tus políticas.
Debido a esto, cuando habilitas la aplicación de Autorización Binaria y la CV con políticas basadas en verificaciones, puedes asegurarte de que la conformidad con la política se valide durante todo el ciclo de vida de la organización.
Esto es útil en las siguientes situaciones:
Cambios en las políticas: Cuando actualizas las políticas de aplicación singleton de proyecto de Autorización Binaria, esta valida solo las imágenes que se implementan después de la actualización. Los Pods que ya están en ejecución no se ven afectados. Continúan ejecutándose incluso si Autorización Binaria, mediante la política actualizada, bloquearía la implementación de la misma imagen.
Debido a esto, cuando actualizas la política singleton de proyecto de Autorización Binaria, te recomendamos que también crees o actualices una política de plataforma de la CV para que coincida con la política singleton del proyecto. De esta manera, la CV te informa sobre la ejecución de Pods que infringen tus políticas actualizadas.
Supervisión de metadatos de imagen: La CV proporciona verificaciones específicas para detectar cambios en los metadatos de imagen, incluidas las siguientes:
- Certificaciones: La CV registra cuando las certificaciones de las imágenes de Pods ya no son válidas.
- Actualidad: La CV registra los registros cuando detecta que las imágenes de los Pods ya no están actualizadas.
- Procedencia: La CV puede verificar que las imágenes de los Pods se hayan compilado con un compilador de confianza, a través de configuraciones de compilación que residan en un repositorio de código fuente confiable.
- Firmas de Sigstore: La CV registra cuando las imágenes de los Pods no tienen una firma de Sigstore válida.
- Directorio de confianza: La CV registra cuando las imágenes de los Pods residen en un directorio de repositorio que no aparece en la política de la plataforma.
- Vulnerabilidades: La CV registra cuando se identifican vulnerabilidades en las imágenes de Pods.
Supervisión de pruebas de validación: Cuando habilitas las pruebas de validación, Autorización Binaria permite que se implementen todas las imágenes. Si habilitas la CV con una política de plataforma que coincida con la política singleton del proyecto, la CV registra con regularidad las imágenes que infringen la política de la plataforma.
Supervisión de anulación de emergencia: Cuando implementas Pods con anulación de emergencia, Autorización Binaria omite la aplicación de la política singleton del proyecto y registra un solo evento en los Registros de auditoría de Cloud. Sin embargo, mediante el uso de una política de plataforma coincidente, la CV registra de forma periódica los Pods que infringen las políticas, incluidos los que se implementan con anulación de emergencia.
Cómo funciona la CV
Para usar la CV, debes habilitarla en tus clústeres de GKE.
Después de implementar imágenes en tu clúster, la CV supervisa los Pods asociados para asegurarse de que cumplan con la política de la plataforma basada en verificaciones.
La CV no admite etiquetas de imagen, excepto las especificadas en imágenes exentas.
La CV revisa con regularidad los Pods en ejecución
Para supervisar los Pods en ejecución, la CV revisa las imágenes asociadas con cada Pod al menos cada 24 horas. La CV también supervisa los contenedores init.
Durante cada revisión, la CV recupera una lista de imágenes asociadas con cada Pod. Luego, la CV verifica que la información de la imagen cumpla con la política de la plataforma.
La CV registra los incumplimientos de las políticas de la plataforma
Cuando la CV determina que las imágenes infringen la política de una plataforma, registra las infracciones y otros resultados en Cloud Logging. Se escribe una entrada de registro separada para cada política de la plataforma que se infringe, en cada Pod.
Cuando la CV evalúa las imágenes de un Pod mediante una política de la plataforma, las imágenes pueden satisfacer algunas verificaciones e infringir otras. La CV produce una entrada de registro cada vez que una imagen de un Pod infringe una o más verificaciones. La entrada de registro solo contiene las imágenes que infringen la política de la plataforma. Si todas las imágenes satisfacen todas las verificaciones, no se producen entradas de registro.
Hasta que un Pod finalice con imágenes que no cumplen con las políticas, la CV continúa registrando incumplimientos de políticas. Los Pods que no cumplen con las políticas y que se finalizan durante el intervalo entre verificaciones se registran durante la siguiente revisión de la CV.
La CV no finaliza los Pods en ejecución.
La CV usa un recurso de feed
Para recuperar información sobre Pods que se ejecutan en tu clúster de GKE, la CV crea un recurso de feed llamado binauthz-cv-cai-feed.
Políticas de plataforma de la CV
Para usar la CV, primero configura las políticas de plataforma.
Las políticas de plataforma son diferentes de las políticas de Autorización Binaria heredadas, también llamadas políticas singleton de proyecto. Aunque el proyecto de implementación solo puede tener una política singleton de proyecto heredada, puedes configurar varias políticas de plataforma. Cada política de plataforma puede residir en uno o más proyectos.
Las políticas de la plataforma funcionan solo con la CV y no son compatibles con la aplicación de la Autorización Binaria. Debido a esto, te recomendamos que, si deseas usar la aplicación de la Autorización Binaria y la supervisión de la CV, crees una política singleton del proyecto para la aplicación y una política de la plataforma para la supervisión.
Por ejemplo, supongamos que deseas configurar la Autorización Binaria para garantizar que tus imágenes tengan una certificación antes de que se puedan implementar y que quieras asegurarte de que los Pods en ejecución se ajusten a lo mismo. . Para hacerlo, configura una política de aplicación singleton de proyecto con un certificador. Luego, debes crear una política de plataforma con una verificación de certificación de firma simple que tenga un autenticador basado en la misma nota y clave pública que el certificador.
Las políticas de plataforma son específicas de la plataforma. GKE es la única plataforma compatible.
Puedes configurar verificaciones en las políticas de la plataforma. Las verificaciones se agrupan en uno o más conjuntos de verificaciones. Cada conjunto de verificaciones puede especificar una o más verificaciones.
Las políticas de la plataforma pueden eximir imágenes de la evaluación mediante la CV.
Permisos necesarios
Para enumerar o describir las políticas de la plataforma, necesitas el rol binaryauthorization.policyViewer. Para crear, modificar y borrar políticas de la plataforma, necesitas el rol binaryauthorization.policyEditor.
Para obtener más información, consulta Administra las políticas de plataforma.
Actualizaciones de políticas
Si actualizas una política de plataforma, se reemplaza la política existente por un descriptor de política que proporcionas en el archivo YAML. Para agregar una verificación nueva a una política de plataforma existente, te recomendamos describir la política existente, guardarla en un archivo YAML, agregar la verificación nueva y, luego, actualizar la política con el archivo actualizado.
Varias políticas de la plataforma
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.
Debido a que puedes configurar varias políticas de plataforma, deberás asignar a cada una un nombre de recurso único. Cuando ejecutas un comando de gcloud CLI, 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 en el siguiente formato: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID
Puedes elegir qué política de la plataforma asociar con cada clúster de GKE, ya sea una política de plataforma local o una en un proyecto diferente.
Varias verificaciones por política de plataforma
Puedes configurar varias verificaciones en cada política de la plataforma si las agregas al bloque checks de la política. Para obtener más información sobre las verificaciones específicas que puedes configurar, consulta Verificaciones.
Cuando la política de la plataforma de la CV especifica más de una verificación, las imágenes que se evalúan con una verificación se siguen evaluando con las otras verificaciones.
La Autorización Binaria evalúa todas las verificaciones configuradas en la política de la plataforma de cada imagen, a menos que la imagen coincida con un patrón de lista de entidades exentas. Para obtener más información, consulta Imágenes exentas.
Configuración de un solo proyecto
Puedes configurar la CV en un solo proyecto.
En una configuración de un solo proyecto, la Autorización Binaria configura de forma automática sus funciones necesarias 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 verificaciones residen en el mismo proyecto, no se necesitan más roles de Identity and Access Management (IAM).
Si deseas obtener más información sobre la configuración de varios proyectos para aplicar más seguridad, consulta Separación de intereses.
Configuración de varios proyectos
Cuando configuras la CV para 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 CV pueden residir en un proyecto diferente.
En la configuración de varios proyectos, es importante conocer el propósito de cada proyecto y los recursos a los que necesita acceder la CV y configurar los permisos y los roles de IAM necesarios según corresponda.
Cómo usar la CV
Para usar la CV, por lo general, debes hacer lo siguiente:
- Decide qué verificaciones deseas usar.
- Redacta una o más políticas de plataforma con un archivo YAML de política. El archivo especifica qué verificaciones deseas usar.
- Crea la política de la plataforma. La política se puede almacenar en el proyecto que elijas.
- Elige si deseas habilitar la CV en clústeres individuales o en una flota.
- Comprueba los registros de la CV en Logging para ver los eventos
- Revisa los registros y actualiza tu compilación y otros procesos para producir imágenes que cumplan con las verificaciones.
Verificaciones
En esta sección, se describen las verificaciones específicas que proporciona la CV.
Las políticas basadas en verificaciones 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 en checks y checkSets es opcional. Solo se usa cuando la CV registra los incumplimientos de política. Se omite en algunos de los ejemplos más adelante en esta guía.
Verificación de siempre denegar
La verificación de siempre denegar garantiza que todas las imágenes sujetas a esta verificación fallen la evaluación. Cada vez que la CV revisa los Pods en ejecución con esta verificación, produce una entrada de registro para cada uno de los Pods.
Puedes combinar la verificación de siempre denegar con las listas de entidades permitidas o varios conjuntos de verificaciones para asegurarte de que la Autorización Binaria siempre produzca registros para los Pods en ciertos casos.
Para usar la verificación de siempre denegar, agrega alwaysDeny: true en el bloque checks de la siguiente manera:
gkePolicy:
checkSets:
- displayName: "My check set"
checks:
- alwaysDeny: true
El valor de alwaysDeny no se puede establecer en false. En su lugar, quita la verificación.
Para ver ejemplos de cómo se puede usar la verificación de siempre denegar, consulta Usa varios conjuntos de verificación.
Verificación de actualidad de las imágenes
La verificación de actualidad de la imagen calcula la duración en la que se ejecutó una imagen y registra cuando la duración superó el umbral, maxUploadAgeDays.
En el siguiente YAML de política de plataforma de ejemplo, la CV registra los Pods con imágenes que se subieron al repositorio desde el que se implementaron hace más de 30 días.
gkePolicy:
checkSets:
checks:
- imageFreshnessCheck:
maxUploadAgeDays: 30
displayName: "My image freshness check"
displayName: "My check set"
Verificación de certificación de firma simple
Puedes usar la verificación de certificación de firma simple de la CV para verificar que cada imagen de un Pod tenga una certificación válida y firmada.
Esta verificación es equivalente a la evaluación de certificación de una política de aplicación de Autorización Binaria. Puedes configurar esta verificación con las mismas notas y claves que usaste en el certificador. Te recomendamos que uses esta verificación en lugar de la validación continua heredada.
El siguiente es un ejemplo de una política de plataforma con una verificación de certificación de firma simple:
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 los certificadores de Autorización Binaria, las verificaciones de certificación de la CV tienen autenticadores. Especifica los autenticadores directamente en la política, en el bloque attestationAuthenticators.
En una política de la plataforma, simpleSigningAttestationCheck puede tener varias attestationAuthenticators y varias claves en cada pkixPublicKeySet. La verificación se cumple cuando cada una de las imágenes de Pods tiene una certificación válida firmada con cualquier clave de pkixPublicKeySet en cualquier autenticador.
Las políticas de la plataforma de la CV se diferencian de las políticas de aplicación del proyecto único de las siguientes maneras:
- Las claves de PGP no son compatibles.
- No se necesitan certificadores. En su lugar, debes crear claves de forma manual y, luego, describe una política de la plataforma para recuperar el ID de clave que luego usas para crear la certificación.
- Crea y firma de forma manual la carga útil, crea el archivo JSON de certificación y crea la certificación mediante la API de Artifact Analysis.
- Aún creas una nota de Artifact Analysis, pero no la especificas en la política. En su lugar, la CV busca certificaciones en cada proyecto que aparece en el campo
containerAnalysisAttestationProjects. - Las certificaciones aún se almacenan en los casos de Artifact Analysis, pero se pueden almacenar en más de un proyecto.
- Debes especificar de forma explícita uno o más proyectos que contengan certificaciones mediante el nombre de recurso
projects/ATTESTATION_PROJECT_ID.
La CV no admite etiquetas de imagen, excepto las especificadas en imágenes exentas.
Si las imágenes se implementan con una etiqueta de imagen en lugar de un resumen, la CV primero la evalúa en función de imágenes exentas, ya que las listas de entidades permitidas pueden incluir etiquetas. Si la imagen no está exenta, la CV intenta encontrar el resumen de la imagen. Debido a que no hay uno, la imagen infringe la verificación.
Verificación de SLSA
La verificación de SLSA verifica la procedencia especificada por SLSA de las imágenes de los Pods.
El siguiente es un ejemplo de una configuración de YAML de la política de la plataforma de la 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 las imágenes con esta política de plataforma, comprueba lo siguiente:
Un compilador de confianza debe compilar las imágenes. Cloud Build es el único compilador de confianza que admite la verificación de SLSA.
Cloud Build debe haber generado las certificaciones en
attestation-project1oattestation-project2.Las imágenes se deben compilar con un archivo de configuración de nivel superior de cualquiera de los siguientes repositorios de confianza:
- El repositorio
source.cloud.google.com/my-project/my-source-repo/ - Cualquier repositorio en
github.com/my-github-user/
- El repositorio
Las imágenes de
gcr.io/my-images/not-built-by-GCB/o sus subdirectorios (que no fueron compilados por Cloud Build) están exentos de la verificación, ya que la infringirían.
Verificación de firma de Sigstore
La verificación de firma de Sigstore comprueba que las imágenes se hayan firmado con firmas de Sigstore.
Esta verificación solo admite imágenes alojadas en Artifact Registry. Comprueba si alguna firma recuperada de Artifact Registry se puede verificar de forma correcta a través de cualquier clave de la política.
En la siguiente política de plataforma de ejemplo, se describe cómo configurar una verificació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 varias sigstoreAuthorities y varias claves en cada publicKeySet. La verificación se cumple cuando cada una de las imágenes de Pods tiene una certificación válida firmada con cualquier clave de publicKeySet en cualquier autenticador.
Verificación del directorio de confianza
La verificación del directorio de confianza verifica que las imágenes de los Pods residan en uno de los directorios de confianza proporcionados que especifiques en la política de la plataforma.
Cuando uses esta verificación, te recomendamos que también protejas los repositorios que enumeras como directorios de confianza en tu política contra el acceso no autorizado.
En la siguiente política de plataforma de ejemplo, se describe cómo configurar una verificación de directorio 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 la plataforma de ejemplo, trustedDirPatterns enumera los directorios de confianza. Si todas las imágenes de los Pods residen en los directorios enumerados, se ajustan a la política. Las imágenes de Pods que no residen en los directorios enumerados infringen la política y la CV registra los incumplimientos.
Verificación de vulnerabilidades
La verificación de vulnerabilidades usa el análisis de vulnerabilidades de Artifact Analysis para comprobar si las imágenes de Pods contienen vulnerabilidades. Esto incluye las vulnerabilidades nuevas que se identifican mediante el análisis de vulnerabilidades desde que se implementó el Pod. En la verificación de vulnerabilidades, puedes configurar umbrales de nivel de gravedad de vulnerabilidades y vulnerabilidades específicas (como CVE). Las imágenes con vulnerabilidades que infringen la verificación de vulnerabilidades se registran en Logging.
Para usar esta verificación, primero debes habilitar el análisis de vulnerabilidades en Artifact Analysis.
El siguiente ejemplo de configuración de política de plataforma contiene una verificació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 de vulnerabilidades común (CVSS) que están asociados con cualquier vulnerabilidad que Artifact Analysis pueda identificar.
Además, blockedCves enumera las exposiciones de vulnerabilidades comunes específicas (CVE). Si una vulnerabilidad identificada excede uno de los niveles de gravedad especificados o coincide con una de las CVE enumeradas en blockedCves, y no coincide con una de las CVE enumeradas en allowedCves, entonces la CV registra una entrada de Logging.
Valida políticas actualizadas
Después de actualizar la política de la plataforma de una CV, te recomendamos que valides que la Autorización Binaria y la CV sigan funcionando como esperas.
Valida tu configuración
Para verificar tu configuración, inspecciona tus políticas de proyecto único de Autorización Binaria y políticas de plataformas de la CV.
Valida la operación
Para validar que la Autorización Binaria y la CV funcionen como esperas, puedes implementar Pods de prueba y, luego, verificar las entradas de Autorización Binaria en Logging.
Imágenes exentas con listas de entidades permitidas
Cuando creas una política de plataforma, puedes eximir a las imágenes de las verificaciones si agregas sus URL a una lista de entidades permitidas. Una lista de anunciantes permitidos a nivel de la política exime a las imágenes de toda la política. Una lista de entidades permitidas en el nivel de conjunto de verificaciones está exenta del conjunto de verificaciones y se aplica solo cuando se evalúa ese conjunto. Una lista de anunciantes permitidos dentro de una verificación exime a las imágenes solo de esa verificación.
Los patrones de listas de entidades permitidas son patrones que coinciden con una o más URL de imágenes. Un patrón de lista de entidades permitidas puede ser uno de los siguientes:
- Un prefijo del nombre de la imagen, que termina con el comodín
*o**. - Solo el nombre de una imagen, sin etiqueta ni resumen.
- Un nombre de imagen con una etiqueta (o prefijo de etiqueta con el comodín
*). - Es un nombre de imagen con un resumen.
- Un nombre de imagen con una etiqueta y un resumen.
Los siguientes son ejemplos de patrones de lista de entidades permitidas:
us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8ccoincide con un nombre de imagen, una etiqueta y un resumen exactos.us-central1.pkg.dev/my-project/my-image:latestcoincide con el nombre y la etiqueta, con cualquier resumen (o ningún resumen).us-central1.pkg.dev/my-image:foo*coincide con el nombre y el prefijo de etiqueta (comomyimage:fooymyimage:foobar), con cualquier resumen (o ningún resumen).us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8ccoincide con el nombre y el resumen, con cualquier etiqueta (o ninguna etiqueta).us-central1.pkg.dev/my-project/my-imagecoincide con el nombre, con cualquier etiqueta o resumen.
Los caracteres comodín * y ** se pueden usar para hacer coincidir cualquier nombre con un prefijo determinado. * coincide con los sufijos que no incluyen /. ** coincide con los sufijos que pueden incluir /, pero ** solo se puede usar después de /. Ten en cuenta que * y ** no se pueden usar con etiquetas o 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 resumen.
Ten en cuenta que los prefijos de nombre y los de etiqueta no deben estar vacíos. Por lo tanto, * o ** por sí solos no son patrones válidos y tampoco lo es us-central1.pkg.dev/my-image:*.
Exención a nivel de gkePolicy
En el siguiente ejemplo, se muestra cómo eximir imágenes a nivel de una política de plataforma. Todas las imágenes en los directorios exempt-images1 y exempt-images2, y sus subdirectorios se excluyen de la supervisión de la CV.
gkePolicy:
imageAllowlist:
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checkSets:
checks:
...
En la política, las imágenes que aparecen en imageAllowlist están exentas de todos los conjuntos de verificaciones (checkSets) que se enumeran en gkePolicy.
Exención a nivel de checkSet
En el siguiente ejemplo, se muestra cómo eximir imágenes a nivel del conjunto de verificación:
gkePolicy:
checkSets:
imageAllowlist:
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checks:
...
En la política, las imágenes enumeradas en imageAllowlist están exentas de todas las verificaciones que se enumeran en checkSets.
exención de nivel de verificación
En el siguiente ejemplo, se muestra cómo eximir imágenes a nivel de verificación:
gkePolicy:
checkSets:
checks:
imageAllowlist:
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
...
Usa varios conjuntos de verificación
Una política basada en verificaciones de la CV puede contener más de un conjunto de verificaciones. La CV evalúa un conjunto de verificaciones cada vez que evalúa la política. Puedes pensar en los conjuntos de verificaciones como subpolíticas que deben evaluarse en diferentes situaciones. Por ejemplo, si deseas aplicar diferentes verificaciones en entornos de desarrollo que en entornos de producción, puedes colocar las verificaciones de cada entorno en un conjunto de verificaciones separado, uno que se evalúa solo en las entorno de desarrollo, y uno que se evalúa en producción.
Cada conjunto de verificaciones tiene un alcance de un espacio de nombres de Kubernetes o una cuenta de servicio de Kubernetes. El permiso determina a qué Pods se aplica el conjunto de verificación.
Cuando se configura un conjunto de verificaciones con un permiso, solo se aplica a los Pods que se ejecutan en ese permiso.
Cuando un conjunto de verificaciones no tiene permiso, se denomina conjunto de verificaciones predeterminado, lo que significa que las verificaciones se aplican a todos los Pods, sin importar el espacio de nombres de Kubernetes o el permiso de la cuenta de servicio.
La mayoría de las políticas de ejemplo de las guías de la CV solo usan un conjunto de verificación predeterminado.
El siguiente ejemplo de configuración de política configura tres conjuntos de verificaciones:
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 verificaciones tiene un alcance de prod-namespace, por lo que sus verificaciones solo afectan a los Pods que se ejecutan en ese permiso. El segundo conjunto de verificaciones se limita a dev-namespace, por lo que sus verificaciones solo afectan a los Pods que se ejecutan en ese permiso.
El tercer conjunto de verificación es un conjunto de verificaciones predeterminado. Sus verificaciones se aplican a todos los Pods del clúster que se ejecutan fuera de los permisos prod-namespace y dev-namespace.
Cuando la CV evalúa el conjunto de verificaciones llamado Prod check set, verifica lo siguiente para las imágenes de Pods que se ejecutan en el espacio de nombres de Kubernetes prod-namespace:
- Las imágenes se almacenan en el directorio
prod-imagesde confianza. - Las imágenes se subieron en los últimos 30 días.
Cuando la CV evalúa el conjunto de verificaciones llamado Dev check set, evalúa los Pods que se ejecutan en el espacio de nombres dev-namespace de Kubernetes y verifica si las imágenes del Pod provienen del directorio dev-images.
El conjunto de verificaciones predeterminado actúa como un elemento genérico. La verificación de denegación siempre garantiza que la CV registre todos los Pods que se ejecutan en cualquier otro espacio de nombres.
Para usar una cuenta de servicio de Kubernetes como alcance de un conjunto de verificaciones, reemplaza la clave kubernetesNamespace en el ejemplo por kubernetesServiceAccount. El valor tiene el formato my-namespace:my-service-account.
Los permisos del conjunto de verificaciones tienen las siguientes reglas:
Solo puede haber un conjunto de verificaciones por permiso en una política de plataforma.
Si una política contiene conjuntos de verificación tanto con permiso de espacio de nombres como con permiso de cuenta de servicio, el conjunto de verificación con permiso de cuenta de servicio debe aparecer primero, seguido del conjunto de verificaciones con permiso de espacio de nombres.
Solo puede haber un conjunto de verificaciones predeterminado y debe enumerarse al final.
Si una política de la plataforma contiene conjuntos de verificación, debe contener al menos un conjunto de verificaciones predeterminado. Se permite una política de la plataforma sin conjuntos de verificaciones, pero como no hay verificaciones que infrinjan, la CV no produce entradas de registro.
CV heredada
En esta sección, se describen las políticas heredadas de la CV. Si es la primera vez que usas la CV, te recomendamos que uses las políticas de plataforma de la CV.
Para admitir usuarios de la CV heredados, la CV se puede habilitar en proyectos que ejecutan GKE. Luego, la CV usa la política de aplicación de la Autorización Binaria para verificar todos los Pods que se ejecutan en todos los clústeres del proyecto, incluidos los que no tienen habilitada la aplicación.
Obtén información para usar la CV heredada y ve los eventos de la CV heredados en Cloud Logging.
¿Qué sigue?
- Usa la verificación de actualidad de la imagen
- Usa la verificación de certificación de firma simple
- Usa la verificación de firma de Sigstore
- Usa la verificación de SLSA
- Usa la verificación del directorio de confianza
- Usa la verificación de vulnerabilidades
- Visualiza los registros de la CV
- Obtén información sobre la autorización binaria.