Résoudre les problèmes courants liés à VPC Service Controls avec les services Google Cloud

Cette page fournit des solutions aux problèmes que vous pouvez rencontrer lorsque vous utilisez un serviceGoogle Cloud qui se trouve dans un périmètre VPC Service Controls.

Problèmes liés à Cloud Build

L'utilisation des ressources Cloud Build dans un périmètre VPC Service Controls présente certaines limites connues. Pour en savoir plus, consultez Limites d'utilisation de VPC Service Controls avec Cloud Build.

Le compte de service Cloud Build ne peut pas accéder aux ressources protégées

Cloud Build utilise le compte de service Cloud Build pour exécuter des compilations en votre nom. Par défaut, lorsque vous exécutez une compilation sur Cloud Build, celle-ci s'exécute dans un projet locataire en dehors de votre projet.

Les VM de nœud de calcul Cloud Build qui génèrent des résultats de compilation se trouvent en dehors du périmètre VPC Service Controls, même si votre projet se trouve à l'intérieur du périmètre. Par conséquent, pour que vos compilations puissent accéder aux ressources du périmètre, vous devez autoriser le compte de service Cloud Build à accéder au périmètre de VPC Service Controls en l'ajoutant au niveau d'accès ou à la règle d'entrée.

Pour en savoir plus, consultez Accorder au compte de service Cloud Build l'accès au périmètre VPC Service Controls.

Problèmes liés à Cloud Storage

Refus lors du ciblage d'un bucket Cloud Storage de journalisation inexistant

Si le bucket de journaux spécifié n'existe pas, VPC Service Controls refuse l'accès en indiquant le motif de non-respect suivant : RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Vous pouvez consulter le journal du refus d'accès à l'aide de l'identifiant unique VPC Service Controls (vpcServiceControlUniqueIdentifier). Vous trouverez ci-dessous un exemple de journal avec le motif de non-respect RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER :

"serviceName": "storage.googleapis.com",
"methodName": "google.storage.buckets.update",
"resourceName": "projects/325183452875",
"metadata": {
  "violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
  ...
  "egressViolations": [
    {
      "sourceType": "Resource",
      "targetResource": "projects/0/buckets/this-bucket-does-not-exist",
      "source": "projects/325183452875/buckets/bucket-in-same-project",
      "servicePerimeter": "accessPolicies/875573620132/servicePerimeters/prod_perimeter"
    }]}

Si le champ targetResource de l'objet egressViolations affiche une cible avec projects/0/buckets, cela déclenche toujours un refus, car projects/0 n'existe pas et est considéré comme étant en dehors du périmètre de service.

Refus lors de l'accès aux buckets Cloud Storage publics appartenant à Google

Un périmètre de service ne peut pas contenir de projets provenant de différentes organisations. Un périmètre ne peut contenir que des projets de son organisation parente. Il existe certaines limites lorsque vous souhaitez accéder à des buckets Cloud Storage depuis des projets situés dans un périmètre VPC Service Controls appartenant à une autre organisation.

Un exemple typique est lorsque vous souhaitez accéder à des buckets Cloud Storage appartenant à Google. Étant donné que votre projet et le projet appartenant à Google qui contient le bucket cible ne se trouvent pas dans le même périmètre, VPC Service Controls refuse la requête en indiquant le motif de non-respect suivant : RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Pour résoudre ce problème, vous pouvez créer des règles d'entrée et de sortie.

Accès à un bucket Cloud Storage disponible publiquement depuis un périmètre

Si vous essayez d'accéder à un bucket Cloud Storage accessible publiquement depuis un périmètre de service, VPC Service Controls peut bloquer vos requêtes en générant un non-respect des règles de sortie.

Pour garantir un accès cohérent et réussi à l'objet selon les besoins, nous devons appliquer une règle de sortie au périmètre de service concerné.

Problèmes liés à Security Command Center

Cette section liste les problèmes que vous pouvez rencontrer lorsque vous utilisez des ressources Security Command Center qui se trouvent dans un périmètre VPC Service Controls.

Security Command Center ne peut pas envoyer de notification à Pub/Sub

Toute tentative de publication de notifications Security Command Center sur un sujet Pub/Sub à l'intérieur d'un périmètre VPC Service Controls échoue et génère le cas de non-respect suivant : RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

Nous vous recommandons d'activer Security Command Center au niveau de l'organisation. VPC Service Controls ne considère pas une organisation parente comme faisant partie du périmètre de ses projets enfants. Pour que cela fonctionne, vous devez accorder un accès au périmètre à Security Command Center.

Pour contourner ce problème, vous pouvez utiliser l'une des méthodes suivantes :

  • Utilisez un sujet Pub/Sub dans un projet qui ne se trouve pas dans un périmètre de service.
  • Supprimez l'API Pub/Sub du périmètre de service jusqu'à ce que la configuration des notifications soit terminée.

Pour en savoir plus sur l'activation des notifications Security Command Center envoyées à un sujet Pub/Sub, consultez Activer les notifications de résultats pour Pub/Sub.

Security Command Center ne peut pas analyser les ressources Compute Engine à l'intérieur d'un périmètre

Security Command Center analyse les ressources Compute Engine de vos projets à l'aide du compte de service par produit et par projet (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. Pour que Security Command Center puisse accéder aux ressources à l'intérieur du périmètre, le P4SA doit être ajouté à votre niveau d'accès ou à votre règle d'entrée. Sinon, une erreur NO_MATCHING_ACCESS_LEVEL peut s'afficher.

Security Command Center ne peut pas analyser les ressources à l'intérieur d'un périmètre de service

Security Health Analytics analyse les ressources de vos projets à l'aide du compte de service P4SA (par produit et par projet) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com. Pour que Security Command Center puisse accéder aux ressources à l'intérieur du périmètre, le compte P4SA doit être ajouté à votre niveau d'accès ou à votre règle d'entrée. Sinon, l'erreur NO_MATCHING_ACCESS_LEVEL s'affichera.

Problèmes liés à Google Kubernetes Engine

Cette section liste les problèmes que vous pouvez rencontrer lorsque vous utilisez des ressources Google Kubernetes Engine qui se trouvent dans un périmètre VPC Service Controls.

L'autoscaler ne fonctionne pas dans les périmètres où les services accessibles et les services restreints sont activés

L'API autoscaling.googleapis.com n'est pas intégrée à VPC Service Controls. Elle ne peut donc pas être ajoutée aux services restreints ni aux services accessibles. Il n'est pas possible d'autoriser l'API autoscaling.googleapis.com dans les services accessibles. Par conséquent, l'autoscaler de clusters qui existe dans un périmètre avec des services accessibles activés peut ne pas fonctionner.

Nous vous déconseillons d'utiliser des services accessibles. Lorsque vous utilisez une adresse IP virtuelle (VIP) restreinte, créez une exception pour autoscaling.googleapis.com afin d'accéder à l'adresse IP virtuelle privée dans un périmètre contenant un cluster avec autoscaling.

Problèmes liés à BigQuery

Cette section liste les problèmes que vous pouvez rencontrer lorsque vous utilisez des ressources BigQuery qui se trouvent dans un périmètre VPC Service Controls.

Les restrictions de périmètre VPC Service Controls ne s'appliquent pas à l'exportation des résultats de requêtes BigQuery

Si vous essayez de limiter l'exportation de données protégées de BigQuery vers Google Drive, Google Sheets ou Looker Studio, vous constaterez peut-être un écart par rapport au comportement attendu. Lorsque vous exécutez une requête depuis l'UI BigQuery, les résultats sont stockés dans la mémoire locale de votre machine, comme le cache du navigateur. Cela signifie que les résultats se trouvent désormais en dehors de VPC Service Controls. Vous pouvez donc les enregistrer dans un fichier CSV ou dans Google Drive.

Dans ce scénario, VPC Service Controls fonctionne comme prévu, car le résultat est exporté depuis une machine locale située en dehors du périmètre de service. Toutefois, la restriction globale des données BigQuery est contournée.

Pour résoudre ce problème, limitez les autorisations IAM des utilisateurs en supprimant l'autorisation bigquery.tables.export. Notez que cette opération désactive toutes les options d'exportation.

Problèmes liés à GKE Enterprise

Cette section liste les problèmes que vous pouvez rencontrer lorsque vous utilisez des ressources GKE Enterprise qui se trouvent dans un périmètre VPC Service Controls.

Pour résoudre les erreurs liées à l'utilisation de VPC Service Controls avec Cloud Service Mesh, consultez Résoudre les problèmes liés à VPC Service Controls pour Cloud Service Mesh géré.

La configuration Config Controller de GKE Enterprise génère un non-respect des règles de sortie

La configuration de GKE Enterprise Config Controller devrait échouer si aucune configuration de sortie ne permet d'atteindre containerregistry.googleapis.com avec la méthode google.containers.registry.read dans un projet en dehors du périmètre.

Pour résoudre cette erreur, créez la règle de sortie suivante :

From:
  Identities:ANY_IDENTITY
To:
  Projects =
    NNNNNNNNNNNN
  Service =
  Service name: containerregistry.googleapis.com
  Service methods:
    containers.registry.read

Le non-respect des règles de sortie disparaît une fois que vous avez ajouté la règle au périmètre concerné.

Problèmes liés à Container Registry

Cette section liste les problèmes que vous pouvez rencontrer lorsque vous utilisez des ressources Container Registry qui se trouvent dans un périmètre VPC Service Controls.

Requêtes API Container Registry bloquées par VPC Service Controls alors qu'elles sont autorisées dans une règle d'entrée ou de sortie

Si vous avez autorisé l'accès à Container Registry à l'aide de règles d'entrée avec le champ identity_type défini sur ANY_USER_ACCOUNT ou ANY_SERVICE_ACCOUNT, l'accès est bloqué par VPC Service Controls.

Pour résoudre ce problème, remplacez la valeur du champ identity_type par ANY_IDENTITY dans la règle d'entrée ou de sortie.

Erreurs de sortie d'un agent de service lors de la copie d'une image Docker appartenant à Artifact Registry vers un projet dans un périmètre

Lorsque vous essayez de copier une image appartenant à Artifact Registry dans votre projet qui se trouve dans un périmètre VPC Service Controls, vous pouvez rencontrer des erreurs de sortie dans les journaux de l'agent de service cloud-cicd-artifact-registry-copier@system.gserviceaccount.com. Cette erreur de sortie se produit généralement lorsque la règle de périmètre est en mode dry run.

Pour résoudre ce problème, créez une règle de sortie qui autorise l'accès de l'agent de service cloud-cicd-artifact-registry-copier@system.gserviceaccount.com au service storage.googleapis.com dans le projet mentionné dans les journaux d'erreur VPC Service Controls.

Problèmes liés à Vertex AI

Cette section liste les problèmes que vous pouvez rencontrer lorsque vous utilisez des ressources Vertex AI qui se trouvent dans un périmètre VPC Service Controls.

Requêtes API pour les notebooks gérés par l'utilisateur bloquées par VPC Service Controls alors qu'elles sont autorisées dans une règle d'entrée ou de sortie

Si vous avez autorisé l'accès à l'API pour les notebooks gérés par l'utilisateur à l'aide d'une règle d'entrée et que vous avez défini identity_type sur ANY_USER_ACCOUNT ou ANY_SERVICE_ACCOUNT, VPC Service Controls bloque l'accès à l'API.

Pour résoudre ce problème, remplacez la valeur du champ identity_type par ANY_IDENTITY dans la règle d'entrée ou de sortie.

Problèmes liés à Spanner

La sauvegarde de la base de données Spanner est bloquée en raison du non-respect de la règle NO_MATCHING_ACCESS_LEVEL par le compte de service par produit et par projet (P4SA) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com.

Pour résoudre ce problème, ajoutez une règle d'entrée avec l'agent de service mentionné ci-dessus ou ajoutez-le à un niveau d'accès.

Problèmes liés à AlloyDB pour PostgreSQL

Si votre cluster AlloyDB pour PostgreSQL est protégé par une clé CMEK, vous pouvez rencontrer des erreurs d'entrée dans les journaux des agents de service service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com et service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com.

Pour résoudre ce problème, ajoutez une règle d'entrée avec l'accès des agents de service susmentionnés au service cloudkms.googleapis.com dans le projet mentionné dans les journaux d'erreur VPC Service Controls.

Étapes suivantes