Ce document explique comment créer et gérer des règles de protection des artefacts. Pour obtenir une présentation du service, de ses fonctionnalités et de ses avantages, consultez la page Présentation d'Artifact Guard.
Avant de commencer
Avant de pouvoir créer une règle Artifact Guard, vous devez activer Artifact Guard dans Security Command Center et obtenir les rôles et autorisations Identity and Access Management (IAM) requis.
Vous pouvez ensuite créer une règle dans la consoleGoogle Cloud ou à l'aide de Google Cloud CLI.
Activer Artifact Guard
Suivez la procédure décrite dans Configurer les services Security Command Center pour activer Artifact Guard.
Rôle requis
Pour obtenir les autorisations nécessaires pour utiliser Artifact Guard, demandez à votre administrateur de vous accorder le rôle IAM (Identity and Access Management) suivant sur votre projet ou votre organisation :
- Administrateur d'évaluation Artifact Scan Guard (
roles/artifactscanguard.policyEvaluator)
Vous pouvez accorder ce rôle à l'aide de la console Google Cloud ou en exécutant la commande Google Cloud CLI suivante :
projet
gcloud organizations add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:YOUR_SERVICE_ACCOUNT_EMAIL" \
--role="roles/artifactscanguard.policyEvaluator" \
Remplacez les éléments suivants :
PROJECT_IDYOUR_SERVICE_ACCOUNT_EMAIL
organisation
gcloud organizations add-iam-policy-binding ORGANIZATION_ID \
--member="serviceAccount:YOUR_SERVICE_ACCOUNT_EMAIL" \
--role="roles/artifactscanguard.policyEvaluator" \
Remplacez les éléments suivants :
ORGANIZATION_IDYOUR_SERVICE_ACCOUNT_EMAIL
Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.
Pour en savoir plus sur les rôles Artifact Guard, consultez Rôles et autorisations Artifact Guard.
Créer une règle dans la console Google Cloud
Pour créer une règle Artifact Guard dans la console Google Cloud :
Dans la console Google Cloud , accédez à Sécurité > Règles, puis cliquez sur Créer une règle Artifact Guard ou Créer une règle.
Saisissez un ID de règle et une description pour la règle, puis cliquez sur Continuer.
Sélectionnez les champs d'application et les actions de la règle :
Plate-forme CI/CD
- Sélectionner un ou plusieurs connecteurs : connecteurs auxquels cette règle doit être associée. Cette règle sera évaluée pour chaque build CI/CD associé aux connecteurs sélectionnés.
- Action de la règle : sélectionnez l'action à effectuer en cas de non-respect de la règle.
- Bloquer les compilations qui ne respectent pas la stratégie
- Autoriser les compilations avec des alertes : les résultats de l'évaluation des règles de l'analyseur CI/CD s'affichent dans les pipelines de compilation associés.
Registre
- Projets Container Analysis : cela ne s'applique qu'aux organisations, et non aux projets. Ajoutez les projets Google Cloud auxquels vous souhaitez appliquer cette règle.
- Dépôts Artifact Registry : sélectionnez les dépôts auxquels vous souhaitez appliquer cette règle. Il doit s'agir de dépôts Artifact Registry valides. Si vous ne renseignez pas ce champ, la règle s'appliquera à tous les dépôts.
- Action de la règle : sélectionnez l'action à effectuer en cas de non-respect de la règle.
- Audit uniquement : la règle est évaluée et toute infraction est consignée à des fins d'audit sans bloquer la ressource. Pour afficher les éventuels cas de non-respect, vous devez appeler l'API à l'aide de
ListArtifactPoliciesEvaluationsetGetArtifactPoliciesEvaluation. - Contrôle d'admission : si une violation se produit lors de l'évaluation de la règle, la ressource est bloquée.
- Définir les stratégies d'autorisation binaire sur le mode dry run : pour en savoir plus, consultez Activer le mode dry run.
- Projets d'autorisation binaire : ne s'applique qu'aux organisations, et non aux projets. Ajoutez les projets Google Cloud auxquels vous souhaitez appliquer le contrôle des admissions.
- Clusters GKE : si ce champ est laissé vide, le contrôle des admissions est appliqué à tous les clusters GKE.
- Ignorer les stratégies d'autorisation binaire : cette case à cocher doit être sélectionnée pour mettre à jour la stratégie d'autorisation binaire pour le contrôle des admissions.
- Audit uniquement : la règle est évaluée et toute infraction est consignée à des fins d'audit sans bloquer la ressource. Pour afficher les éventuels cas de non-respect, vous devez appeler l'API à l'aide de
Durée d'exécution
- Projets d'exécution : cela ne s'applique qu'aux organisations, et non aux projets. Ajoutez des projets d'exécution contenant des clusters GKE.
- Clusters GKE : sélectionnez les clusters GKE auxquels vous souhaitez appliquer cette règle. Si vous ne renseignez pas ce champ, la règle s'appliquera à tous les clusters GKE des projets sélectionnés.
Définissez la règle de stratégie. Une règle de stratégie est un ensemble de critères qui déterminent les failles et les packages autorisés dans votre environnement. Une règle de stratégie inclut les éléments suivants :
Seuil de gravité : définissez le niveau de gravité minimal d'une faille pour qu'elle soit incluse dans l'évaluation des règles. Les failles doivent être supérieures ou égales à ce seuil pour être incluses.
Par exemple, si vous configurez la règle sur Moyenne, l'évaluation inclut toutes les failles Moyennes, Élevées et Critiques.
Seuil du nombre de failles : définit le nombre maximal de failles autorisées après l'application des autres filtres de règles. La règle n'est enfreinte que si le nombre de ces failles filtrées spécifiques dépasse la limite.
Par exemple, si vous définissez un seuil de gravité sur Élevée, que vous excluez les failles pour lesquelles aucune correction n'est disponible et que vous définissez un seuil de nombre sur cinq, une compilation échoue si elle contient plus de cinq failles corrigibles classées comme Élevées ou Critiques.
État de la faille : indiquez si vous souhaitez inclure uniquement les failles pour lesquelles un correctif est disponible. Cela permet de définir la priorité de la correction en ciblant toutes les failles ou uniquement celles qui peuvent être corrigées.
Exceptions et restrictions : ces sections vous permettent de créer des autorisations ou des blocages spécifiques qui remplacent la règle générale.
- CVE exemptées : spécifiez les CVE qui sont considérées comme acceptables dans votre environnement pour une durée déterminée. Cela peut être utile pour implémenter des solutions de contournement temporaires. Vous pouvez définir une date d'expiration pour ces exceptions. Après cette date, la faille n'est plus autorisée et entraîne l'échec de la règle.
- CVE restreintes : spécifiez les CVE à bloquer systématiquement, quelle que soit leur évaluation de gravité. Cela est particulièrement utile pour signaler les failles qui présentent un risque unique pour votre application ou infrastructure spécifique.
- Packages autorisés : liste des packages considérés comme sécurisés. La version du package peut être définie. Sinon, toutes les versions sont autorisées.
- Packages restreints : liste des packages à restreindre. Les packages restreints entraînent l'échec de la règle. La version du package peut être définie. Sinon, toutes les versions sont limitées.
Cliquez sur Créer.
Les règles Artifact Guard disponibles sont listées dans le tableau de la page Règles.
Créer une stratégie à l'aide de Google Cloud CLI
Cette section décrit les commandes gcloud CLI disponibles pour Artifact Guard et explique comment les utiliser.
Prérequis de Google Cloud CLI
- Assurez-vous que votre version de gcloud CLI est 559.0.0 ou ultérieure.
- Définissez votre projet comme projet de configuration.
Pour ce faire, exécutez les commandes gcloud CLI suivantes :
gcloud components update --version=559.0.0
gcloud config set project PROJECT_ID
Commandes Google Cloud CLI
create
gcloud alpha scc artifact-guard policies create \ (POLICY --location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)) \ --policy-file-path=PATH_TO_FILE
- POLICY : identifiant complet de la stratégie, dans l'un des formats suivants :
{organizations/ORGANIZATION_ID/locations/LOCATION/policies/POLICY_ID}{projects/PROJECT_NUMBER/locations/LOCATION/policies/POLICY_ID}{policy_id -location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)}
- PATH_TO_FILE : chemin d'accès local au document YAML contenant la définition de la règle. Pour en savoir plus sur la structure du fichier YAML, consultez la section Fichier YAML de ce document.
get
gcloud alpha scc artifact-guard policies describe \ (POLICY --location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER))
- POLICY : identifiant complet de la stratégie, dans l'un des formats suivants :
{organizations/ORGANIZATION_ID/locations/LOCATION/policies/POLICY_ID}{projects/PROJECT_NUMBER/locations/LOCATION/policies/POLICY_ID}{policy_id -location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)}
list
gcloud alpha scc artifact-guard policies list PARENT
- PARENT : une organisation ou un projet. Les formats acceptés pour la ressource parente sont les suivants :
{organizations/ORGANIZATION_ID/locations/LOCATION}{projects/PROJECT_NUMBER/locations/LOCATION}
supprimer
gcloud alpha scc artifact-guard policies delete \ (POLICY --location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)) \ [--etag=ETAG]
- POLICY : identifiant complet de la règle, dans l'un des formats suivants :
{organizations/ORGANIZATION_ID/locations/LOCATION/policies/POLICY_ID}{projects/PROJECT_NUMBER/locations/LOCATION/policies/POLICY_ID}{policy_id -location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)}
- etag : facultatif. Pour le contrôle de simultanéité. La requête n'est exécutée que si l'ETag de la ressource correspond.
update
gcloud alpha scc artifact-guard policies update \ (POLICY --location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)) \ --policy-file-path=PATH_TO_FILE [--allow-missing] \ [--update-mask=UPDATE_MASK]
- POLICY : identifiant complet de la stratégie, dans l'un des formats suivants :
{organizations/ORGANIZATION_ID/locations/LOCATION/policies/POLICY_ID}{projects/PROJECT_NUMBER/locations/LOCATION/policies/POLICY_ID}{policy_id -location=LOCATION (--organization=ORGANIZATION_ID | --project=PROJECT_NUMBER)}
- PATH_TO_FILE : chemin d'accès local au document YAML contenant la définition des champs à mettre à jour.
- allow_missing : valeur booléenne facultative. Si
true, crée une règle si celle spécifiée n'existe pas. - update-mask : liste des champs à mettre à jour, séparés par une virgule. Une chaîne vide ou "*" signifie une mise à jour complète des règles. Les champs valides pour le masque de mise à jour sont les suivants :
display_namedescriptionscopeenablement_statevulnerability_policyannotations
Fichier YAML
Un fichier YAML pour une définition de règle Artifact Guard doit suivre ce modèle :
displayName: <Human readable display name for the policy>
description: <Description of the policy>
vulnerabilityPolicy: # (at least one of these rules must be defined)
exemptedCves:
- id: <cve-id-1>
gracePeriodExpirationTime: <optional-grace-period-expiration-time>
- id: <cve-id-2>
gracePeriodExpirationTime: <optional-grace-period-expiration-time>
maxAllowedSeverity: <The maximum severity allowed in the detected
vulnerabilities. The severity values can be LOW, MEDIUM, HIGH, CRITICAL>
maximumAllowedVulnerabilities: <The maximum number of vulnerabilities that
can be detected>
excludeUnfixable: <Whether to exclude the vulnerabilities without an
available fix from the purview of the policy evaluation>
restrictedCves:
- <restricted-cve-id-1>
- <restricted-cve-id-2>
allowedPackages:
- name: <allowed_package_name_1>
version: <optional_version_of_allowed_package_1. If unspecified, all the
versions of the package are allowed>
- name: <allowed_package_name_2>
version: <optional_version_of_allowed_package_2>
restrictedPackages:
- name: <restricted_package_name_1>
version: <optional_version_of_restricted_package_1. If unspecified, all
the versions of the package are restricted>
- name: <restricted_package_name_2>
version: <optional_version_of_restricted_package_2>
scope:
pipeline:
connectorIds:
- <connector_id_1>
- <connector_id_2>
enforcementAction: <action to take in case the policy evaluation fails.
The supported values are AUDIT_ONLY or BLOCK_BUILD>
registry:
projectIds:
- <project_id_1>
garRepositoryNamePatterns:
- <repository_name_pattern_1>
imageNamePatterns:
- <image_name_pattern_1>
enforcementAction: <AUDIT_ONLY or ADMISSION_CONTROL>
admissionControl:
deploymentProjectIds:
- <project_id_1>
gkeClusterNames:
- <cluster_name_1>
dryRun: <bool>
overrideBinauthzPolicy: <bool>
runtime:
deploymentProjectIds:
- <project_id_1>
gkeClusterNames:
- <cluster_name_1>
dryRun: <bool>
overrideBinauthzPolicy: <bool>
enforcementAction: <AUDIT_ONLY or BLOCK_DEPLOYMENT>
enablementState: <The enablement state of the policy. The supported values are
ACTIVE, INACTIVE>
Voici un exemple de fichier de règles Artifact Guard :
displayName: 'A sample policy'
description: Vulnerability Policy
vulnerabilityPolicy:
exemptedCves:
- id: CVE-2022-40897
gracePeriodExpirationTime: '2026-09-10T18:58:08Z'
- id: CVE-2024-6345
maxAllowedSeverity: MEDIUM
maximumAllowedVulnerabilities: 5
excludeUnfixable: true
restrictedCves:
- CVE-2013-4392
- CVE-2024-4143
allowedPackages:
- name: systemd
version: '257.7'
- name: util-linux
restrictedPackages:
- name: ncurses
version: 6.5+20250216
- name: setuptools
scope:
pipeline:
connectorIds:
- organizations/123/locations/global/connectors/demoConnector
enforcementAction: BLOCK_BUILD
registry:
projectIds:
- projects/my-registry-project-id
- projects/another-registry-project
garRepositoryNamePatterns:
- us-west1-docker.pkg.dev/my-registry-project-id/my-repo
- gcr.io/team-a/internal-artifacts
imageNamePatterns:
- my-repo/service-a:.*
- my-repo/service-b:v1\..*
enforcementAction: ADMISSION_CONTROL
admissionControl:
deploymentProjectIds:
- projects/my-deployment-project
gkeClusterNames:
- //container.googleapis.com/projects/my-deployment-project/locations/us-central1/clusters/gke-cluster-a
- //container.googleapis.com/projects/my-deployment-project/locations/us-central1/clusters/gke-cluster-b
dryRun: true
overrideBinauthzPolicy: true
runtime:
deploymentProjectIds:
- projects/my-deployment-project
gkeClusterNames:
- //container.googleapis.com/projects/my-deployment-project/locations/us-central1/clusters/gke-cluster-a
- //container.googleapis.com/projects/my-deployment-project/locations/us-central1/clusters/gke-cluster-b
dryRun: false
overrideBinauthzPolicy: false
enforcementAction: BLOCK_DEPLOYMENT
enablementState: ACTIVE
Performances et limites
- Nombre maximal de règles par ressource parente : une ressource parente (organisation ou projet) peut définir un maximum de 1 000 règles. Cela inclut tous les types de règles de sécurité configurées dans Artifact Guard.
- Nombre maximal de règles de protection contre les failles par ressource parente : en plus de la limite globale de règles, il existe une limite concernant le nombre de règles axées sur les résultats de failles. Une ressource parente (organisation ou projet) peut comporter au maximum 500 règles ciblant les failles.
- Nombre maximal de règles par pipeline : pour chaque pipeline CI/CD individuel dans lequel des règles Artifact Guard sont intégrées pour l'application au moment de la compilation, un maximum de 100 règles est autorisé.
- Nombre maximal de modifications par règlement et par semaine : pour chaque règlement, vous pouvez effectuer au maximum 100 modifications par semaine.
- Nombre maximal de connecteurs de pipeline par règle : chaque règle peut être associée à un maximum de 100 connecteurs de pipeline.
- Nombre maximal de CVE exemptées et restreintes par règle : chaque règle peut exempter et restreindre un maximum de 100 CVE.
- Nombre maximal de packages autorisés et restreints par règle : chaque règle peut autoriser et restreindre un maximum de 100 packages.
Pour connaître les autres contraintes, consultez Dépannage.
Dépannage
Cette section décrit les champs des règles Artifact Guard et les erreurs courantes ainsi que leurs solutions.
Validation des règles
Artifact Guard valide les définitions de règles lorsque vous créez ou mettez à jour des règles. Si la validation échoue, Artifact Guard rejette la demande et fournit un message d'erreur détaillé.
Champs de règles générales
| Nom | Description | Obligatoire | Contraintes | Exemples de valeurs |
|---|---|---|---|---|
| Parent | Définit le champ d'application de la règle. | Oui | Seules les règles dans l'emplacement global sont acceptées. |
|
| ID de la règle | Identifiant unique de la règle. | Oui | Jusqu'à 100 caractères. Doit commencer par une lettre, se terminer par un caractère alphanumérique et ne contenir que des lettres, des chiffres, des traits d'union ou des traits de soulignement. | my-policy-1 |
| Nom à afficher | Nom lisible de la règle. | Non | Jusqu'à 63 caractères. Il est recommandé qu'elle soit unique. | My vulnerability policy |
| Description | Description de la règle. | Non | Jusqu'à 2 048 caractères. | Checks for critical vulnerabilities. |
| Type de règle | Type de règle en cours de définition. | Oui | Seule l'option vulnerability_policy est acceptée. |
vulnerability_policy |
| État de l'activation | État d'activation de la règle. | Oui | La valeur doit être ACTIVE ou INACTIVE. |
ACTIVE |
Règlement sur les failles
| Nom | Description | Valeurs multiples | Contraintes | Exemples de valeurs |
|---|---|---|---|---|
| maximumAllowedVulnerabilities | Nombre maximal de failles autorisé avant que la règle ne soit enfreinte. | Non | Doit être un nombre non négatif s'il est défini. | 10 |
| maxAllowedSeverity | Gravité maximale des failles autorisées par le règlement. | Non | La valeur doit être LOW, MEDIUM, HIGH ou CRITICAL. |
|
| exemptedCves | Liste des CVE exemptées de cette règle. | Oui | Jusqu'à 100 entrées. Chaque ID doit être au format CVE-YYYY-NNNN.
Si une date d'expiration du délai de grâce est fournie, elle doit correspondre à un horodatage valide. Ne peut pas chevaucher restrictedCves. |
- id: CVE-2024-12345gracePeriodExpirationTime: 2027-01-01T00:00:00Z- id: CVE-2025-4000 |
| restrictedCves | Liste des CVE explicitement interdites par cette règle. | Oui | Jusqu'à 100 entrées. Chaque ID doit être au format CVE-YYYY-NNNN.
Ne peut pas chevaucher exemptedCves. |
- CVE-2024-54321- CVE-2025-5001 |
| allowedPackages | Liste des packages autorisés, qui peuvent remplacer d'autres règles. | Oui | Jusqu'à 100 entrées. Les noms de packages ne peuvent pas être vides. Ne peut pas être en conflit avec
restrictedPackages. |
- name: nginxversion: 1.0- name: pythonversion: 3.12.4 |
| restrictedPackages | Liste des packages explicitement interdits. | Oui | Jusqu'à 100 entrées. Les noms de packages ne peuvent pas être vides. Ne peut pas être en conflit avec
allowedPackages. |
- name: npmversion: 9.0.0 |
| excludeUnfixable | Indique s'il faut exclure les failles pour lesquelles aucun correctif n'est disponible. | Non | Valeur booléenne. La valeur par défaut est false. |
true |
| exemptionDaysPostDisclosure | Nombre de jours pendant lesquels les failles sont exemptées après leur date de divulgation. | Non | Si elle est définie, elle doit être un nombre non négatif. La valeur par défaut est 0. |
30 |
Champ d'application des règles
Champ d'application du pipeline
| Nom | Description | Obligatoire | Contraintes | Exemples de valeurs |
|---|---|---|---|---|
| connectorIds | Liste des ID de connecteur auxquels la règle s'applique lors de l'analyse du pipeline CI/CD. | Oui | Une entrée minimum, 100 entrées maximum. Votre organisation ou votre projet doivent être intégrés à l'analyse CI/CD. Chaque ID doit respecter le format approprié, appartenir à votre organisation ou projet, et pointer vers un connecteur existant. |
|
| enforcementAction | Action à effectuer en cas de non-respect des règles. | Oui | La valeur doit être définie sur AUDIT_ONLY ou BLOCK_BUILD. |
BLOCK_BUILD |
Champ d'application du registre
| Nom | Description | Obligatoire | Contraintes | Exemples de valeurs |
|---|---|---|---|---|
| projectIds | Liste des ID de projet auxquels la règle s'applique. | Non | Au moins une entrée. Chaque ID doit être un ID de projet Google Cloud valide. | projects/123, projects/456 |
| garRepositoryNamePatterns | Liste des modèles de noms de dépôts Artifact Registry. Google Cloud | Non | 100 entrées maximum. Doit être un schéma de dépôt Artifact Registry valide Google Cloud . | us-west1-docker.pkg.dev/my-project/my-repo, gcr.io/team-a/* |
| imageNamePatterns | Modèles d'expression régulière pour les noms d'image complets. | Non | 100 entrées maximum. Doit être une expression régulière valide. | 'my-repo/service-a:.*', 'my-repo/service-b:v1..*' |
| enforcementAction | Action à effectuer en cas de non-respect des règles. | Oui | La valeur doit être définie sur AUDIT_ONLY ou ADMISSION_CONTROL. |
ADMISSION_CONTROL |
| admissionControl | Détails de configuration du contrôle des admissions. | Non | Doit être présent si enforcementAction a la valeur ADMISSION_CONTROL. |
Champ d'application de l'exécution
Le champ d'application de l'exécution permet à Artifact Guard de surveiller les images de conteneurs en cours d'exécution dans votre environnement GKE. Lorsqu'une règle est appliquée à ce champ d'application, les résultats de Security Command Center concernant les failles sont automatiquement enrichis avec les métadonnées de la règle pour les images déployées dans les projets ou clusters spécifiés.
| Nom | Description | Obligatoire | Contraintes | Exemples de valeurs |
|---|---|---|---|---|
| projectIds | Liste des ID de projet dans lesquels les clusters GKE sont déployés et l'évaluation des failles est activée. | Oui | Doit être sélectionné au niveau de l'organisation. | projects/my-gke-deployment-123 |
| gkeClusterNames | Clusters GKE spécifiques pour lesquels la règle doit être évaluée. | Non | Peuvent être sélectionnés au niveau de l'organisation ou du projet. | projects/prod-env/locations/us-central1/clusters/main-cluster |
Si une image de conteneur exécutée dans un cluster GKE surveillé ne respecte pas une règle, les métadonnées ArtifactGuardPolicies sont ajoutées au message de résultat de la faille Security Command Center, comme suit :
// Added to the SCC 'message Finding'
ArtifactGuardPolicies artifact_guard_policies = X;
message ArtifactGuardPolicies {
string resource_id = 1; // e.g., //us-docker.pkg.dev/google-samples/containers/gke/security/...
repeated Policy failing_policies = 2;
}
message Policy {
enum Type {
TYPE_UNSPECIFIED = 0;
VULNERABILITY = 1;
}
Type type = 1;
string policy_id = 2; // e.g., organizations/3392779/locations/global/policies/prod-policy
string failure_reason = 3; // e.g., severity=HIGH AND max_vuln_count=2
}
Mesure coercitive
Pour les actions BLOCK_BUILD et BLOCK_DEPLOYMENT, l'évaluation des règles renvoie une mesure coercitive recommandée. Toutefois, vous devez configurer l'application réelle dans la configuration du pipeline à l'aide de cette recommandation.
Suppression de règles
Les règles actives ne peuvent pas être supprimées et génèrent une erreur FAILED_PRECONDITION. Pour supprimer une règle, définissez d'abord son état sur Inactive.
Erreurs fréquentes
Le tableau suivant présente certaines erreurs courantes et explique comment les résoudre.
| Indication du message d'erreur | Cause | Solution |
|---|---|---|
| parent is required (parent obligatoire) | Le champ parent est manquant dans la requête. | Indiquez un parent valide dans l'un des formats suivants :
|
| La définition de la règle est obligatoire | L'objet de règle est manquant dans la requête. | Fournissez un objet de règle valide dans la requête. |
| Le nom à afficher ne peut pas dépasser… | Le nom à afficher comporte plus de 63 caractères. | Raccourcissez le nom à afficher pour qu'il ne comporte pas plus de 63 caractères. |
| La description ne doit pas dépasser… | La description dépasse 2 048 caractères. | Raccourcissez la description pour qu'elle ne comporte pas plus de 2 048 caractères. |
| Veuillez sélectionner un type de règle. | Le type de règle (par exemple, vulnerabilityPolicy) est manquant dans la requête. |
Ajoutez un vulnerabilityPolicy ou un autre type de règle à votre règle. |
| L'état d'activation n'est pas valide | Un état d'activation non valide ou obsolète a été utilisé. | Utilisez ACTIVE ou INACTIVE. |
| Le champ d'application est obligatoire. | Aucun champ d'application (pipeline, registre ou environnement d'exécution) n'a été défini. | Ajoutez au moins un champ d'application valide à votre règle. |
| Le nom de la CVE doit être au format suivant : | Un ID CVE dans exemptedCves ou restrictedCves n'est pas valide. |
Assurez-vous que tous les ID CVE respectent le format CVE-YYYY-NNNN. |
| CVE ... ne peut pas être exemptée et restreinte | Le même ID CVE existe dans exemptedCves et restrictedCves. |
Supprimez le CVE dans l'une des listes. |
| Le nom du package ne peut pas être vide | Un package dans allowedPackages ou restrictedPackages a un nom vide. |
Attribuez un nom à tous les packages. |
| package ... cannot be allowed and restricted | Le même package est listé à la fois dans allowedPackages et restrictedPackages. |
Supprimez le package dans l'une des listes. |
| Veuillez indiquer des ID de connecteur. | Le champ connectorIds est manquant dans un champ "Portée du pipeline". |
Indiquez au moins un ID de connecteur. |
| L'ID du connecteur doit être au format suivant : | L'ID d'un connecteur est incorrect. | Assurez-vous que les ID sont dans l'un des formats suivants :
|
| L'ID de connecteur ... n'existe pas | L'ID de connecteur spécifié n'existe pas. | Vérifiez que le connecteur existe ou supprimez-le de la liste. |
| Le modèle de nom de dépôt GAR doit être... | Un schéma de dépôt non valide a été fourni dans un champ d'application du registre. | Assurez-vous que les modèles correspondent aux formats de dépôt Artifact Registry valides. Google Cloud |
| L'ID du projet doit être un ID de projet GCP valide... | Un ID de projet non valide a été fourni dans un champ d'application Registry ou Runtime. | Fournissez des ID de projet Google Cloud valides. |
| Une mesure coercitive doit être spécifiée. | Le enforcementAction est manquant dans un champ d'application "Pipeline" ou "Runtime". |
Définissez l'action d'application (par exemple, AUDIT_ONLY,
BLOCK_BUILD (pipeline uniquement) ou BLOCK_DEPLOYMENT (environnement d'exécution uniquement)). |
| Le nombre de règles par organisation dépasse la limite... | Vous avez atteint le nombre maximal de règles (1 000) pour votre organisation. | Supprimez les règles inutilisées avant d'en créer d'autres. |
| Le nombre de règles de sécurité ... dépasse la limite... | Vous avez atteint le nombre maximal de règles de sécurité (500). | Supprimez les règles de sécurité inutilisées avant d'en créer d'autres. |
| Le nombre de règles par pipeline dépasse la limite. | Un connecteur est associé à plus de 100 règles. | Réduisez le nombre de règles associées au connecteur. |
| Le nombre de révisions des règles dépasse la limite... | Vous avez modifié un règlement plus de 100 fois en sept jours. | Attendez ou réduisez la fréquence des mises à jour. |
Problèmes opérationnels courants
Outre les échecs de validation du contenu des règles, des problèmes peuvent survenir avec le plan de contrôleGoogle Cloud sous-jacent. Ces problèmes peuvent affecter les requêtes API, les opérations de longue durée et les états des ressources. Ils se manifestent généralement par des codes d'erreur spécifiques ou un comportement inhabituel.
| Problème | Symptôme(s) | Résoudre les problèmes |
|---|---|---|
| Modification simultanée | UpdatePolicy ou DeletePolicy échoue avec un code d'erreur ABORTED et un message "Provided etag is out of date". |
Dépannage : cela se produit lorsque le etag de votre demande ne correspond pas à la version actuelle du serveur de la règle, ce qui indique une modification par une autre demande.Résolution : Relisez la règle pour obtenir le dernier ETag, puis relancez la requête avec le nouvel ETag. |
| Demande validée, mais non exécutée | Une requête CreatePolicy, UpdatePolicy ou DeletePolicy renvoie une réponse positive, mais vous ne constatez aucune modification de la ressource. |
Dépannage : cela se produit généralement lorsque validate_only: true est défini dans la requête. Cet indicateur demande au service d'effectuer toutes les validations sans appliquer de modifications.Résolution : définissez validate_only sur
false ou omettez le champ dans votre requête. |
| Une mise à jour crée une nouvelle règle | Une requête UpdatePolicy crée une règle au lieu de renvoyer une erreur "introuvable" lorsque la règle n'existe pas. |
Dépannage : il s'agit du comportement attendu lorsque allow_missing: true est inclus dans un UpdatePolicyRequest.Résolution : Si vous souhaitez uniquement mettre à jour une règle existante, définissez allow_missing sur false ou omettez le champ. |
| Autorisation refusée ou API non activée | Les requêtes échouent avec PERMISSION_DENIED ou un message d'erreur tel que "Artifact Guard API has not been used in the project before or it is
disabled.". |
Dépannage : l'API est peut-être désactivée ou l'appelant ne dispose pas des autorisations suffisantes. Résolution : Dans votre projet Google Cloud , activez l'API Artifact Guard ( artifactscanguard.googleapis.com).
Vérifiez que l'utilisateur ou le compte de service qui effectue l'opération dispose des rôles IAM nécessaires. |
| Délai d'expiration de l'opération | Une requête qui renvoie une opération de longue durée (LRO) met trop de temps à se terminer ou échoue avec DEADLINE_EXCEEDED. |
Dépannage : cela peut indiquer un ralentissement ou un problème temporaire dans le service de backend. Résolution : interrogez l'état de l'opération de longue durée. En cas d'échec ou d'expiration, réessayez l'opération après quelques instants. Si le problème persiste, consultez le tableau de bord de l'étatGoogle Cloud pour vérifier si des incidents sont en cours ou contactez l'assistance Google Cloud . |