Cas d'utilisation pour résoudre les problèmes d'accès sur Google Cloud

Last reviewed 2022-09-29 UTC

Ce document explique comment utiliser les outils Google Cloud pour résoudre les problèmes d'accès aux ressources Google Cloud. Il n'explique pas comment résoudre les problèmes d'accès des utilisateurs finaux à vos applications. Dans ce document, nous partons du principe que vous êtes familiarisé avec la résolution des problèmes liés aux stratégies et aux accès sur Google Cloud. Le document "Résoudre les problèmes liés aux stratégies et aux accès sur Google Cloud" décrit les services Google Cloud qui peuvent appliquer des stratégies d'accès et les outils de dépannage fournis par Google Cloud.

Méthode de dépannage

La première étape de la résolution d'un problème d'accès consiste à décider comment le traiter. L'organigramme suivant représente une approche visant à résoudre les problèmes d'accès. Pour effectuer la procédure de dépannage décrite, vous devez disposer des autorisations appropriées ou vous faire assister par une personne disposant de ces autorisations.

Le diagramme précédent décrit les étapes suivantes :

1. Vérifiez l'accès des utilisateurs dans Google Cloud Console et dans Cloud Shell. Si tous les accès sont refusés, consultez les entrées des journaux d'audit pour vérifier si le niveau d'erreur est indiqué.
   1. Si le niveau d'erreur est indiqué, vérifiez les autorisations requises.
      1. Si vous pouvez accorder des autorisations permettant de résoudre les problèmes d'accès, résolvez le problème.
      2. Si vous ne parvenez pas à résoudre les problèmes d'accès, contactez Cloud Customer Care.
   2. Si le niveau d'erreur n'est pas indiqué, contactez le service client.
2. S'il n'y a aucun problème d'accès, recherchez d'éventuels problèmes réseau. Si vous rencontrez des problèmes liés au réseau, corrigez-les.
3. S'il n'y a pas de problème réseau, vérifiez l'allocation de quotas. Si vous rencontrez des problèmes d'allocation de quotas, suivez la procédure pour augmenter les quotas. Cela devrait vous permettre de résoudre le problème.
4. S'il n'y a pas de problème d'allocation de quota, vérifiez les entrées de gravité des erreurs dans les journaux d'audit.
   1. Si le niveau d'erreur est indiqué, vérifiez les autorisations requises.
      1. Si vous pouvez accorder des autorisations permettant de résoudre les problèmes d'accès, résolvez le problème.
      2. Si vous ne parvenez pas à résoudre les problèmes d'accès, contactez le service client.
   2. Si le niveau d'erreur n'est pas indiqué, contactez le service client.

Les sections suivantes expliquent comment effectuer chaque étape de dépannage.

Valider l'accès utilisateur

Vérifiez si l'accès des utilisateurs est refusé à la fois dans la console Google Cloud et dans Google Cloud CLI :

1. Connectez-vous à la console Google Cloud en tant qu'utilisateur concerné.
2. Essayez d'accéder à la ressource. Par exemple, si l'utilisateur a signalé qu'il ne peut pas démarrer une VM, essayez de la démarrer.

3. Dans la console Google Cloud, ouvrez Cloud Shell et exécutez la commande gcloud CLI suivante à partir d'une session à laquelle l'utilisateur est connecté. Cette commande permet de vérifier si l'utilisateur est connecté à la bonne identité et s'il peut accéder à la ressource à l'aide de gcloud CLI.

   gcloud auth list
   

   Le résultat indique le compte auquel l'utilisateur est connecté.

4. Vérifiez si la commande précédente renvoie l'identité appropriée.

   • Si la commande précédente renvoie la mauvaise identité, demandez à l'utilisateur de se connecter à l'identité appropriée. Vérifiez ensuite si l'accès pose toujours problème lorsque l'utilisateur se sert de la bonne identité.
   • Si la commande précédente renvoie l'identité appropriée et que vous obtenez un message permission denied, exécutez la commande de gcloud CLI pour l'action que l'utilisateur souhaite effectuer. Pour en savoir plus sur le refus, ajoutez les options --log-http et --verbosity=debug.

5. Si vous identifiez un problème lié aux autorisations, passez à la section Vérifier les autorisations requises.

Rechercher des problèmes de réseau

1. Recherchez les problèmes de réseau en vous servant des conseils de la section Rechercher les erreurs liées à VPC Service Controls. Si un message d'erreur lié à un refus concernant VPC Service Controls s'affiche, corrigez le problème.
2. Vérifiez les chemins réseau de la source vers la destination à l'aide de tests de connectivité. Pour savoir comment tester la connectivité entre deux instances de VM dans un même réseau ou dans des réseaux appairés, consultez la page Effectuer des tests au sein des réseaux VPC.
3. Vérifiez la configuration du pare-feu en vous servant de la fonctionnalité Firewall Insights pour afficher les règles de pare-feu bloquées et les règles de refus susceptibles d'affecter les chemins d'accès.

Vérifier l'allocation des quotas

• Si vous ne trouvez aucun problème lié au réseau, vérifiez votre allocation de quotas. S'il semble y avoir un problème lié aux quotas, appliquez la procédure d'augmentation du quota que vous avez définie, le cas échéant.

Vérifier les journaux d'audit

• Vérifiez les fichiers journaux d'audit à l'aide de l'explorateur de journaux. L'explorateur de journaux fournit un résumé de la gravité d'une entrée de journal. Une "entrée de gravité" est consignée dans le journal d'erreurs lorsqu'un appel d'API échoue. Par exemple, une erreur est enregistrée si un utilisateur tente de créer un bucket Cloud Storage, mais ne dispose pas des autorisations nécessaires pour appeler storage.buckets.create.

  Le résumé d'une entrée de journal fournit les informations suivantes :

  • Nom de la ressource cible
  • Compte principal (qui essaie d'accéder à la ressource)
  • Appel d'API que le compte principal a tenté d'exécuter

Vérifier les autorisations requises

Pour déboguer les raisons pour lesquelles le compte principal ne dispose pas des autorisations requises, utilisez Policy Troubleshooter.

1. Si les vérifications indiquent que l'accès n'est pas accordé, vérifiez les rôles que Policy Troubleshooter indique comme disposant de l'autorisation.
2. Utilisez Policy Analyzer pour voir les autres comptes principaux ayant accès à la ressource à laquelle le compte principal est refusé.
3. Ajoutez l'identité du compte principal au groupe Google qui dispose d'une liaison au rôle approprié.

Contacter le service client

Si vous avez suivi les sections de dépannage précédentes et que vous ne parvenez pas à résoudre le problème, contactez Customer Care. Fournissez autant d'informations que possible, comme décrit dans la section Transmission au service client du guide de dépannage.

Exemples de cas d'utilisation pour le dépannage

Cette section fournit des instructions détaillées sur la résolution de cas d'utilisation spécifiques en suivant les étapes de dépannage précédentes. Pour tous les cas d'utilisation, vous devez disposer des autorisations appropriées pour utiliser les outils de dépannage décrits dans la section Résoudre les problèmes liés aux stratégies et aux accès sur Google Cloud.

Pour les cas d'utilisation suivants, nous supposons que vous utilisez Google Groupes pour gérer l'accès des utilisateurs. L'utilisation de Google Groupes pour accorder des autorisations vous permet de gérer les accès à grande échelle. Chaque membre d'un groupe Google hérite des rôles IAM (Identity and Access Management) qui sont attribués au groupe. Cet héritage signifie que vous pouvez utiliser l'appartenance à un groupe pour gérer les rôles des utilisateurs plutôt que d'attribuer des rôles Cloud IAM à des utilisateurs individuels.

Le délégateur de rôle résout les problèmes liés à l'accès des développeurs à un rôle d'administrateur Compute

En tant que délégateur de rôle, je dois comprendre pourquoi je ne peux pas attribuer un certain rôle à un développeur. J'attribue régulièrement des rôles d'administrateur de Compute aux nouveaux développeurs lorsqu'ils rejoignent mon équipe. Aujourd'hui, j'ai essayé d'accorder le rôle "Administrateur d'instances de Compute" et l'accès m'a été refusé.

Après avoir suivi la procédure de l'organigramme pour vérifier l'accès des utilisateurs et contrôler les journaux d'audit, vous pouvez confirmer qu'il s'agit d'un problème d'autorisation.

Pour attribuer des rôles, vous devez disposer de l'autorisation resourcemanager.projects.setIamPolicy. Cette autorisation peut être accordée dans le cadre des rôles suivants :

• Rôle d'administrateur de l'organisation (roles/resourcemanager.organizationAdmin)
• Rôle Administrateur IAM de dossier (roles/resourcemanager.folderIamAdmin)
• Rôle Administrateur IAM de projet (roles/resourcemanager.projectIamAdmin)

Pour déterminer si le délégateur de rôle dispose de l'autorisation resourcemanager.projects.setIamPolicy, vous pouvez utiliser Policy Troubleshooter. Si l'autorisation n'est plus attribuée, vérifiez les éléments suivants :

1. Vérifiez si une recommandation IAM qui a pu annuler la stratégie a été appliquée.
2. Si vous vous rappelez quand vous avez pu accorder des rôles pour la dernière fois, consultez les journaux pour vérifier si des appels setIam ont été effectués et ont pu modifier les règles appliquées.
3. Utilisez Policy Analyzer pour vérifier les comptes principaux disposant de resourcemanager.projects.setIamPolicy. Policy Analyzer peut vous aider à vérifier si le délégateur de rôle a été supprimé d'un groupe.

L'administrateur cloud résout les problèmes d'accès des développeurs à BigQuery

En tant qu'administrateur cloud, je dois comprendre pourquoi l'un des développeurs ne peut plus exécuter une requête sur un ensemble de données BigQuery.

Pour résoudre ce cas d'utilisation, vous devez d'abord vérifier l'accès utilisateur et résoudre les problèmes associés. Ensuite, recherchez les problèmes de réseau. Dans cet exemple, nous partons du principe que vous avez déterminé qu'il n'y a pas de problème d'identité ou de réseau, mais qu'il existe un problème d'autorisation.

Pour résoudre le problème d'autorisations, commencez par vérifier les autorisations des membres de l'équipe. Si vous ne constatez aucune différence, consultez les journaux pour identifier les problèmes potentiels. Si vous ne constatez aucun problème dans les journaux, vous pouvez contacter Customer Care pour obtenir de l'aide.

Vérifier les autorisations des membres de l'équipe

Pour vérifier les autorisations des membres de l'équipe, demandez tout d'abord au développeur quand il a réussi à exécuter la requête pour la dernière fois. Vérifiez ensuite si quelqu'un dans l'équipe du développeur a déjà pu exécuter la requête, et si cette personne peut toujours l'exécuter. Si aucun membre de l'équipe ne peut exécuter la requête, reportez-vous à la section Vérifier les journaux.

Si un membre de l'équipe peut toujours exécuter la requête, procédez comme suit :

1. Vérifiez les autorisations IAM accordées aux deux développeurs, et déterminez si leurs autorisations respectives diffèrent. Lorsque vous vérifiez les autorisations, recherchez les éléments suivants :
   • Autorisations IAM de BigQuery
   • Vues autorisées
   • Autorisations au niveau de la ligne
2. Si les autorisations ne diffèrent pas, passez à la section suivante, Vérifier les journaux. Si les autorisations diffèrent, procédez comme suit :
   1. Vérifiez si les deux membres de l'équipe appartiennent au même groupe Google.
      • S'ils n'appartiennent pas au même groupe Google, déterminez si cela devrait être le cas.
      • Si ces personnes appartenaient auparavant au même groupe Google, contactez l'administrateur du groupe pour déterminer la raison de ce changement.
3. Une fois le problème d'autorisation résolu, vérifiez si le développeur peut exécuter la requête.
   • Si le développeur peut exécuter la requête, résolvez le problème.
   • Si le développeur ne peut pas exécuter la requête, passez à la section suivante, Vérifier les journaux.

Vérifier les journaux

Si aucun membre de l'équipe ne peut effectuer la requête ou si le dépannage des problèmes d'autorisation n'a pas résolu le problème, vous pouvez consulter les journaux pour déterminer ce qui a pu être modifié depuis que le développeur a effectué la requête pour la dernière fois.

1. Déterminez où afficher les journaux de la dernière tâche terminée. Dans cet exemple, les journaux sont exportés vers BigQuery.
2. Exécutez des requêtes sur les journaux exportés dans BigQuery :
   1. Exécutez une requête qui inclut la dernière date d'accès du développeur afin de voir la tâche terminée.
   2. Exécutez la même requête pendant un certain temps en cas d'échec.
3. Si les journaux contiennent un élément identifiable, résolvez le problème à l'aide de Policy Troubleshooter et de Policy Analyzer, comme décrit dans la section Vérifier les autorisations requises.
4. Si vous ne parvenez toujours pas à résoudre le problème, contactez Customer Care.

Le développeur a besoin d'autorisations sur GKE

En tant que développeur, je dois comprendre pourquoi je ne peux pas démarrer, supprimer ou mettre à jour un pod, ni créer un déploiement dans le cluster Google Kubernetes Engine (GKE) auquel j'ai accès. Je ne suis pas sûr du compte principal que j'utilise lorsque je passe l'appel avec l'outil de ligne de commande kubectl, ni des autorisations dont je dispose.

Le rôle IAM qui permet à un développeur de démarrer, supprimer ou mettre à jour un pod ou de créer un déploiement dans le cluster GKE est le rôle Développeur Google Kubernetes Engine (roles/container.developer). Ce rôle doit être attribué dans le projet où réside le cluster GKE.

Pour résoudre ce cas d'utilisation, vous devez d'abord vérifier l'accès utilisateur et résoudre les problèmes associés. Après avoir validé l'identité, vous devez vous assurer que l'outil kubectl est configuré pour pointer vers le cluster approprié. Pour savoir comment vous assurer que l'identité utilisée par l'outil kubectl est correcte et que l'outil kubectl pointe vers le cluster approprié, consultez la section Configurer l'accès au cluster pour kubectl. Dans cet exemple, nous partons du principe que vous avez déterminé qu'il n'y a pas de problème de réseau ni de problème lié au quota, mais qu'il existe un problème d'autorisation.

Pour commencer à résoudre le problème lié aux autorisations, consultez les journaux d'audit afin de voir ce qui a changé entre la dernière action réussie du développeur et l'heure du premier signalement.

1. Si le développeur a déjà eu accès au cluster auparavant, vérifiez si un membre de l'équipe autorisé à effectuer les mêmes actions peut toujours les effectuer. Si le membre de l'équipe peut accéder au cluster, utilisez Policy Analyzer pour déterminer le type d'accès dont ce membre dispose. Si vous suivez les bonnes pratiques, les deux développeurs doivent faire partie du même groupe et disposer des mêmes autorisations.

   1. Si leurs autorisations sont identiques et qu'aucun développeur ne peut effectuer les actions sur la ressource, vérifiez si des recommandations IAM ont été appliquées et peuvent affecter l'accès.
   2. Si leurs autorisations sont différentes, examinez l'origine de cette différence :
      1. Consultez les journaux d'audit de la dernière fois où le développeur a pu effectuer la tâche. Comparez les journaux avec ceux de la dernière tentative échouée.
      2. Vérifiez les recommandations IAM et appliquez les recommandations éventuelles.

2. S'il n'y a pas d'autre membre de l'équipe à valider, utilisez Policy Troubleshooter et Policy Analyzer, comme décrit dans la section Vérifier les autorisations requises. Pour en savoir plus, consultez les ressources suivantes :

   • Interaction GKE avec IAM
   • Google Groupes pour GKE
   • Rôles IAM pour GKE

3. Si vous ne parvenez toujours pas à résoudre le problème, contactez Customer Care.

L'administrateur de la sécurité résout les problèmes liés à l'accès des développeurs

En tant qu'administrateur de sécurité, je dois comprendre pourquoi un développeur n'a pas pu effectuer une action. Quel est le meilleur rôle et l'emplacement à attribuer à ce rôle pour que celui-ci ne fournisse pas plus de droits d'accès que ce dont l'utilisateur a besoin ?

Dans ce scénario, le développeur doit pouvoir effectuer les opérations suivantes :

• Importer des objets dans un bucket Cloud Storage. Le développeur ne doit pas être en mesure d'afficher, de supprimer ou d'écraser les objets existants dans le bucket.
• Démarrer des instances dans leur projet de développement.

Pour connaître les autorisations requises pour effectuer la tâche dont votre développeur doit disposer, utilisez Policy Troubleshooter et la page de référence Comprendre les rôles IAM. Dans cet exemple, vous devez attribuer à votre développeur un rôle comprenant les autorisations suivantes :

• Pour autorise le développeur à arrêter et à démarrer les instances : compute.instances.start et compute.instances.stop.
• Pour autoriser le développeur à importer des objets dans des buckets Cloud Storage : storage.objects.create.

Les rôles suivants incluent les autorisations précédentes et respectent le principe du moindre privilège :

• Au niveau du bucket dans lequel le développeur est autorisé à importer des objets, attribuez le rôle Créateur des objets de l'espace de stockage (roles/storage.objectCreator).
• Au niveau du projet attribué au développeur ou de l'instance que le développeur doit pouvoir redémarrer, accordez le rôle Administrateur d'instances de Compute (roles/compute.instanceAdmin).

En règle générale, la gestion des instances peut également nécessiter des actions telles que l'ajout de disques. Dans ce cas, le rôle roles/compute.instanceAdmin peut constituer un moyen approprié d'accorder les autorisations requises tout en respectant le principe du moindre privilège.

L'administrateur cloud comprend pourquoi une application ne peut pas écrire sur Cloud Storage

En tant qu'administrateur cloud, je dois comprendre pourquoi une application exécutée sur GKE ne peut plus écrire dans Cloud Storage.

Dans ce scénario, une application exécutée sur GKE doit être configurée comme suit :

• Sur un bucket spécifié, l'application peut ajouter, mettre à jour et supprimer des objets.
• L'application ne peut accéder à aucun autre bucket de l'organisation.

L'approche de dépannage suivante suppose que vous utilisez Workload Identity, que nous vous recommandons. Avec Workload Identity, vous pouvez configurer un compte de service Kubernetes qui agira en tant que compte de service Google. Les pods exécutés en tant que compte de service Kubernetes s'authentifient automatiquement en tant que compte de service Google lorsqu'ils accèdent aux API Google Cloud.

Dans cet exemple, vous vérifiez que vous avez accordé les autorisations appropriées au compte de service Google que vous utilisez pour Workload Identity pour votre cluster. Pour connaître les autorisations requises pour effectuer les tâches de votre application, utilisez Policy Troubleshooter et la page de référence Comprendre les rôles IAM. Pour configurer et valider les autorisations, procédez comme suit :

1. Attribuez les autorisations suivantes au compte de service Google que vous utilisez pour Workload Identity :

   1. Au niveau du bucket dans lequel l'application est autorisée à contrôler entièrement les objets, y compris répertorier, créer, afficher et supprimer des objets, accordez le rôle "Administrateur des objets de l'espace de stockage" (roles/storage.objectAdmin).

   2. Pour configurer le compte de service Kubernetes afin qu'il emprunte l'identité du compte de service Google, définissez une liaison de stratégie IAM :

      gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]" \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      

      Remplacez les valeurs suivantes :

      • PROJECT_ID : ID de votre projet.
      • KSA_NAME : compte de service Kubernetes qui effectue la requête.
      • KUBERNETES_NAMESPACE : l'espace de noms Kubernetes dans lequel le compte de service Kubernetes est défini.
      • GSA_NAME : compte de service Google.

2. Définissez l'autorisation iam.serviceAccounts.setIamPolicy sur le projet :

   • Ajoutez l'annotation suivante au compte de service Kubernetes :

     iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID
     

3. Vérifiez que le compte de service Google dispose des autorisations appropriées et que Workload Identity est correctement configuré :

   1. Au niveau du bucket dans lequel l'application est autorisée à contrôler entièrement les objets, affichez la stratégie IAM du bucket et vérifiez que le compte de service Google dispose du rôle roles/storage.objectAdmin.
   2. Si les autorisations ne sont pas appropriées, modifiez la stratégie pour accorder au compte de service Google l'autorisation requise.

4. Vérifiez que Workload Identity est correctement configuré en vérifiant qu'il existe une liaison au compte de service Kubernetes :

   gcloud iam service-accounts get-iam-policy \
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
   

   La sortie ressemble à ceci :

   - members:
     - serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KSA_NAME]
     role: roles/iam.workloadIdentityUser
   

   Si la liaison est incorrecte, répétez les étapes précédentes pour attribuer des autorisations au compte de service.

Étapes suivantes

• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.