Les ressources présentes dans Google Cloud sont organisées selon une hiérarchie, dont chacun des nœuds (Organisations, Dossiers, Projets, etc.) fait référence à son parent. Vous pouvez utiliser cette référence comme une expression de filtre par clé permettant aux analyses d'améliorer la cohérence des recherches de ressources.
Vous pouvez accorder des autorisations aux utilisateurs en définissant des rôles personnalisés. Ces rôles fonctionnent selon le principe du moindre privilège et ne fournissent généralement que le minimum d'autorisations nécessaires pour effectuer une tâche donnée.
Un tel dispositif peut être utile pour isoler différents groupes d'utilisateurs. Exemples :
- Une grande entreprise dont les différents services ne doivent pas avoir la possibilité d'inspecter les ressources les uns des autres
- Des sous-traitants recevant des autorisations pour un projet spécifique à l'exclusion de toute autre ressource
Toutefois, en raison de leurs autorisations restreintes, les rôles personnalisés peuvent entraîner l'omission de nombreuses ressources de votre hiérarchie lors de l'exécution d'une opération de liste. Lorsque vous effectuez des recherches en tant qu'utilisateur doté d'un rôle personnalisé, il peut être difficile de déterminer pourquoi certaines ressources ne s'affichent pas.
Pour éviter cela, cette page présente les bonnes pratiques à suivre pour répertorier tous les des ressources gérées par l'API Cloud Resource Manager dans votre hiérarchie de ressources. Ces conseils peuvent vous aider à configurer des vérifications d'audit personnalisées, ou à créer votre propre expérience utilisateur en plus de l'API Cloud Resource Manager.
Répertorier tous les nœuds de ressources
Lorsque vous analysez votre hiérarchie de ressources afin de répertorier toutes les ressources, il importe que les résultats obtenus soient fortement cohérents. Si votre analyse omet certaines ressources ou fournit des résultats obsolètes, il peut être difficile de déterminer si un problème est survenu. Pour obtenir à coup sûr les résultats les plus précis et les plus complets possibles, utilisez un compte de service et procédez comme suit pour l'analyse :
- Attribuez à un compte de service les autorisations
list
etget
pour les organisations, les dossiers et les projets de la ressource Organisation. - Si vous répertoriez les ressources de projets et de dossiers, spécifiez la ressource parente dans la chaîne de filtre.
- Exécutez la méthode
projects.list()
via ce compte de service pour chaque type de ressource recherché, ainsi que pour toutes les ressources intermédiaires telles que les dossiers.
Exemple de liste de tous les nœuds de ressources
L'exemple qui suit explique comment répertorier tous les nœuds de ressources de votre organisation :
organizations = organizations.search()
projects = emptyList()
parentsToList = queueOf(organizations)
while (parent = parentsToList.pop()) {
// TODO: Iterate over paginated results as needed.
// TODO: Handle PERMISSION_DENIED appropriately.
projects.addAll(projects.list(parent.type, parent.id))
parentsToList.addAll(folders.list(parent))
}
Lorsque vous créez une expérience utilisateur personnalisée, vous pouvez également avoir besoin de mélanger les résultats de recherche et de charger les ressources parentes selon vos besoins (tout en interceptant l'exception PERMISSION_DENIED
).
Réduire la latence sur la liste des projets gcloud
Si votre requête gcloud projects list
échoue ou prend trop de temps, le nombre de projets Google Cloud à renvoyer peut être trop élevé. Pour résoudre ce problème, appliquez les options filter
et page-size
à votre commande gcloud projects list
.
Pour en savoir plus sur les options que vous pouvez ajouter à votre commande gcloud projects list
, consultez la page sur les projets gcloud.
Exemple d'exclusion de projets Apps Script
Le plus souvent, les échecs ou la latence des requêtes sont dus à un nombre élevé de projets Apps Script au sein d'une organisation. La commande suivante montre comment exclure les projets Apps Script de la liste des projets et limiter le nombre de ressources ; renvoyées par page.
gcloud projects list --filter="NOT parent.id: 'APPS_SCRIPT_FOLDER_ID' "--page-size='30'
Obtenir l'ID du dossier Apps Script
Pour trouver l'ID de votre dossier Apps Script, procédez comme suit :
Dans la barre d'outils de la console Google Cloud, cliquez sur Recherchez des ressources, des documents, des produits, etc., puis saisissez
apps-script
.Sous Ressources, sélectionnez le dossier apps-script.
Sous ID du dossier, copiez l'ID du dossier.
Rechercher des ressources
Si votre analyse a pour but de rechercher une ressource qui a été créée il y a quelque temps, vous pouvez effectuer une analyse plus rapide privilégiant une cohérence à terme par rapport à une cohérence forte. Notez que cette méthode de recherche peut exclure certaines ressources des résultats, en particulier celles qui ont été modifiées récemment. Pour rechercher des ressources, procédez comme suit :
- Utilisez un compte de service disposant de l'autorisation
get
pour la ressource que vous recherchez. - Exécutez la méthode
projects.search()
avec ce compte de service.
Résoudre les problèmes d'omission de ressources
Si vous développez un outil d'analyse, nous vous recommandons d'utiliser les autorisations list
et get
accordées au niveau de l'organisation. Vous évitez ainsi les problèmes liés au caractère partiel des autorisations détenues par l'utilisateur, qui entraîne l'omission de certaines ressources dans la liste.
Si vous concevez une expérience utilisateur personnalisée qui vérifie les autorisations des utilisateurs, il n'existe pas de solution simple. Si un utilisateur ne détient pas les autorisations requises au niveau de l'organisation, il lui faudra disposer de certaines autorisations sur chacune des ressources à répertorier. Si un utilisateur ne dispose pas des autorisations nécessaires sur une ressource de la hiérarchie, certaines ressources risquent de ne pas s'afficher.
Si un utilisateur dispose de l'autorisation list
, mais pas de l'autorisation get
pour un
ressource spécifique, celle-ci ne sera pas visible du tout
console Google Cloud. Cependant, la ressource est renvoyée lors d'une recherche à l'aide de la méthode
API ou Google Cloud CLI qui spécifie le parent de la ressource. Cette disparité
entre la console Google Cloud et d'autres méthodes est souvent source de confusion
lorsque vous essayez d'analyser
la hiérarchie des ressources.
Les schémas suivants illustrent certaines configurations courantes des autorisations, en indiquant comment elles modifient les ressources visibles par un utilisateur effectuant une recherche.
Dans cet exemple, toutes les autorisations requises sont accordées dans la ressource Organisation. Par conséquent, la hiérarchie tout entière est visible lorsque vous effectuez une recherche ou une opération de liste.
Dans cet exemple, l'utilisateur dispose de toutes les autorisations requises à l'exception de resourcemanager.organizations.get
, mais ces autorisations ne lui sont accordées qu'au niveau du dossier. Lors des opérations de liste ou de recherche, cette lacune dans les autorisations lui donne une visibilité totale sur une branche de la hiérarchie, mais pas sur l'autre.
Cet exemple illustre l'expérience d'un utilisateur ne disposant que de l'autorisation resourcemanager.projects.get
accordée au niveau d'une ressource Dossier.
L'utilisateur peut voir les projets situés sous ce dossier dans la hiérarchie, mais uniquement en effectuant une recherche. La fonctionnalité de liste ne renvoie aucun résultat.
Cet exemple présente le même problème que le précédent : les autorisations accordées permettent uniquement à l'utilisateur de trouver ses ressources Dossier via des recherches. La fonctionnalité de liste ne renvoie aucun résultat.
Dans cet exemple, les utilisateurs disposent d'une combinaison d'autorisations au sein de leur organisation.
Ils peuvent obtenir la liste des dossiers depuis le niveau de l'organisation, ce qui leur permet de retrouver les dossiers de l'ensemble de la hiérarchie via des recherches spécifiant la ressource parente.
Ils peuvent répertorier les ressources Projet d'un dossier, mais pas celles de l'autre, et ils disposent de l'autorisation resourcemanager.projects.get
pour un projet situé au niveau inférieur de la hiérarchie.
Ils n'ont donc pas la possibilité de répertorier les projets de la branche de gauche de cette hiérarchie de ressources. Ils peuvent lister les projets sur le côté droit uniquement en à l'aide d'une recherche spécifiant la ressource parente. Un seul projet est visibles dans la console Google Cloud.
Dans cet exemple, les utilisateurs peuvent récupérer la ressource Organisation et répertorier les ressources Projet de la hiérarchie tout entière en spécifiant la ressource parente. En revanche, ils n'ont pas la possibilité de répertorier ni de rechercher les dossiers intermédiaires. L'utilisateur ne peut rechercher des projets que s'il connaît l'ID de leur dossier parent. Les dossiers ne sont pas du tout visibles par cet utilisateur, qui ne peut donc pas retrouver leur ID s'il ne le connaît pas déjà. La seule ressource qui apparaît dans la console Google Cloud est l'organisation.
Lors de la conception de votre expérience utilisateur personnalisée, il est important d'identifier les situations comparables à celles décrites ci-dessus. Vous pouvez afficher la hiérarchie des ressources à l'aide d'une combinaison d'opérations de liste et de recherche. Vous pouvez également réfléchir à la manière d'indiquer aux utilisateurs qu'il leur manque certaines autorisations pour afficher la hiérarchie des ressources tout entière.