Der Stammknoten für die Verwaltung von Ressourcen in Google Cloud ist die Organisation. Die Google Cloud-Organisation bietet eine Ressourcenhierarchie, die eine Inhaberstruktur für Ressourcen und Verbindungspunkte für Organisationsrichtlinien und Zugriffssteuerungen bietet. Die Ressourcenhierarchie besteht aus Ordnern, Projekten und Ressourcen und definiert die Struktur und Nutzung von Google Cloud-Diensten innerhalb einer Organisation.
Ressourcen, die niedriger in der Hierarchie sind, übernehmen Richtlinien wie IAM-Zulassungsrichtlinien und Organisationsrichtlinien. Alle Zugriffsberechtigungen werden standardmäßig abgelehnt, bis Sie Zulassungsrichtlinien direkt auf eine Ressource anwenden oder die Ressource die Zulassungsrichtlinien von einer höheren Ebene in der Ressourcenhierarchie übernimmt.
Das folgende Diagramm zeigt die Ordner und Projekte, die vom Blueprint bereitgestellt werden.
In den folgenden Abschnitten werden die Ordner und Projekte im Diagramm beschrieben.
Ordner
Im Blueprint werden Ordner verwendet, um Projekte nach ihrer Umgebung zu gruppieren. Diese logische Gruppierung wird verwendet, um Konfigurationen wie Zulassungsrichtlinien und Organisationsrichtlinien auf Ordnerebene anzuwenden. Alle Ressourcen im Ordner übernehmen dann die Richtlinien. In der folgenden Tabelle werden die Ordner beschrieben, die Teil des Blueprints sind.
| Ordner | Beschreibung |
|---|---|
bootstrap |
Enthält die Projekte, die zum Bereitstellen von Grundlagenkomponenten verwendet werden. |
common |
Enthält Projekte mit Ressourcen, die für alle Umgebungen freigegeben sind. |
production |
Enthält Projekte mit Produktionsressourcen. |
nonproduction |
Enthält eine Kopie der Produktionsumgebung, mit der Sie Arbeitslasten testen können, bevor Sie sie für die Produktion übernehmen. |
development |
Enthält die Cloud-Ressourcen, die für die Bereitstellung verwendet werden. |
networking |
Enthält die Netzwerkressourcen, die für alle Umgebungen freigegeben sind. |
Projekte
Im Blueprint werden Projekte verwendet, um einzelne Ressourcen basierend auf ihrer Funktionalität und den vorgesehenen Grenzen für die Zugriffssteuerung zu gruppieren. In der folgenden Tabelle werden die Projekte beschrieben, die im Blueprint enthalten sind.
| Ordner | Projekt | Beschreibung |
|---|---|---|
bootstrap |
prj-b-cicd |
Enthält die Bereitstellungspipeline, mit der die Grundlagenkomponenten der Organisation aufgebaut werden Weitere Informationen finden Sie unter Bereitstellungsmethodik. |
prj-b-seed |
Enthält den Terraform-Zustand Ihrer Infrastruktur und das Terraform-Dienstkonto, das zum Ausführen der Pipeline erforderlich ist. Weitere Informationen finden Sie unter Bereitstellungsmethodik. | |
common |
prj-c-secrets |
Enthält Secrets auf Organisationsebene Weitere Informationen finden Sie unter Anmeldedaten von Anwendungen mit Secret Manager speichern. |
prj-c-logging |
Enthält die aggregierten Logquellen für Audit-Logs. Weitere Informationen finden Sie unter Zentrales Logging für Sicherheit und Audit. | |
prj-c-scc |
Enthält Ressourcen zum Konfigurieren von Security Command Center-Benachrichtigungen und anderen benutzerdefinierten Sicherheitsmonitorings. Weitere Informationen finden Sie unter Bedrohungsmonitoring mit Security Command Center. | |
prj-c-billing-export |
Enthält ein BigQuery-Dataset mit den Abrechnungsexporten der Organisation Weitere Informationen finden Sie unter Kosten auf interne Kostenstellen verteilen. | |
prj-c-infra-pipeline |
Enthält eine Infrastruktur-Pipeline zum Bereitstellen von Ressourcen wie VMs und Datenbanken, die von Arbeitslasten verwendet werden. Weitere Informationen finden Sie unter Pipelineebenen. | |
prj-c-kms |
Enthält Verschlüsselungsschlüssel auf Organisationsebene. Weitere Informationen finden Sie unter Verschlüsselungsschlüssel verwalten. | |
networking |
prj-net-{env}-shared-base |
Enthält das Hostprojekt für ein freigegebene VPC-Netzwerk für Arbeitslasten, für die keine VPC Service Controls erforderlich sind. Weitere Informationen finden Sie unter Netzwerktopologie. |
prj-net-{env}-shared-restricted |
Enthält das Hostprojekt für ein freigegebene VPC-Netzwerk für Arbeitslasten, für die VPC Service Controls erforderlich sind. Weitere Informationen finden Sie unter Netzwerktopologie. | |
prj-net-interconnect |
Enthält die Cloud Interconnect-Verbindungen, die die Konnektivität zwischen Ihrer lokalen Umgebung und Google Cloud bieten Weitere Informationen finden Sie unter Hybridkonnektivität. | |
prj-net-dns-hub |
Enthält Ressourcen für einen zentralen Kommunikationspunkt zwischen Ihrem lokalen DNS-System und Cloud DNS. Weitere Informationen finden Sie unter Zentrale DNS-Einrichtung. | |
prj-{env}-secrets |
Enthält Secrets auf Ordnerebene Weitere Informationen finden Sie unter Anmeldedaten von Anwendungen mit Secret Manager speichern und prüfen. | |
prj-{env}-kms |
Enthält Verschlüsselungsschlüssel auf Ordnerebene. Weitere Informationen finden Sie unter Verschlüsselungsschlüssel verwalten. | |
| Anwendungsprojekte | Enthält verschiedene Projekte, in denen Sie Ressourcen für Anwendungen erstellen. Weitere Informationen finden Sie unter Projektbereitstellungsmuster und Pipelineebenen. |
Governance für die Inhaberschaft von Ressourcen
Wir empfehlen, Labels einheitlich auf Ihre Projekte anzuwenden, um die Verwaltung und Kostenzuordnung zu erleichtern. In der folgenden Tabelle werden die Projektlabels beschrieben, die jedem Projekt im Blueprint für die Governance hinzugefügt werden.
| Label | Beschreibung |
|---|---|
application |
Der visuell lesbare Name der Anwendung oder Arbeitslast, die mit dem Projekt verknüpft ist. |
businesscode |
Ein kurzer Code, der beschreibt, welcher Geschäftseinheit das Projekt gehört. Der Code shared wird für allgemeine Projekte verwendet, die nicht explizit mit einer Geschäftseinheit verknüpft sind. |
billingcode |
Ein Code, der zur Bereitstellung von Rückbuchungsinformationen verwendet wird. |
primarycontact |
Der Nutzername des primären Kontakts, der für das Projekt verantwortlich ist. Da Projektlabels keine Sonderzeichen wie @ enthalten dürfen, wird der Nutzername ohne das @example.com-Suffix auf den Nutzernamen gesetzt. |
secondarycontact |
Der Nutzername des sekundären Kontakts, der für das Projekt verantwortlich ist. Da Projektlabels keine Sonderzeichen wie @ enthalten dürfen, legen Sie nur den Nutzernamen ohne das @example.com-Suffix fest. |
environment |
Ein Wert, der den Umgebungstyp identifiziert, z. B.
bootstrap, common, production,
non-production,development oder network. |
envcode |
Ein Wert, der den Umgebungstyp identifiziert, verkürzt zu b, c, p, n, d oder net. |
vpc |
Die ID des VPC-Netzwerk, das für dieses Projekt voraussichtlich verwendet wird. |
Google sendet gelegentlich wichtige Benachrichtigungen, z. B. zu Kontosperrungen oder Aktualisierungen der Produktbedingungen. Der Blueprint verwendet Wichtige Kontakte, um diese Benachrichtigungen an die Gruppen zu senden, die Sie während der Bereitstellung konfigurieren. „Wichtige Kontakte“ wird am Organisationsknoten konfiguriert und von allen Projekten in der Organisation übernommen. Wir empfehlen Ihnen, diese Gruppen zu prüfen und dafür zu sorgen, dass E-Mails zuverlässig überwacht werden.
„Wichtige Kontakte“ wird für einen anderen Zweck verwendet als die Felder primarycontact und secondarycontact, die in Projektlabels konfiguriert sind. Die Kontakte in Projektlabels sind für die interne Verwaltung gedacht. Wenn Sie beispielsweise nicht konforme Ressourcen in einem Arbeitslastprojekt identifizieren und die Inhaber kontaktieren müssen, können Sie das Feld primarycontact verwenden, um die Person oder das Team zu ermitteln, das für diese Arbeitslast verantwortlich ist.
Nächste Schritte
- Netzwerk (nächstes Dokument in dieser Reihe)