Présentation de la validation continue

La validation continue (CV) est une fonctionnalité de l'autorisation binaire qui vous permet de surveiller les pods exécutés sur Google Kubernetes Engine (GKE) pour vous assurer que leurs images de conteneur associées continuent de respecter les règles de plate-forme basées sur la vérification de l'autorisation binaire que vous spécifiez.

Lorsque l'outil CV détermine que les pods ne respectent pas les règles de plate-forme, il consigne les cas de non-respect dans Cloud Logging.

L'utilisation de CV avec règles de plate-forme remplace l'ancienne validation continue.

Pourquoi utiliser un CV ?

Bien que l'application de l'autorisation binaire fournisse des validations d'image ponctuelles lorsque vous déployez des images de conteneurs, CV surveille en permanence que les images associées aux pods en cours d'exécution continuent de respecter vos stratégies.

Pour cette raison, lorsque vous activez à la fois l'application de l'autorisation binaire et le CV avec des stratégies basées sur des vérifications, vous pouvez vous assurer que la conformité de la stratégie est validée tout au long du cycle de vie de l'orchestration.

La CV est utile dans les scénarios suivants :

Modifications des stratégies: lorsque vous mettez à jour les stratégies d'application de projet-singleton de l'autorisation binaire, l'autorisation binaire valide uniquement les images déployées après la mise à jour. Les pods en cours d'exécution ne sont pas affectés. Elles continuent de s'exécuter même si l'autorisation binaire, à l'aide de la stratégie mise à jour, bloque désormais le déploiement de la même image.

Pour cette raison, lorsque vous mettez à jour la stratégie d'autorisation binaire de projet-singleton, nous vous recommandons également de créer ou de mettre à jour une stratégie de plate-forme de CV pour qu'elle corresponde à la stratégie de singleton de projet. De cette façon, le CV vous informe des pods en cours d'exécution qui ne respectent pas vos règles mises à jour.
Surveiller les métadonnées d'image: le CV permet de vérifier spécifiquement les modifications apportées aux métadonnées d'image, y compris les suivantes:
- Attestations: les journaux CV sont consignés lorsque les attestations sur les images des pods ne sont plus valides.
- Fraîcheur: le CV est consigné dans le journal lorsqu'il détecte que les images des pods ne sont plus à jour.
- Provenance: le CV peut vérifier que les images des pods ont été créées avec un compilateur de confiance, à l'aide de configurations de compilation qui résident dans un dépôt source approuvé.
- Répertoire de confiance: les journaux CV sont consignés lorsque les images des pods résident dans un répertoire de dépôt non répertorié dans votre stratégie de plate-forme.
- Vulnerabilities (Failles) : le CV est consigné lorsque des failles sont identifiées dans les images des pods.
Surveillance de la simulation: lorsque vous activez la simulation, l'autorisation binaire autorise le déploiement de toutes les images. En activant le CV avec une règle de plate-forme correspondant à votre stratégie de projet Singleton, CV enregistre régulièrement les images qui ne respectent pas la règle de plate-forme.
Surveillance en mode "bris de glace": lorsque vous déployez des pods à l'aide du mode bris de glace, l'autorisation binaire contourne l'application de la stratégie du singleton du projet et consigne un seul événement dans Cloud Audit Logs. Toutefois, si une règle de plate-forme correspondante est utilisée, le CV continue de consigner régulièrement les pods qui ne respectent pas les règles, y compris les pods déployés à l'aide du mode "bris de glace".

Fonctionnement du CV

Pour utiliser CV, vous devez l'activer sur vos clusters GKE.

Une fois que vous avez déployé des images sur votre cluster, CV surveille les pods associés pour s'assurer qu'ils sont conformes à votre règle de plate-forme basée sur les vérifications.

CV n'accepte pas les tags d'image autres que ceux spécifiés dans la section Images exclues.

Le CV vérifie régulièrement les pods en cours d'exécution

Pour surveiller les pods en cours d'exécution, le CV examine les images associées à chaque pod au moins toutes les 24 heures. CV surveille également les conteneurs init.

À chaque examen, CV récupère une liste d'images associées à chaque pod. CV vérifie ensuite que les informations de l'image sont conformes à la règle de plate-forme.

Non-respect du règlement de la plate-forme dans les journaux CV

Lorsque l'outil CV détermine que des images ne respectent pas les règles de plate-forme, il consigne les cas de non-respect et d'autres résultats dans Cloud Logging.

Lorsque CV évalue les images d'un pod à l'aide d'une règle de plate-forme, ces images peuvent répondre à certaines vérifications et en violer d'autres. CV génère une entrée de journal chaque fois que les images d'un pod ne respectent pas une ou plusieurs vérifications.

Si toutes les images satisfont à toutes les vérifications, aucune entrée de journal n'est générée.

Jusqu'à l'arrêt d'un pod contenant des images non conformes aux règles, le CV continue à consigner les cas de non-respect des règles. Les pods non conformes aux règles qui sont arrêtés pendant l'intervalle entre les vérifications sont enregistrés lors de l'examen suivant du CV.

La CV n'arrête pas les pods en cours d'exécution.

Le CV utilise une ressource de flux

Pour récupérer des informations sur les pods exécutés sur votre cluster GKE, CV crée une ressource de flux appelée binauthz-cv-cai-feed.

Règles de la plate-forme CV

Pour utiliser le CV, vous devez d'abord configurer des règles de plate-forme.

Les règles de plate-forme sont différentes des anciennes stratégies d'autorisation binaire, également appelées règles de singleton. Bien que le projet de déploiement ne puisse avoir qu'une seule ancienne règle de projet-singleton, vous pouvez configurer plusieurs règles de plate-forme. Chaque règle de plate-forme peut résider dans un ou plusieurs projets.

Les règles de plate-forme ne fonctionnent qu'avec le CV et ne sont pas compatibles avec l'application de l'autorisation binaire. C'est pourquoi nous vous recommandons de créer une règle de singleton de projet pour l'application et une règle de plate-forme pour la surveillance si vous souhaitez utiliser à la fois l'application de l'autorisation binaire et la surveillance CV.

Par exemple, supposons que vous souhaitiez configurer l'autorisation binaire pour s'assurer que vos images disposent d'une attestation avant qu'elles ne soient autorisées à être déployées, et que vous souhaitiez également vous assurer que vos pods en cours d'exécution sont conformes à la même exigence. Pour ce faire, configurez une stratégie d'application de projet-singleton avec un certificateur. Vous allez ensuite créer une stratégie de plate-forme avec une vérification d'attestation de signature simple. Celle-ci dispose d'un authentificateur basé sur la même note et la même clé publique que le certificateur.

Les règles de la plate-forme sont spécifiques à une plate-forme. GKE est la seule plate-forme compatible.

Vous pouvez configurer des vérifications dans les règles de plate-forme. Les vérifications sont regroupées en un ou plusieurs ensembles de vérifications. Chaque ensemble de vérifications peut spécifier une ou plusieurs vérifications.

Les stratégies de plate-forme peuvent exempter des images de l'évaluation par CV.

Autorisations requises

Pour répertorier ou décrire les règles de plate-forme, vous devez disposer du rôle binaryauthorization.policyViewer. Pour créer, modifier et supprimer des stratégies de plate-forme, vous devez disposer du rôle binaryauthorization.policyEditor. Pour en savoir plus, consultez Gérer les règles de plate-forme.

Modifications apportées aux règles

La mise à jour d'une règle de plate-forme écrase la stratégie existante par un descripteur de stratégie que vous fournissez dans le fichier YAML. Pour ajouter une vérification à une règle de plate-forme existante, nous vous recommandons de décrire la stratégie existante, de l'enregistrer dans un fichier YAML, d'ajouter la nouvelle vérification, puis de la mettre à jour à l'aide du fichier mis à jour.

Règles applicables à plusieurs plates-formes

Vous pouvez créer des règles de plate-forme dans le même projet que le cluster (une règle de plate-forme locale) ou dans tout autre projet.

Étant donné que vous pouvez configurer un certain nombre de règles de plate-forme, vous devez nommer chacune d'elles avec un nom de ressource unique. Lorsque vous exécutez une commande de gcloud CLI, vous faites référence à la règle de plate-forme locale à l'aide de son ID. Lorsque vous faites référence à une règle de plate-forme dans un autre projet, vous utilisez le nom de la ressource au format suivant : projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

Vous pouvez choisir la règle de plate-forme à associer à chaque cluster GKE, qu'il s'agisse d'une règle de plate-forme locale ou d'une règle d'un projet différent.

Vérifications multiples par règle de plate-forme

Vous pouvez configurer plusieurs vérifications dans chaque règle de plate-forme en les ajoutant au bloc checks de la règle. Pour en savoir plus sur les vérifications spécifiques que vous pouvez configurer, consultez la section Vérifications.

Lorsque votre règle de plate-forme de CV spécifie plusieurs vérifications, les images évaluées par une vérification continuent de l'être par les autres vérifications.

L'autorisation binaire évalue toutes les vérifications configurées dans la stratégie de plate-forme pour chaque image, sauf si l'image correspond à un modèle de liste d'autorisation d'images exemptées. Pour en savoir plus, consultez Exclure des images.

Configuration d'un seul projet

Vous pouvez configurer un CV dans un seul projet.

Dans une configuration à projet unique, l'autorisation binaire définit automatiquement ses rôles requis dans l'agent de service de l'autorisation binaire.

Si les clusters GKE, les stratégies de plate-forme qui y sont liées et les métadonnées requises par les vérifications se trouvent tous dans le même projet, aucun rôle IAM (Identity and Access Management) supplémentaire n'est requis.

Pour en savoir plus sur la configuration d'une configuration multiprojet pour plus de sécurité, consultez la page Séparation des tâches.

Configuration multiprojets

Lorsque vous configurez une configuration de CV multiprojets avec des règles de plate-forme, la stratégie de plate-forme, les images, le cluster GKE et d'autres types de ressources dépendantes du CV peuvent se trouver dans un projet différent.

Dans une configuration multiprojet, il est important de connaître l'objectif de chaque projet et les ressources auxquelles CV a besoin pour accéder, et de configurer les rôles et autorisations IAM requis en conséquence.

Comment utiliser un CV ?

Pour utiliser CV, procédez comme suit:

Choisissez les vérifications que vous souhaitez utiliser.
Rédigez une ou plusieurs règles de plate-forme à l'aide d'un fichier YAML de stratégie. Ce fichier spécifie les vérifications que vous souhaitez utiliser.
Créez la règle de plate-forme. La règle peut être stockée dans le projet de votre choix.
Créez un cluster ou mettez à jour un cluster existant avec l'autorisation binaire et le CV activés pour utiliser les stratégies de plate-forme.
Vérifiez les événements des journaux CV dans Logging.
Examinez les journaux et mettez à jour votre build et d'autres processus pour produire des images satisfaisant aux vérifications.

Chèques

Cette section décrit les vérifications spécifiques fournies par un CV.

Les règles basées sur des vérifications ont le format canonique suivant:

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

Le champ displayName dans checks et checkSets est facultatif. Il n'est utilisé que lorsque CV enregistre les cas de non-respect des règles. Elle est omise dans certains exemples plus loin dans ce guide.

Toujours refuser

La vérification Always-deny garantit que toutes les images soumises à cette vérification échouent à l'évaluation. Chaque fois que le CV examine les pods en cours d'exécution avec cette vérification, il génère une entrée de journal pour chacun des pods.

Vous pouvez combiner la vérification toujours refusée avec des listes d'autorisation ou plusieurs ensembles de vérification pour vous assurer que l'autorisation binaire génère toujours des journaux pour les pods dans certains cas.

Pour utiliser la vérification Always-deny, ajoutez alwaysDeny: true dans le bloc checks, comme suit:

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

Impossible de définir la valeur de alwaysDeny sur false. Supprimez plutôt la coche.

Pour obtenir des exemples d'utilisation de la vérification Always-deny, consultez la section Utiliser plusieurs ensembles de vérification.

Vérification de l'actualisation de l'image

La vérification de l'actualisation de l'image calcule la durée d'exécution d'une image et consigne quand cette durée dépasse le seuil, maxUploadAgeDays.

Dans l'exemple de stratégie de plate-forme suivant, CV enregistre les pods avec des images importées dans le dépôt à partir duquel ils ont été déployés il y a plus de 30 jours.

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

Vérification simple des attestations de signature

Vous pouvez utiliser la vérification d'attestation de signature simple du CV pour vérifier que chacune des images d'un pod possède une attestation valide et signée.

Cette vérification est équivalente à l'évaluation d'attestation dans une stratégie d'application de l'autorisation binaire. Vous pouvez configurer cette vérification avec les mêmes notes et clés que celles utilisées dans votre certificateur. Nous vous recommandons d'utiliser cette vérification plutôt que l'ancienne validation continue.

Voici un exemple de règle de plate-forme avec un contrôle d'attestation de signature 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

Au lieu des certificateurs d'autorisation binaire, les vérifications d'attestation de CV disposent d'authentificateurs. Vous spécifiez les authentificateurs directement dans la règle, dans le bloc attestationAuthenticators.

Dans la règle de plate-forme, simpleSigningAttestationCheck peut comporter plusieurs attestationAuthenticators et plusieurs clés dans chaque pkixPublicKeySet. La vérification est effectuée lorsque chacune des images des pods dispose d'une attestation valide signée avec n'importe quelle clé dans n'importe quel authentificateur pkixPublicKeySet.

Les règles de la plate-forme CV sont différentes des règles d'application de singleton de projet sur les points suivants:

Les clés PGP ne sont pas compatibles.
Les certificateurs ne sont pas nécessaires. À la place, vous devez créer des clés manuellement, puis décrire la règle de plate-forme pour récupérer l'ID de clé que vous utiliserez ensuite pour créer l'attestation.
Vous créez et signez manuellement la charge utile, créez le fichier JSON d'attestation, puis créez l'attestation à l'aide de l'API Artifact Analysis.
Vous créez toujours une note d'analyse d'artefacts, mais vous ne la spécifiez pas dans la règle. À la place, CV recherche des attestations dans chaque projet répertorié dans le champ containerAnalysisAttestationProjects.
Les attestations sont toujours stockées dans des occurrences Artifact Analysis, mais elles peuvent être stockées dans plusieurs projets.
Vous devez spécifier explicitement un ou plusieurs projets contenant des attestations à l'aide du nom de ressource projects/ATTESTATION_PROJECT_ID.

CV n'est pas compatible avec les tags d'image, à l'exception de ceux spécifiés dans les images exemptées.

Si les images sont déployées avec un tag d'image au lieu d'un condensé, CV les évalue d'abord par rapport aux images exclues, car les listes d'autorisation peuvent inclure des tags. Si l'image n'est pas exemptée, le CV tente de trouver le condensé de l'image. Comme il n'y en a pas, l'image enfreint la vérification.

Vérification SLSA

La vérification SLSA vérifie la origine spécifiée par le framework SLSA des images des pods.

Voici un exemple de configuration YAML d'une stratégie de plate-forme 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"

Lorsque CV examine des images à l'aide de cette règle de plate-forme, il vérifie les éléments suivants:

Les images doivent avoir été créées par un créateur de confiance. Cloud Build est le seul compilateur de confiance compatible avec la vérification SLSA.
Cloud Build doit avoir généré les attestations dans attestation-project1 ou attestation-project2.
Les images doivent être créées à l'aide d'un fichier de configuration de premier niveau provenant de l'un des dépôts de confiance suivants:
- Le dépôt source.cloud.google.com/my-project/my-source-repo/
- Tous les dépôts de github.com/my-github-user/
Les images de gcr.io/my-images/not-built-by-GCB/ ou de ses sous-répertoires (qui n'ont pas été créées par Cloud Build) sont exemptées de la vérification, car elles enfreignent cette règle.

Vérification de l'annuaire de confiance

La vérification du répertoire de confiance vérifie que les images des pods résident dans un ou plusieurs répertoires de confiance que vous spécifiez dans la règle de plate-forme.

Lorsque vous utilisez cette vérification, nous vous recommandons également de protéger les dépôts que vous répertoriez comme répertoires de confiance dans votre stratégie contre les accès non autorisés.

L'exemple de règle de plate-forme suivant explique comment configurer une vérification d'un annuaire de confiance:

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"

Dans l'exemple de règle de plate-forme, trustedDirPatterns répertorie les répertoires de confiance. Si toutes les images des pods se trouvent dans les répertoires répertoriés, elles sont conformes à la stratégie. Les images de pods qui ne résident pas dans les répertoires répertoriés enfreignent la règle, et CV consigne les cas de non-respect.

Vérification des failles

Cette fonctionnalité utilise l'analyse des failles d'Artifact Analysis pour vérifier si les images des pods contiennent des failles. Cela inclut les nouvelles failles identifiées par l'analyse des failles depuis le déploiement du pod. Dans la vérification des failles, vous pouvez configurer des seuils de niveau de gravité des failles et des failles spécifiques (en tant que failles CVE). Les images présentant des failles qui enfreignent la vérification des failles sont consignées dans Logging.

Pour utiliser cette vérification, vous devez d'abord activer l'analyse des failles dans Artifact Analysis.

L'exemple de configuration de règle de plate-forme suivant contient une vérification des failles:

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"

Dans l'exemple, maximumUnfixableSeverity et maximumFixableSeverity définissent les niveaux de gravité CVSS (Common Vulnerability Scoring System) associés à toute faille que Artifact Analysis peut identifier. En outre, blockedCves répertorie des expositions CVE spécifiques à des failles courantes. Si une faille identifiée dépasse l'un des niveaux de gravité spécifiés ou correspond à l'une des failles CVE répertoriées dans blockedCves, et qu'elle ne correspond pas à l'une des failles CVE répertoriées dans allowedCves, CV enregistre une entrée dans Logging.

Valider les règles mises à jour

Après avoir mis à jour la stratégie de plate-forme de CV, nous vous recommandons vivement de vérifier que l'autorisation binaire et le CV continuent de fonctionner comme prévu.

Valider votre configuration

Pour vérifier votre configuration, inspectez vos stratégies d'autorisation binaire project-singleton et vos règles de plate-forme de CV.

Valider l'opération

Pour vérifier que l'autorisation binaire et le CV fonctionnent comme prévu, vous pouvez déployer des pods de test, puis vérifier les entrées d'autorisation binaire dans Logging.

Exclure des images grâce aux listes d'autorisation

Lorsque vous créez une règle de plate-forme, vous pouvez exclure des images des vérifications en ajoutant leurs URL à une liste d'autorisation. Une liste d'autorisation au niveau de la règle exclut les images de l'ensemble de la règle. Une liste d'autorisation au niveau de l'ensemble de vérifications est exemptée de l'ensemble de vérifications et ne s'applique que lorsque cet ensemble de vérifications est évalué. Une liste d'autorisation au sein d'un test exempte les images uniquement de cette vérification.

Les formats de liste d'autorisation sont des formats qui correspondent à une ou plusieurs URL d'image. Voici les formats possibles:

Préfixe de nom d'image se terminant par le caractère générique * ou **.
Il s'agit simplement d'un nom d'image, sans tag ni condensé.
Un nom d'image avec un tag (ou un préfixe de tag avec le caractère générique *)
Nom d'image avec un condensé.
Nom d'image avec un tag et un condensé.

Voici des exemples de formats de liste d'autorisation:

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c correspond à un nom d'image, à un tag et à un condensé exacts.
us-central1.pkg.dev/my-project/my-image:latest correspond au nom et au tag, avec n'importe quel condensé (ou aucun).
us-central1.pkg.dev/my-image:foo* correspond au nom et au préfixe du tag (par exemple, myimage:foo et myimage:foobar), avec n'importe quel condensé (ou aucun).
us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c établit une correspondance avec le nom et le condensé, avec n'importe quel tag (ou aucune balise).
us-central1.pkg.dev/my-project/my-image correspond au nom, avec n'importe quel tag et/ou condensé.

Les caractères génériques * et ** peuvent être utilisés pour établir une correspondance avec n'importe quel nom comportant un certain préfixe. * correspond aux suffixes qui n'incluent pas /. ** correspond aux suffixes qui peuvent inclure /, mais ** ne peut être utilisé qu'après /. Notez que * et ** ne peuvent pas être utilisés avec des tags ou des condensés.

Exemple :

us-central1.pkg.dev/my-project/my-image* correspond à us-central1.pkg.dev/myproject/my-image, us-central1.pkg.dev/myproject/my-image1 et us-central1.pkg.dev/myproject/my-image2 avec n'importe quel tag et/ou condensé.
us-central1.pkg.dev/my-project/** correspond à us-central1.pkg.dev/myproject/my-image et us-central1.pkg.dev/my-project/some-directory/other-image, avec n'importe quel tag et/ou condensé.

Notez que les préfixes de nom et de tag ne doivent pas être vides. Ainsi, * ou ** seuls n'est pas un modèle valide, pas plus que us-central1.pkg.dev/my-image:*.

Exception au niveau gkePolicy

L'exemple suivant vous montre comment exempter des images au niveau des règles de plate-forme. Toutes les images des répertoires exempt-images1 et exempt-images2 et de leurs sous-répertoires sont exclues de la surveillance 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:
        ...

Dans cette stratégie, les images répertoriées sous imageAllowlist sont exemptées de tous les ensembles de vérification (checkSets) répertoriés sous gkePolicy.

Exemption au niveau de CheckSet

L'exemple suivant montre comment exempter des images au niveau de l'ensemble de contrôle:

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:
      ...

Dans cette stratégie, les images répertoriées sous imageAllowlist sont exemptées de toutes les vérifications répertoriées sous checkSets.

exception au niveau des vérifications

L'exemple suivant montre comment exempter des images au niveau de la vérification:

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/**"
      ...

Utiliser plusieurs jeux de vérification

Une stratégie basée sur la vérification de CV peut contenir plusieurs jeux de contrôle. Le CV évalue une vérification définie chaque fois qu'il évalue la stratégie. Vous pouvez considérer les ensembles de vérification comme des sous-règles qui doivent être évaluées dans différentes situations. Par exemple, si vous souhaitez appliquer des vérifications différentes dans les environnements de développement et de production, vous pouvez placer les vérifications pour chaque environnement dans un ensemble de vérifications distinct, qui n'est évalué que dans l'environnement de développement et un autre qui est évalué en production.

Chaque ensemble de vérifications est limité à un espace de noms Kubernetes ou à un compte de service Kubernetes. Le champ d'application détermine les pods auxquels l'ensemble de contrôle s'applique.

Lorsqu'un ensemble de vérification est configuré avec un champ d'application, il ne s'applique qu'aux pods exécutés dans ce champ d'application.

Lorsqu'un ensemble de vérification n'a pas de champ d'application, on parle d'ensemble de vérification par défaut, ce qui signifie que les vérifications s'appliquent à tous les pods, quel que soit le champ d'application de leur espace de noms Kubernetes ou de leur compte de service.

La plupart des exemples de règles présentés dans les guides sur le CV n'utilisent qu'un ensemble de vérification par défaut.

L'exemple de configuration de stratégie suivant configure trois ensembles de vérification:

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

Dans l'exemple de configuration, le premier ensemble de vérification est limité à prod-namespace. Ses vérifications n'affectent donc que les pods exécutés dans ce champ d'application. Le deuxième est le champ d'application de dev-namespace. Par conséquent, ses vérifications n'affectent que les pods exécutés dans ce champ d'application. Le troisième jeu de contrôle est un jeu de contrôle par défaut. Ses vérifications s'appliquent à tous les pods du cluster exécutés en dehors des champs d'application prod-namespace et dev-namespace.

Lorsque CV évalue l'ensemble de vérifications appelé Prod check set, il vérifie les images suivantes de pods s'exécutant dans l'espace de noms Kubernetes prod-namespace:

Les images sont stockées dans le répertoire prod-images de confiance.
Les images ont été importées au cours des 30 derniers jours.

Lorsque CV évalue l'ensemble de vérifications appelé Dev check set, il évalue les pods exécutés dans l'espace de noms Kubernetes dev-namespace, en vérifiant si les images du pod proviennent du répertoire dev-images.

L'ensemble de contrôle par défaut sert d'alias collecteur. La vérification Always-deny garantit que CV enregistre tous les pods qui s'exécutent dans n'importe quel autre espace de noms.

Pour utiliser un compte de service Kubernetes comme champ d'application d'un ensemble de vérifications, remplacez la clé kubernetesNamespace dans l'exemple par kubernetesServiceAccount. La valeur est au format my-namespace:my-service-account.

Les champs d'application de l'ensemble de vérifications sont soumis aux règles suivantes:

Il ne peut y avoir qu'une seule vérification par champ d'application dans une règle de plate-forme.
Si une règle contient des ensembles de vérifications à l'échelle d'un espace de noms et à l'échelle d'un compte de service, celui-ci doit être répertorié en premier, suivi de celui à l'échelle d'un espace de noms.
Il ne peut y avoir qu'une seule vérification par défaut, et celle-ci doit être répertoriée en dernier.

Si une règle de plate-forme contient des ensembles de vérification, elle doit contenir au moins un ensemble de vérification par défaut. Une règle de plate-forme sans ensemble de vérification est autorisée, mais comme il n'y a aucune vérification à enfreindre, CV ne génère aucune entrée de journal.

Ancien CV

Cette section décrit les anciennes règles relatives aux cryptogrammes. Si vous débutez, nous vous recommandons d'utiliser plutôt les règles de plate-forme de CV.

Pour les anciens utilisateurs de CV, vous pouvez l'activer sur les projets qui exécutent GKE. CV utilise ensuite la stratégie d'application de l'autorisation binaire pour vérifier tous les pods exécutés sur tous les clusters du projet, y compris les clusters pour lesquels l'application de l'autorisation binaire n'est pas activée.

Découvrez comment utiliser l'ancien CV et afficher les événements de l'ancien CV dans Cloud Logging.