Mit der ordnerbasierten Mitgliedschaftsfunktion in VPC Service Controls können Sie Dienstperimeter mit Google Cloud Ordnern als Mitglieder definieren. Mit dieser Funktion können Sie eine gesamte Ordnerhierarchie mit einer einzigen Perimeterkonfiguration schützen. So wird der Verwaltungsaufwand für die Perimeterverwaltung im großen Maßstab reduziert.
In diesem Dokument wird beschrieben, wie die Unterstützung von Ordnern in Perimetern funktioniert. Außerdem werden die folgenden Themen behandelt:
Grundlegende Konzepte, Verhaltensweisen und Vorteile der Verwendung von Ordnern in Perimetern.
Interaktionen zwischen der Mitgliedschaft auf Ordnerebene, verschachtelten Ressourcen und Regeln für die Ressourcenhierarchie wie Vererbung und Vorrang bei der Auswertung.
Konfigurierte Perimeters für Projekte und Ordner nachschlagen
Best Practices und bekannte Einschränkungen für die Verwendung dieser Funktion.
Ordner in Perimetern
Ein Google Cloud Ordner kann mehrere Projekte, andere Ordner oder eine Kombination aus beidem enthalten. Sie können zwar einzelne Projekte in einem Ordner einem Dienstperimeter hinzufügen, wir empfehlen jedoch, stattdessen den übergeordneten Ordner hinzuzufügen. Wenn Sie beim Erstellen eines Perimeters einen Ordner als geschützte Ressource angeben, umfasst VPC Service Controls alle Ressourcen in diesem Ordner, z. B. Projekte und verschachtelte Ordner.
Wenn Sie einem Ordner, den Sie in einem Perimeter konfiguriert haben, Projekte hinzufügen, fügt VPC Service Controls diese Projekte automatisch demselben Perimeter hinzu. Sie müssen die Perimeterkonfiguration nicht aktualisieren, um diese Projekte einzubeziehen. Wenn Sie Projekte aus dem Ordner entfernen, werden sie von VPC Service Controls automatisch aus dem Perimeter entfernt.
Verschachtelte Ordner und Übernahme
VPC Service Controls schränkt alle Ressourcen in einem Ordner ein, den Sie in einem Perimeter konfiguriert haben, z. B. verschachtelte Ordner und deren Ressourcen. Wenn Sie einem Perimeter einen Ordner hinzufügen, werden alle Projekte in diesem Ordner und seinen Unterordnern automatisch durch VPC Service Controls eingeschränkt.
Vorrang bei der Bewertung der Ressourcenmitgliedschaft
Eine Google Cloud -Ressource kann nur durch einen regulären Dienstperimeter im erzwungenen Modus und einen im Probelaufmodus geschützt werden. Wenn eine Ressource oder ihre übergeordneten Ordner mehreren Perimetern zugeordnet sind, bestimmt die Zuordnung auf der niedrigsten Ebene in der Ressourcenhierarchie den effektiven Perimeter.
VPC Service Controls wertet die Priorität unabhängig für den erzwingenden Modus und den Probelaufmodus aus:
- Vorrang des erzwungenen Modus: Der effektive erzwungene Perimeter wird durch die niedrigste Ressource in der Hierarchie (das Projekt selbst oder der nächstgelegene übergeordnete Ordner) bestimmt, die explizit einem erzwungenen Perimeter zugewiesen ist.
- Vorrang des Probelaufmodus: Der effektive Probelaufperimeter wird durch die niedrigste Ressource in der Hierarchie bestimmt, die explizit einem Probelaufperimeter zugewiesen oder implizit von einer explizit zugewiesenen erzwungenen Ressource übernommen wird.
Wenn Sie einen Perimeter für den Probelauf für ein Projekt oder einen Unterordner konfigurieren, wird ein erzwungener Perimeter, der für einen übergeordneten Ordner konfiguriert ist, dadurch nicht deaktiviert oder überschrieben.
Beispiele für Vorrang
Beispiel 1 (Direktes Überschreiben des Projekts im erzwungenen Modus): Wenn Sie einen übergeordneten Ordner (
folders/1) in einem erzwungenen Perimeter (sp1) konfigurieren und ein Projekt in diesem Ordner (projects/1) explizit in einem anderen erzwungenen Perimeter (sp2) konfigurieren, wirdprojects/1durchsp2geschützt. Die direkte Projektzuweisung hat Vorrang vor der Ordnervererbung. Alle anderen Projekte infolders/1(z. B.projects/2) sind weiterhin durchsp1über die Ordnervererbung geschützt.Beispiel 2 (Ordnerübernahme im Probelaufmodus): Wenn Sie einen Ordner (
folders/1) in einem Dienstperimeter im Probelaufmodus konfigurieren, übernehmen alle Projekte in diesem Ordner (projects/1undprojects/2) die Perimeterkonfiguration für den Probelauf (sp1), sofern sie nicht explizit deaktiviert ist. Die Übernahme im Probelaufmodus verhält sich identisch mit der Übernahme im erzwungenen Modus, es sei denn, für eine verschachtelte Ressource ist explizit ein anderer Probelaufperimeter konfiguriert.Beispiel 3 (Unabhängige Auswertung von erzwungenen und Probelauf-Perimetern): VPC Service Controls wertet erzwungene und Probelauf-Zuordnungen unabhängig voneinander aus. Wenn Sie einen übergeordneten Ordner (
folders/1) in einem erzwungenen Perimeter (sp1) konfigurieren und ein Projekt in diesem Ordner (projects/1) explizit einem Probelaufperimeter (sp2) zuweisen, bleibtprojects/1im erzwungenen Modus durchsp1geschützt und wird gleichzeitig im Probelaufmodus vonsp2ausgewertet. Wenn Sie ein Projekt einem Probelaufperimeter zuweisen, wird der erzwungene Perimeter des übergeordneten Ordners dadurch nicht überschrieben oder deaktiviert.Beispiel 4 (Ordnerhierarchie mit mehreren Ebenen und Vorrang von Unterordnern): In einer Ordnerhierarchie mit mehreren Ebenen wird der Vorrang von VPC Service Controls auf jeder Ebene der Hierarchie ausgewertet. Wenn ein übergeordneter Ordner (
folders/2) in einem erzwungenen Perimeter (sp1) konfiguriert ist, erben alle enthaltenen Projekte (projects/1undprojects/2) die Erzwingung vonsp1. Wenn Probelaufperimeter auf verschiedenen Ebenen zugewiesen werden, z. B. wenn der übergeordnetefolders/2dem Probelaufperimetersp2und das Projektprojects/2(im Unterordnerfolders/1) dem Probelaufperimetersp1zugewiesen wird, erbt jedes Projekt die Probelaufkonfiguration von seinem nächstgelegenen übergeordneten Element. Daher wirdprojects/1imsp2-Probelauf ausgewertet,projects/2jedoch imsp1-Probelauf.
Effektive konfigurierte Perimeter nachschlagen
Da Ressourcen den Perimeterschutz von übergeordneten Ordnern übernehmen können, können Sie mit der Methode LookupConfiguredServicePerimeter ermitteln, welche Dienstperimeter ein Projekt oder einen Ordner schützen.
Die API gibt Folgendes zurück:
servicePerimeter: Der vollständig qualifizierte Name des effektiv erzwungenen Perimeters.servicePerimeterDryRun: Der voll qualifizierte Name des effektiven Testlauf-Perimeters.restrictedResource: Die spezifische Ressource (Projekt oder Ordner), an die der erzwungene Perimeter direkt angehängt ist.restrictedResourceDryRun: Die spezifische Ressource, an die der Perimeter für den Probebetrieb direkt angehängt ist.
Weitere Informationen finden Sie unter Konfigurierte Perimeters suchen.
Ausschluss von Projekten aus Perimetern
Wenn Sie ein Projekt aus einem Perimeter auf Ordnerebene ausschließen möchten, weisen Sie es explizit einem separaten Perimeter zu, der keine Dienste einschränkt und den gesamten ein- und ausgehenden Traffic zulässt. Da explizite Projektkonfigurationen Vorrang vor Perimetern auf Ordnerebene haben, wird das Projekt aus dem Ordnerperimeter ausgeschlossen.
Informationen zum Aktualisieren von Perimetern finden Sie unter Dienstperimeter aktualisieren.
Richtlinien mit eingeschränktem Geltungsbereich
Dienstperimeter in einer Richtlinie mit eingeschränktem Umfang schränken nur die Ressourcen ein, die im Umfang dieser Richtlinie enthalten sind. Damit ein Ordner als Mitglied in einen bereichsbezogenen Perimeter aufgenommen werden kann, muss die Zugriffsrichtlinie auf diesen Ordner oder ein übergeordnetes Element dieses Ordners (z. B. ein übergeordneter Ordner oder die Organisation) beschränkt sein.
Best Practices
Beachten Sie die folgenden Best Practices, wenn Sie ordnerbasierte Perimeter verwalten.
Sichere Migration von Projekten in Ordnerbereiche
Wenn Sie von expliziten Projektmitgliedschaften zu ordnerbasierten Mitgliedschaften wechseln, sollten Sie die folgenden Schritte ausführen, um unbeabsichtigte Unterbrechungen der Perimeterdurchsetzung zu vermeiden:
- Fügen Sie dem Dienstperimeter den Zielüberordner hinzu.
- Verschieben Sie die Projekte unter diesem übergeordneten Ordner in der Ressourcenhierarchie.
- Mindestens 48 Stunden warten: Behalten Sie die expliziten Projekteinträge in der Perimeterkonfiguration mindestens 48 Stunden lang bei. Während dieser Wartezeit kann die Weitergabe der Ressourcenhierarchie in allen Systemen abgeschlossen werden.
- Entfernen Sie die expliziten Projektkonfigurationen aus dem Perimeter. Die Projekte bleiben durch die Ordnerübernahme geschützt.
Hierarchieänderungen
Wenn Sie Ordner oder Projekte verschieben, ändert sich der effektive Perimeterschutz. Um unerwartete Zugriffsverweigerungen zu vermeiden, sollten Sie alle Hierarchieänderungen mit Ihrem Resource Manager-Administrator abstimmen.
Wenn Sie Projekte, die Sie in einem Perimeter konfiguriert haben, in einen anderen Ordner verschieben und diesen Ordner demselben Perimeter hinzufügen, müssen Sie die vorhandenen expliziten Projektmitgliedschaftskonfigurationen im Perimeter mindestens 48 Stunden lang beibehalten. Diese Wartezeit ermöglicht die Weitergabe der Ressourcenhierarchie und verhindert unerwartete Probleme bei der Durchsetzung des Perimeters, wenn Sie die expliziten Projektkonfigurationen aus dem Perimeter entfernen.
Beschränkungen
Die ordnerbasierte Mitgliedschaft wird in Perimeter-Bridges nicht unterstützt. Perimeter-Bridges akzeptieren nur Projektressourcen.
VPC Service Controls unterstützt keine API-Ressourcen auf Ordner- oder Organisationsebene.
Aufgrund eines bekannten Problems wird die ordnerbasierte Erzwingung überschrieben, wenn ein VPC-Netzwerkprojekt als geschützte Ressource in einem Probelaufperimeter konfiguriert wird. Wenn ein Netzwerkprojekt explizit einem Perimeter für den Probebetrieb hinzugefügt wird, verliert es den erzwungenen Perimeterschutz, der von den übergeordneten Ordnern übernommen wurde.
Die Ordnerzugehörigkeit wird für Nicht-Google Cloud -APIs und mit
allowed_service_patternskonfigurierte Perimeters nicht unterstützt. Damit der Zugriff auf diese Dienstmuster möglich ist, müssen die Quellprojekte oder VPC-Netzwerke explizit dem Perimeter hinzugefügt werden und können nicht über einen Ordner übernommen werden.
Nächste Schritte
- Ordner in Dienstperimetern konfigurieren
- VPC Service Controls
- Weitere Informationen zu Dienstperimetern
- Weitere Informationen zum Entwerfen von Dienstperimetern