Présentation de la validation continue

La validation continue (CV) avec des règles de plate-forme basées sur les vérifications est une fonctionnalité de l'autorisation binaire qui vous permet de surveiller les pods exécutés sur Google Kubernetes Engine (GKE) afin de vous assurer que les images de conteneurs 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 la CV détermine que les pods ne respectent pas les règles de plate-forme, elle consigne les cas de non-respect dans Cloud Logging.

La CV avec règles de plate-forme remplace l'ancienne validation continue (obsolète).

Pourquoi utiliser la CV ?

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

Par conséquent, lorsque vous activez à la fois l'application de l'autorisation binaire et la CV avec des règles basées sur des vérifications, vous pouvez vous assurer que la conformité avec les règles est validée tout au long du cycle de vie de l'orchestration.

La CV est utile dans les scénarios suivants :

  • Modifications des règles : lorsque vous mettez à jour vos règles d'application Singleton de projet pour l'autorisation binaire, cette dernière valide uniquement les images déployées après la mise à jour. Les pods déjà en cours d'exécution ne sont pas affectés. Ils continueront de s'exécuter même si l'autorisation binaire bloque désormais le déploiement de la même image du fait de la stratégie mise à jour.

    Par conséquent, lorsque vous mettez à jour la règle Singleton de projet d'autorisation binaire, nous vous recommandons également de créer ou de mettre à jour une règle de plate-forme de CV pour qu'elle corresponde à la règle Singleton de projet. Ainsi, la CV vous informe si des pods en cours d'exécution ne respectent pas vos règles mises à jour.

  • Métadonnées d'image Monitoring : la CV fournit des vérifications spécifiques pour détecter les modifications apportées aux métadonnées d'image, y compris les suivantes :

    • Attestations : la CV journalise les attestations sur les images de pods qui ne sont plus valides.
    • Fraîcheur : la CV journalise les images des pods qui ne sont plus à jour.
    • Provenance : la CV peut vérifier que les images des pods ont été créées avec un compilateur de confiance, avec des configurations de compilation hébergées dans un dépôt source de confiance.
    • Signatures Sigstore : la CV journalise les images des pods ne comportant pas de signature Sigstore valide.
    • Répertoire de confiance : la CV journalise les images des pods se trouvant dans un répertoire de dépôt qui n'est pas répertorié dans votre règle de plate-forme.
    • Failles : la CV journalise les failles identifiées dans les images de pod.

  • Surveillance des "dry run" (test à blanc) : lorsque vous activez le dry run, l'autorisation binaire permet le déploiement de toutes les images. En activant la CV avec une règle de plate-forme correspondant à votre règle Singleton de projet, la CV journalise régulièrement les images qui ne respectent pas la règle de plate-forme.

  • Surveillance de type "bris de glace" : lorsque vous déployez des pods à l'aide du mode bris de glace, l'autorisation binaire contourne l'application des règles Singleton de projet et journalise un seul événement dans Cloud Audit Logs. Toutefois, en utilisant une règle de plate-forme correspondante, la CV continue de journaliser régulièrement les pods qui ne respectent pas les règles, y compris ceux déployés à l'aide du mode "bris de glace".

Fonctionnement de la CV

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

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

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

La CV examine régulièrement les pods en cours d'exécution

Pour surveiller les pods en cours d'exécution, la CV examine les images associées à chaque pod au moins toutes les 24 heures. La CV surveille également les conteneurs d'initialisation et les conteneurs éphémères.

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

La CV consigne les cas de non-respect des règles de plate-forme

Lorsque la CV détermine que les images ne respectent pas les règles de plate-forme, elle journalise les violations et autres résultats dans Cloud Logging. Une entrée de journal distincte est écrite pour chaque règle de plate-forme non respectée, pour chaque pod.

Lorsque la CV évalue les images d'un pod eu égard aux règles de plate-forme, les images peuvent satisfaire à certaines vérifications et en enfreindre d'autres. La CV génère une entrée de journal chaque fois qu'une image d'un pod enfreint une vérification. L'entrée de journal ne contient que les images de pod qui ne respectent pas les règles de plate-forme. Si toutes les images satisfont à toutes les vérifications, aucune entrée de journal n'est générée.

La CV continue à consigner les cas de non-respect des règles jusqu'à l'arrêt d'un pod avec des images non conformes aux règles. Lorsque des pods non conformes aux règles sont arrêtés pendant l'intervalle entre les validations, les entrées de journal générées par la CV peuvent apparaître après l'arrêt, lors de la prochaine évaluation de la CV.

Les pods non conformes aux règles doivent être consignés au moins une fois, même pour les pods de courte durée.

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

La CV utilise une ressource de flux

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

Règles de plate-forme CV

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

Les règles de plate-forme sont différentes des anciennes règles d'autorisation binaire, également appelées règles Singleton du projet. Bien que le projet de déploiement ne puisse comporter qu'une seule ancienne règle Singleton de projet, 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 la CV et ne sont pas compatibles avec l'application de l'autorisation binaire. Pour cette raison, si vous souhaitez utiliser à la fois l'application de l'autorisation binaire et la surveillance CV, vous devez créer une règle Singleton de projet pour l'application et une règle de plate-forme pour la surveillance.

Par exemple, supposons que vous souhaitiez configurer l'autorisation binaire pour vous assurer que vos images disposent d'une attestation avant d'être autorisées à être déployées, et que vous souhaitez également vous assurer que vos pods en cours d'exécution se conforment à la même configuration. Pour ce faire, vous devez configurer une règle d'application Singleton de projet avec un certificateur. Vous créez ensuite une règle de plate-forme avec une vérification d'attestation de signature simple. Elle dispose d'un authentificateur basé sur la même note et la même clé publique que le certificateur.

Les règles de plate-forme sont spécifiques à la 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 dans un ou plusieurs ensembles de vérifications. Chaque ensemble de vérifications peut spécifier une ou plusieurs vérifications.

Les règles de plate-forme peuvent exclure les 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 règles de plate-forme, vous devez disposer du rôle binaryauthorization.policyEditor. Pour en savoir plus, consultez la page Gérer les règles de plate-forme.

Mises à jour des règles

La mise à jour d'une règle de plate-forme écrase la règle existante avec un descripteur de règle 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 règle existante, de l'enregistrer dans un fichier YAML, d'ajouter la nouvelle vérification, puis de mettre à jour la règle à l'aide du fichier mis à jour.

Plusieurs règles de plate-forme

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 attribuer à chacune un nom de ressource unique. Lorsque vous exécutez une commande gcloud CLI, vous faites référence à la règle de plate-forme locale en utilisant 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 de plate-forme dans un projet différent.

Plusieurs vérifications 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 la règle de plate-forme CV spécifie plusieurs vérifications, les images évaluées par une vérification continuent d'être évaluées par les autres vérifications.

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

Configuration à projet unique

Vous pouvez configurer la CV dans un projet unique.

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

Si les clusters GKE, les règles de plate-forme liées aux clusters et les métadonnées requises par les vérifications résident dans le même projet, aucun rôle supplémentaire de gestion de l'authentification et des accès (IAM) n'est nécessaire.

Pour en savoir plus sur la création d'une configuration multiprojets afin d'accroître la sécurité, consultez la page Séparation des tâches.

Configuration multiprojets

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

Dans une configuration multiprojets, il est important de connaître l'objectif de chaque projet ainsi que les ressources auxquelles la CV doit accéder et de configurer les rôles et autorisations IAM requis en conséquence.

Comment utiliser la CV

Pour utiliser la CV, procédez comme suit :

  1. Choisissez les vérifications que vous souhaitez utiliser.
  2. Composez une ou plusieurs règles de plate-forme à l'aide d'un fichier YAML de règle. Ce fichier spécifie les vérifications que vous souhaitez utiliser.
  3. Créez la règle de plate-forme. Vous pouvez stocker la règle dans le projet de votre choix.
  4. Choisissez d'activer la CV sur des clusters individuels ou sur un parc.
  5. Consultez les journaux de la CV dans Logging pour voir les événements.
  6. Examinez les journaux et mettez à jour votre compilation ainsi que vos autres processus pour produire des images conformes aux vérifications.

Chèques

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

Les règles basées sur des vérifications utilisent 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 la CV journalise les cas de non-respect des règles. Elle est omise dans certains exemples ci-après.

Vérification avec refus systématique

La vérification avec refus systématique garantit que toutes les images soumises à cette vérification échouent. Chaque fois que la CV examine des pods en cours d'exécution avec cette vérification, elle génère une entrée de journal pour chacun des pods.

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

Pour utiliser la vérification avec refus systématique, ajoutez alwaysDeny: true dans le bloc checks, comme suit :

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

La valeur de alwaysDeny ne peut pas être définie sur false. Supprimez plutôt la coche.

Pour obtenir des exemples d'utilisation de la vérification avec refus systématique, consultez la page Utiliser plusieurs ensembles de vérification.

Vérification de la fraîcheur des images

La vérification de la fraîcheur des images calcule la durée d'exécution d'une image et crée une entrée de journal lorsque cette durée a dépassé le seuil, maxUploadAgeDays.

Dans l'exemple de règle de plate-forme YAML suivant, la CV journalise les pods contenant des images qui ont été importées il y a plus de 30 jours dans le dépôt à partir duquel elles ont été déployées.

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

Vérification d'attestation de signature simple

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

Cette vérification est équivalente à l'évaluation d'attestation dans une règle d'application d'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 au lieu de l'ancienne validation continue (obsolète).

Voici un exemple de règle de plate-forme avec une vérification 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 CV utilisent des authenticators. Vous spécifiez les authentificateurs directement dans la règle, dans le bloc attestationAuthenticators.

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

Les règles de plate-forme CV diffèrent des règles d'application Singleton de projet par les points suivants :

  • Les clés PGP ne sont pas prises en charge.
  • Les certificateurs ne sont pas nécessaires. Au lieu de cela, vous créez manuellement des clés, puis décrivez 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 et créez l'attestation à l'aide de l'API Artifact Analysis.
  • Vous créez toujours une note Artifact Analysis, mais vous ne la spécifiez pas dans la règle. Au lieu de cela, la CV recherche des attestations dans chaque projet répertorié dans le champ containerAnalysisAttestationProjects.
  • Les attestations sont toujours stockées dans les 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.

La CV n'accepte pas les tags d'image, à l'exception de ceux spécifiés dans les images exclues.

Si les images sont déployées avec un tag d'image au lieu d'un condensé, la 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 exclue, la CV tente de trouver le condensé de l'image. Comme il n'y en a pas, l'image échoue à la vérification.

Vérification SLSA

La vérification SLSA vérifie la provenance spécifiée par la certification SLSA dans les images des pods.

Voici un exemple de configuration YAML de règle de plate-forme 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 la CV examine les images à l'aide de cette règle de plate-forme, elle vérifie les éléments suivants :

  • Les images doivent avoir été créées par un compilateur de confiance. Cloud Build est le seul compilateur de confiance accepté par 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 à partir 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 dans github.com/my-github-user/

  • Les images dans gcr.io/my-images/not-built-by-GCB/ ou ses sous-répertoires (qui n'ont pas été créés par Cloud Build) sont exclues de la vérification, car elles échoueraient.

Vérification de signature Sigstore

La vérification de signature Sigstore vérifie que les images ont été signées à l'aide de signatures Sigstore.

Cette vérification n'est possible que pour les images hébergées dans Artifact Registry. Il vérifie si une signature extraite d'Artifact Registry peut être validée par une clé de la règle.

L'exemple de règle de plate-forme suivant montre comment configurer une vérification de signature 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-----

Dans la règle de plate-forme, sigstoreSignatureCheck peut avoir plusieurs sigstoreAuthorities et plusieurs clés dans chaque publicKeySet. La vérification est satisfaite lorsque chacune des images des pods possède une attestation signée valide avec n'importe laquelle des clés dans n'importe quel publicKeySet d'authentificateur.

Vérification du répertoire de confiance

La vérification du répertoire de confiance permet de vérifier que les images des pods se trouvent dans l'un des répertoires de confiance fournis que vous spécifiez dans une 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 des répertoires de confiance dans votre règle contre les accès non autorisés.

L'exemple de règle de plate-forme suivant montre comment configurer une vérification de répertoire 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 listés, elles sont conformes à la règle. Les images de pods qui ne se trouvent pas dans les répertoires listés ne respectent pas la règle, et la CV journalise les violations.

Vérification des failles

La vérification des failles utilise l'analyse des failles 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 (sous forme de codes CVE). Les images présentant des failles qui ne respectent pas la vérification sont journalisé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 de failles courantes (CVE) spécifiques. Si une faille identifiée dépasse l'un des niveaux de gravité spécifiés ou correspond à l'une des CVE répertoriées dans blockedCves, et qu'elle ne correspond pas à l'une des CVE répertoriées dans allowedCves, la CV consigne une entrée dans Logging.

Valider les règles mises à jour

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

Vérifier votre configuration

Pour vérifier votre configuration, inspectez à la fois les règles Singleton de projet d'autorisation binaire et les règles de plate-forme CV.

Vérifier le bon fonctionnement

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

Images exclues avec listes d'autorisation

Lorsque vous créez une règle de plate-forme, vous pouvez exclure les 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 cet ensemble de tests, et elle ne s'applique que lorsque cet ensemble de vérifications est évalué. Une liste d'autorisation au sein d'une vérification exclut uniquement les images de cette vérification.

Les schémas de liste d'autorisation sont des schémas qui correspondent à une ou plusieurs URL d'image. Un schéma de liste d'autorisation peut être l'un des schémas suivants :

  • Un préfixe de nom d'image se terminant par le caractère générique * ou **.
  • Un simple 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 *)
  • Un nom d'image avec un condensé.
  • Un nom d'image contenant à la fois un tag et un condensé.

Voici des exemples de schémas de liste d'autorisation :

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c correspond au nom, au tag et au condensé d'image exacts.
  • us-central1.pkg.dev/my-project/my-image:latest correspond au nom et au tag, avec n'importe quel condensé (ou aucun condensé).
  • us-central1.pkg.dev/my-image:foo* correspond au nom et au préfixe de tag (par exemple, myimage:foo et myimage:foobar), avec n'importe quel condensé (ou aucun condensé).
  • us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c correspond au nom et au condensé, avec n'importe quel tag (ou sans tag).
  • 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 faire correspondre n'importe quel nom avec un certain préfixe. * correspond aux suffixes qui n'incluent pas /. ** correspond aux suffixes pouvant inclure /, mais ** ne peut être utilisé qu'après un /. Notez que * et ** ne peuvent pas être utilisés avec des tags ou des condensés.

Par 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 les préfixes de tag ne doivent pas être vides. Ainsi, * ou ** à lui seul n'est pas un schéma valide, pas plus que us-central1.pkg.dev/my-image:*.

Exception au niveau de gkePolicy

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

Dans la règle, les images répertoriées sous imageAllowlist sont exclues de tous les ensembles de vérifications (checkSets) répertoriés sous gkePolicy.

Exception au niveau de checkSet

L'exemple suivant montre comment exclure les images au niveau de l'ensemble de vérifications :

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

Dans la règle, les images répertoriées sous imageAllowlist sont exclues de toutes les vérifications répertoriées sous checkSets.

Exception au niveau des vérifications

L'exemple suivant montre comment exclure les images au niveau de la vérification :

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

Utiliser plusieurs ensembles de vérifications

Une règle basée sur les vérifications CV peut contenir plusieurs ensembles de vérifications. La CV évalue un ensemble de vérifications à chaque fois qu'elle évalue la règle. Vous pouvez considérer les ensembles de vérifications 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 dans les environnements de production, vous pouvez placer les vérifications pour chaque environnement dans un ensemble de vérifications distinct, l'un n'étant évalué que dans l'environnement de développement et l'autre que dans l'environnement de 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 vérifications s'applique.

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

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

La plupart des exemples de règles inclus dans les guides de CV n'utilisent qu'un ensemble de vérifications par défaut.

L'exemple de configuration de règle suivant configure trois ensembles de vérifications :

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érifications est limité à prod-namespace. Par conséquent, ses vérifications n'affectent que les pods exécutés dans ce champ d'application. Le second ensemble de vérifications est limité à dev-namespace. Ses vérifications n'affectent donc que les pods exécutés dans ce champ d'application. Le troisième ensemble de vérifications est un ensemble de vérifications par défaut. Ses vérifications s'appliquent à tous les pods du cluster qui s'exécutent en dehors des champs d'application prod-namespace et dev-namespace.

Lorsque la CV évalue l'ensemble de vérifications appelé Prod check set, elle vérifie les éléments suivants pour les images 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 la CV évalue l'ensemble de vérifications appelé Dev check set, elle évalue les pods exécutés dans l'espace de noms Kubernetes dev-namespace et vérifie si les images du pod proviennent du répertoire dev-images.

L'ensemble de vérifications par défaut agit comme un alias collecteur. La vérification avec refus systématique garantit que la CV journalise tous les pods en cours d'exécution 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.

Vérifiez que les champs d'application définis sont soumis aux règles suivantes :

  • Il ne peut y avoir qu'un seul ensemble de vérifications par champ d'application dans une règle de plate-forme.

  • Si une règle contient à la fois des ensembles de vérifications au niveau d'un espace de noms et au niveau d'un compte de service, ces derniers doivent être répertoriés en premier, suivi des ensembles de vérifications au niveau de l'espace de noms.

  • Il ne peut y avoir qu'un seul ensemble de vérifications par défaut, qui doit être répertorié en dernier.

Si une règle de plate-forme contient des ensembles de vérifications, elle doit contenir au moins un ensemble de vérifications par défaut. Une règle de plate-forme sans ensemble de vérifications est autorisée, mais comme aucune vérification n'est enfreinte, la CV ne produit aucune entrée de journal.

Ancienne CV

Cette section décrit les anciennes règles CV. Si vous débutez avec la CV, nous vous recommandons d'utiliser plutôt la CV avec des règles basées sur les vérifications.

Pour les anciens utilisateurs de CV, la CV peut être activée sur les projets exécutant GKE. La CV utilise alors la règle d'application d'autorisation binaire pour vérifier tous les pods exécutés sur tous les clusters du projet, y compris ceux pour lesquels l'application d'autorisation binaire n'est pas activée.

Découvrez comment utiliser l'ancienne CV (obsolète)et afficher les événements d'ancienne CV dans Cloud Logging.

Étapes suivantes