Alle Projekte und Ordner in Ihrer Hierarchie auflisten

Mit der Cloud Resource Manager API können Sie alle Ordner und Projekte in Ihrer Ressourcenhierarchie von Cloud de Confiance by S3NSerkennen und katalogisieren. Diese Transparenz hilft Ihnen, Audits durchzuführen und benutzerdefinierte Verwaltungstools zu erstellen. Bei Standardlistenvorgängen können Ressourcen weggelassen werden, wenn Nutzer eingeschränkte benutzerdefinierte Rollen haben. Sie können Ihre Abfragen nach übergeordneten Verweisen filtern, um konsistente Suchergebnisse zu erhalten und Knoten zu identifizieren, die sonst durch Berechtigungen mit geringsten Berechtigungen ausgeblendet werden könnten.

Alle Ressourcenknoten auflisten

Wenn Sie Ihre Ressourcenhierarchie scannen, um alle Ressourcen aufzulisten, benötigen Sie strikt konsistente Ergebnisse. Wenn bei Ihrem Scan Ressourcen fehlen oder veraltete Ergebnisse angezeigt werden, kann es schwierig sein, festzustellen, ob ein Fehler aufgetreten ist. Damit Sie immer die genauesten und vollständigsten Ergebnisse erhalten, verwenden Sie ein Dienstkonto und führen Sie einen Scan auf folgende Weise durch:

1. Gewähren Sie einem Dienstkonto die Berechtigungen list und get für Organisationen, Ordner und Projekte in der Organisationsressource.
2. Wenn Sie Projekt- und Ordnerressourcen auflisten, geben Sie im Filterstring die übergeordnete Ressource an.
3. Führen Sie die Methode projects.list() mit diesem Dienstkonto für jeden Ressourcentyp aus, den Sie finden möchten, sowie für alle Zwischenressourcen wie Ordner.

Beispiel zum Auflisten aller Ressourcenknoten

Der folgende Pseudocode zeigt, wie Sie alle Ressourcenknoten in Ihren Organisationen auflisten können:

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))
}

Wenn Sie eine benutzerdefinierte Konfiguration vornehmen, können Sie auch Suchergebnisse mit aufnehmen, nach Bedarf die übergeordneten Ressourcen laden und gleichzeitig die Ausnahme PERMISSION_DENIED erkennen.

Latenz bei „gcloud projects list“ verringern

Wenn Ihre gcloud projects list-Abfrage fehlschlägt oder zu lange dauert, ist die Anzahl der zurückzugebendenCloud de Confiance by S3NS -Projekte möglicherweise zu groß. Wenden Sie die Flags filter und page-size auf den Befehl gcloud projects list an, um das Problem zu beheben.

Weitere Informationen zu den Flags, die Sie Ihrem gcloud projects list-Befehl hinzufügen können, finden Sie unter gcloud projects list.

Beispiel für das Ausschließen von Apps Script-Projekten

Die häufigste Ursache für Abfragefehler oder -latenzen ist eine hohe Anzahl von Apps Script-Projekten innerhalb einer Organisation. Der folgende Befehl zeigt, wie Sie Apps Script-Projekte aus der Projektliste ausschließen und die Anzahl der pro Seite zurückgegebenen Ressourcen begrenzen.

gcloud projects list --filter="NOT parent.id: 'APPS_SCRIPT_FOLDER_ID' "--page-size='30'

Apps Script-Ordner-ID abrufen

So finden Sie die ID Ihres Apps Script-Ordners:

1. Klicken Sie in der Symbolleiste der Cloud de Confiance Console auf Nach Ressourcen, Dokumenten, Produkten und mehr suchen und geben Sie apps-script ein.

   Zur Cloud de Confiance Console

2. Wählen Sie unter Ressourcen den Ordner apps-script aus.

3. Kopieren Sie unter Ordner-ID die Ordner-ID.

Ressourcen suchen

Wenn Sie eine Ressource suchen, die vor einiger Zeit erstellt wurde, können Sie den Scan mit Eventual Consistency anstelle von strikter Konsistenz ausführen. Beachten Sie, dass bei dieser Suchmethode einige Ressourcen aus dem Suchergebnis ausgelassen werden, insbesondere solche, die kürzlich geändert wurden. So suchen Sie Ressourcen:

1. Verwenden Sie ein Dienstkonto mit der Berechtigung get für die Ressource, nach der Sie suchen.
2. Führen Sie die Methode projects.search() mit diesem Dienstkonto aus.

Fehlerbehebung bei ausgelassenen Ressourcen

Wenn Sie ein Scan-Tool entwickeln, empfehlen wir die Verwendung der Berechtigungen list und get auf Organisationsebene. Dadurch vermeiden Sie Probleme, die verursacht werden, wenn der Nutzer nur Teilberechtigungen hat, was dazu führt, dass einige Ressourcen aus der Liste ausgelassen werden.

Wenn Sie eine benutzerdefinierte Nutzererfahrung entwerfen, die Nutzerberechtigungen prüft, gibt es keine einfache Lösung. Wenn ein Nutzer keine Berechtigungen auf Organisationsebene hat, benötigt er für jede einzelne Ressource bestimmte Berechtigungen, damit sie angezeigt werden. Wenn einem Nutzer Berechtigungen für eine Ressource irgendwo in der Hierarchie fehlen, werden möglicherweise einige Ressourcen nicht angezeigt.

Wenn ein Nutzer die Berechtigung list, aber nicht die Berechtigung get für eine bestimmte Ressource hat, ist diese Ressource in derCloud de Confiance Console überhaupt nicht sichtbar. Die Ressource wird jedoch in einer Suche mit der API oder der Google Cloud CLI zurückgegeben, die das übergeordnete Element der Ressource angibt. Diese Diskrepanz zwischen der Cloud de Confiance Console und anderen Methoden ist eine häufige Ursache für Verwirrung beim Scannen der Ressourcenhierarchie.

In den folgenden Diagrammen werden einige gängige Konfigurationen von Berechtigungen erläutert. Außerdem wird beschrieben, wie sie die Sichtbarkeit von Ressourcen bei einer Suche beeinflussen.

In diesem Beispiel werden alle erforderlichen Berechtigungen in der Organisationsressource erteilt. Daher ist beim Ausführen einer Liste oder Suche die gesamte Hierarchie sichtbar.

Der Nutzer in diesem Beispiel hat alle erforderlichen Berechtigungen mit Ausnahme von resourcemanager.organizations.get, aber diese Berechtigungen gelten auf Ordnerebene. Durch diese Berechtigungslücke besteht vollständige Sichtbarkeit in der Liste oder Suche dieses Teils der Hierarchie, aber nicht in der anderen Hälfte.

Dieses Beispiel zeigt, was ein Nutzer sieht, der die Berechtigung resourcemanager.projects.get nur auf Ordnerebene hat. Er kann die Projekte sehen, die in der Hierarchie diesem Ordner untergeordnet sind, aber nur über eine Suchanfrage. Wenn Sie die Listenfunktion verwenden, werden keine Ergebnisse zurückgegeben.

In diesem Beispiel wird ein ähnliches Szenario veranschaulicht, in dem Sie mit den gewährten Berechtigungen nur nach Ihren Ordnerressourcen suchen können. Der Listenvorgang gibt keine Ergebnisse zurück.

Der Nutzer in diesem Beispiel hat in seiner gesamten Organisation verschiedene Berechtigungen. Er kann Ordner auf Organisationsebene auflisten, sodass er sie mit Suchanfragen findet, in denen die übergeordnete Ressource in der Hierarchie angegeben ist. Er kann Projektressourcen für einen Ordner auflisten, aber nicht für den anderen, und er hat die Berechtigung resourcemanager.projects.get für ein Projekt am Ende der Hierarchie.

Dies führt dazu, dass die Projekte auf der linken Seite dieser Ressourcenhierarchie nicht zurückgegeben werden. Sie können die Projekte auf der rechten Seite nur über eine Suche auflisten, die die übergeordnete Ressource angibt. In der Cloud de Confiance Console ist nur ein Projekt sichtbar.

In diesem Beispiel können Sie die Organisationsressource abrufen und Projektressourcen auflisten, indem Sie das übergeordnete Element in der gesamten Hierarchie angeben. Sie sind jedoch nicht berechtigt, Zwischenordner aufzulisten oder zu durchsuchen. Ihre Projekte sind durchsuchbar, wenn Sie die ID des übergeordneten Ordners kennen. Die Ordner sind für Sie nicht sichtbar. Sie können die ID also nicht ermitteln, wenn Sie sie nicht bereits haben. Die einzige Ressource, die in der Cloud de Confiance Console angezeigt wird, ist die Organisation.

Wenn Sie Ihre benutzerdefinierte Nutzererfahrung entwerfen, sollten Sie sich ähnlicher Situationen bewusst sein. Sie können eine Kombination aus Listen und Suchvorgängen verwenden, um die Ressourcenhierarchie darzustellen. Überlegen Sie sich auch, wie Sie den Nutzern mitteilen können, dass ihnen Berechtigungen fehlen, mit denen sie die gesamte Ressourcenhierarchie sehen könnten.