Der Stammknoten zum Verwalten 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 durch den Blueprint bereitgestellt werden.
In den folgenden Abschnitten werden die Ordner und Projekte im Diagramm beschrieben.
Ordner
Der Blueprint verwendet Ordner, um Projekte anhand 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 von allen Umgebungen gemeinsam genutzt werden. |
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 von allen Umgebungen gemeinsam genutzt werden. |
Projekte
Der Blueprint verwendet Projekte, um einzelne Ressourcen basierend auf ihrer Funktionalität und ihren beabsichtigten Grenzen für die Zugriffssteuerung zu gruppieren. In der folgenden Tabelle werden die im Blueprint enthaltenen Projekte beschrieben.
Ordner | Projekt | Beschreibung |
---|---|---|
bootstrap |
prj-b-cicd |
Enthält die Bereitstellungspipeline, mit der die Grundlagenkomponenten der Organisation aufgebaut werden Weitere Informationen finden Sie unter Bereitstellungsmethode. |
prj-b-seed |
Enthält den Terraform-Status Ihrer Infrastruktur und das Terraform-Dienstkonto, das zum Ausführen der Pipeline erforderlich ist. Weitere Informationen finden Sie unter Bereitstellungsmethode. | |
common |
prj-c-secrets |
Enthält Secrets auf Organisationsebene Weitere Informationen finden Sie unter Anmeldedaten für Anwendungen mit Secret Manager speichern. |
prj-c-logging |
Enthält die aggregierten Logquellen für Audit-Logs. Weitere Informationen finden Sie unter Zentralisiertes 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-logs |
Enthält ein BigQuery-Dataset mit den Abrechnungsexporten der Organisation Weitere Informationen finden Sie unter Kosten zwischen internen Kostenstellen zuweisen. | |
prj-c-infra-pipeline |
Enthält eine Infrastrukturpipeline zum Bereitstellen von Ressourcen wie VMs und Datenbanken, die von Arbeitslasten verwendet werden sollen. 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 freigegebenes VPC-Netzwerk für Arbeitslasten, die keine VPC Service Controls erfordern. Weitere Informationen finden Sie unter Netzwerktopologie. |
prj-net-{env}-shared-restricted |
Enthält das Hostprojekt für ein freigegebenes VPC-Netzwerk für Arbeitslasten, die VPC Service Controls erfordern. 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. | |
Umgebungsordner (production,
non-production und development ) |
prj-{env}-monitoring |
Enthält ein den Umfang festlegendes Projekt, um Messwerte aus Projekten in dieser Umgebung zu aggregieren. Weitere Informationen finden Sie unter Benachrichtigungen zu logbasierten Messwerten und Leistungsmesswerten. |
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 Ressourceninhaberschaft
Wir empfehlen, Labels auf Ihre Projekte konsistent anzuwenden, um die Governance und die Kostenzuordnung zu unterstützen. In der folgenden Tabelle werden die Projektlabels beschrieben, die jedem Projekt für die Governance im Blueprint hinzugefügt werden.
Label | Beschreibung |
---|---|
application |
Der menschenlesbare 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, gekürzt auf b , c , p , n , d oder net . |
vpc |
Die ID des VPC-Netzwerks, das von diesem Projekt verwendet werden soll. |
Google sendet gelegentlich wichtige Benachrichtigungen wie Kontosperrungen oder Aktualisierungen von Produktbedingungen. Der Blueprint verwendet wichtige Kontakte, um diese Benachrichtigungen an die Gruppen zu senden, die Sie während der Bereitstellung konfigurieren. Wichtige Kontakte werden auf dem Organisationsknoten konfiguriert und von allen Projekten in der Organisation übernommen. Wir empfehlen Ihnen, diese Gruppen zu prüfen und sicherzustellen, dass E-Mails zuverlässig überwacht werden.
Wichtige Kontakte werden 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 Governance vorgesehen. 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)