So strukturieren Sie Ihr Unternehmen auf der Google Cloud Platform

• Sorgen Sie für organisatorische Ausrichtung
• Wählen Sie Ihren eigenen Weg
• Identitäten über Benutzergruppen und Rollen aufsetzen
• Netzwerke mit Shared VPCs zentralisieren
• Alle Ressourcen sauber durchplanen
• Ressourcen für besseres Reporting taggen
• Budget Alerts einrichten
• Source-Code-Repositories für IaC organisieren
• Security- und Monitoring-Alerts einrichten
• Bastion (Jump) Host nutzen
• Daten schützen
• Cloud Security Command Center einsetzen
• Disaster-Recovery- und Business-Continuity-Pläne dokumentieren und testen
• Mit erfahrenen Experten zusammenarbeiten

Auch wenn dieser Artikel auf Funktionen der Google Cloud Platform (GCP) fokussiert ist, möchte ich es nicht versäumen, AWS-CEO Andy Jassy für seine prägnante Zusammenfassung der vier Schlüsselfaktoren einer erfolgreichen Cloud-Transformation – und ich wage zu behaupten jeder erfolgreichen Initiative – Anerkennung zu zollen:

1. Überzeugung und gemeinsame Ausrichtung des Senior-Leadership-Teams
2. Ambitionierte Ziele von oben
3. Schulen Sie Ihre Builder
4. Lassen Sie sich nicht von [Analyse-]Lähmung stoppen, bevor Sie überhaupt loslegen

Mein persönliches Mantra beim Ausprobieren neuer Dinge lautet: "first make it work, then make it right, then make it fast."

Google bietet hervorragende Online-Ressourcen zu Enterprise Best Practices sowie die folgende Abbildung mit empfohlenen Schritten für Secure Google Cloud Services. Da die Anforderungen jeder Organisation unterschiedlich sind, ist diese Roadmap ein guter Ausgangspunkt, um Ihre konkrete Infrastruktur zu planen oder einen Überblick über das Verfügbare zu bekommen.

Quelle: Google

Beginnen Sie mit einer Least-Privilege-Policy und deaktivieren Sie sofort die Möglichkeit, auf Organisationsebene Projekte anzulegen. Nur DevOps, Billing und OrgAdmins sollten dazu berechtigt sein – idealerweise lediglich ein Service Account in DevOps für Ihre Infrastruktur-Automatisierung (z. B. Terraform). Nehmen Sie wann immer möglich keine Einzelpersonen in Ihr IAM auf.

• Organization Administrators ([email protected])
• Network Administrators ([email protected])
• Security Administrators ([email protected])
• Billing Administrators ([email protected])
• DevOps ([email protected])
• Development ([email protected])
• DataScience ([email protected]) [optional]

Sobald Sie diese Gruppen angelegt haben – optional mit Cloud Identity (Anbindung an Ihr bestehendes AD oder Ihren IdP) oder in Ihrer GSuite-Organisation –, fügen Sie pro Gruppe mindestens eine Person hinzu. Anschließend weisen Sie der jeweiligen Gruppe nur bei Bedarf die nötigen Rollen auf Organisations- oder Folder-Ebene zu.

Quelle: Google

Wenn Sie GitOps konsequent leben, können Entwicklungsteams beliebige workloads* per CI/CD-Pipeline aus der Versionsverwaltung in die jeweiligen Kubernetes-Cluster-Namespaces deployen. Dieser Ansatz erleichtert die Steuerung von Zugriffen und Quotas und damit auch die Cloud-Kostenkontrolle und Budgetplanung.

*ausschließlich freigegebene Binaries aus einem vertrauenswürdigen privaten Image-Repository

In stark regulierten Branchen oder wenn Sie Compliance-Anforderungen wie SOC 2 erfüllen müssen, verlangen Ihre Kontrollen unter Umständen eine strikte Funktionstrennung. Eine gängige Enterprise-Praxis ist es, das Netzwerkmanagement von DevOps und Anwendungsentwicklung zu trennen. GCP macht das mit seinen Shared VPCs und der eleganten Projekthierarchie aus Host- und Service-Projekten besonders einfach.

Planen und designen Sie Ihr Netzwerk so, dass keine Kollisionen entstehen, und löschen Sie alle Default-Netzwerke in Ihren Projekten – Sie werden mir später dafür danken!

Wie gesagt: Das ist ein klar positionierter Ansatz, Ihrer mag abweichen. Meine empfohlene Best Practice: Kapseln Sie Ihre Service-Projekte über ein Host-Projekt und zentralisieren Sie die Netzwerkkonfiguration an einer Stelle, wobei nur Ihre Network-Administrators-Gruppe Zugriff auf diese Projekte erhält.

Bei der IP-Vergabe für Ihre Subnetze sollte – je nach Skalierung und Wachstumsplanung – ein /16-CIDR-Bereich für eine VPC reichlich genügen (65.000 Adressen). Kubernetes hingegen benötigt eine große Anzahl IPs für Services und Pods, da diese ephemeren Containern dynamisch zugewiesen werden. Ich empfehle, einen zusätzlichen ungenutzten Bereich für Secondary IPs zu reservieren, etwa so:

• Subnetz innerhalb des VPC /16-Bereichs: k8s-nodes-prod (10.10.0.0/22)

secondary: k8s-services-prod (10.80.64.0/22)

secondary: k8s-pods-prod (10.80.0.0/18)

Subnetz: bastion-prod (10.10.64.0/29)

• Subnetz innerhalb des VPC /16-Bereichs: k8s-nodes-stage (10.11.0.0/22)

secondary: k8s-services-stage (10.81.64.0/22)

secondary: k8s-pods-stage (10.81.0.0/18)

Subnetz: bastion-stage (10.11.64.0/29)

• Subnetz innerhalb des VPC /16-Bereichs: k8s-nodes-demo (10.12.0.0/22)

secondary: k8s-services-demo (10.82.64.0/22)

secondary: k8s-pods-demo (10.82.0.0/18)

Subnetz: bastion-demo (10.12.64.0/29)

• Subnetz innerhalb des VPC /16-Bereichs: k8s-nodes-qa (10.13.0.0/22)

secondary: k8s-services-qa (10.83.64.0/22)

secondary: k8s-pods-qa (10.83.0.0/18)

Subnetz: bastion-qa (10.13.64.0/29)

• Subnetz innerhalb des VPC /16-Bereichs: k8s-nodes-dev (10.14.0.0/22)

secondary: k8s-services-dev (10.84.64.0/22)

secondary: k8s-pods-dev (10.84.0.0/18)

Subnetz: bastion-dev (10.14.64.0/29)

So bleibt innerhalb Ihrer VPC ausreichend Platz für weitere Subnetze, etwa für Datenbankserver oder andere Ressourcen.

Die Google Cloud Platform organisiert Ressourcen über Organisation, Folder und Projekt. Das erleichtert die Verwaltung von Nutzern und Gruppen erheblich – ohne den Multi-Account-Wahnsinn anderer Plattformen. Viele Unternehmen, die früh in die Cloud gegangen sind, kämpfen heute mit Eigenentwicklungen, um diesen Wildwuchs an Accounts und Berechtigungen zu beherrschen – ein Albtraum für InfoSec und Compliance. GCP hat das von Anfang an besser gelöst.

├── DevOps
│   └── project-devops
│       ├── bucket-terraform-state
│       ├── cluster-devops
│       │   ├── namespace-cicd
│       │   └── namespace-vault
│       ├── sink-application-logs
│       └── sink-audit-logs
├── RnD
│   ├── Non-Production
│   │   └── project-shared-network-nonprod
│   │       ├── sink-application-logs
│   │       ├── sink-audit-logs
│   │       ├── vpc-demo-10-12-0-0
│   │       │   └── project-demo
│   │       │       ├── cluster-demo
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       ├── vpc-dev-10-14-0-0
│   │       │   └── project-development
│   │       │       ├── cluster-development
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       └── vpc-qa-10-13-0-0
│   │           └── project-development
│   │               └── cluster-qa
│   │                   ├── namespace-team1
│   │                   ├── namespace-team2
│   │                   └── namespace-vault
│   ├── Production
│   │   └── project-shared-network-prod
│   │       ├── sink-application-logs
│   │       ├── sink-audit-logs
│   │       ├── vpc-prod-10-10-0-0
│   │       │   └── project-production
│   │       │       ├── cluster-production
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       └── vpc-stage-10-11-0-0
│   │           └── project-stage
│   │               ├── cluster-stage
│   │               │   ├── namespace-team1
│   │               │   ├── namespace-team2
│   │               │   └── namespace-vault
│   │               ├── sink-application-logs
│   │               └── sink-audit-logs
│   └── project-monitoring
│       ├── bucket-development-logs
│       ├── bucket-production-logs
│       ├── workspace-development
│       └── workspace-production
└── Security
    └── project-security
        └── bucket-audit-logs

Eine der häufigsten Herausforderungen und größten Quellen für Verwirrung in Public Clouds sind Billing, Reporting und Kostenkontrolle. Eine Möglichkeit, die Kosten im Griff zu behalten, ist der Aufbau Ihrer Infrastruktur mit teambasierten Namespaces, wie oben skizziert. Das beschleunigt das Onboarding und die Produktivität von Entwicklern und vermeidet steile Lernkurven oder einen zu kleinen Talentpool. Eine weitere Best Practice ist es, Ressourcen zu taggen bzw. zu labeln, damit Sie später Alerts, Budgets und Reports darauf aufbauen können.

Ein Kollege von mir hat einen Artikel zum Thema "Auto Tagging Google Cloud Resources" mit unserem Open-Source-Tool IRIS verfasst. Es gibt viele weitere lesenswerte Beiträge dazu – planen Sie Ihre Tags also frühzeitig, um sich später Kopfschmerzen zu ersparen.

Empfohlene Tags pro Ressource:

• Owner – wer aktuell verantwortlich ist (kann sich teamintern verschoben haben)
• Creator – wer die Ressource ursprünglich angelegt hat (für spätere Rückfragen)
• Project – z. B. my-company-production für eine bessere Gruppierung
• Working Hours – bis zu 60 % sparen durch automatisches Scheduling von Dev-Ressourcen mit Zorya

Viele CFOs scheuen die Cloud, weil ihnen die Transparenz fehlt und sie endlose Kosten durch Fehlkonfigurationen befürchten. Mit Budget Alerts können Sie die täglichen Ausgaben verfolgen und schnell reagieren, um Ihre Cloud-Ausgaben in Einklang mit den Unternehmenseinnahmen zu halten. Es empfiehlt sich, Kosteninformationen an Ihre Teams weiterzugeben und die Team-Leads in die Pflicht zu nehmen, das Budget regelmäßig zu prüfen und zu überwachen.

Sobald Ihr Plan für die Ressourcen-Hierarchie steht, stehen Sie vor einem Henne-Ei-Problem: Provisionieren Sie alles mit Terraform – und wenn ja, wie erhält Terraform die Berechtigungen, alles aufzubauen? Die Empfehlung: Ihr Org Admin legt den DevOps-Folder samt Projekt an, und Ihr DevOps-Team erstellt einen Terraform Service Account mit den nötigen Rechten, um Projekte anzulegen, zu löschen usw. Beginnen Sie mit dem absoluten Minimum und ergänzen Sie Rollen erst dann, wenn tatsächlich Fehler auftreten.

Ein Kollege hat einen lesenswerten Artikel zu "Refactoring Terraform The Right Way" geschrieben, der sich mit den Empfehlungen des Expertenteams von Gruntwork.io – den Machern von Terragrunt – deckt. Kurz gesagt: Trennen Sie Ressourcen, Services und Live-Umgebungen in drei separate Repositories und steuern Sie Gruppenberechtigungen entsprechend über Ihre Versionsverwaltung.

Monitoring und Alerting sollten ganz oben auf Ihrer Planungsliste stehen – glücklicherweise bringt die Google Cloud Platform viele Funktionen mit, die das einfach machen. Das CIS-Benchmark-Scanning im weiter unten beschriebenen Cloud Security Command Center (CSCC) erkennt fehlendes Monitoring und liefert Schritt-für-Schritt-Anleitungen, wie Sie jedes Projekt korrekt konfigurieren. Mehr Infos zum CSCC weiter unten.

Zur Vereinfachung gibt es hier einen Gist mit den empfohlenen Monitoring-Konfigurationen.

Im obigen Diagramm habe ich die VMs für Bastion Hosts der Übersicht halber weggelassen, doch die Best Practice für sicheren Zugriff ist, sie einzusetzen. Ich empfehle, pro Projekt einen Subnetz-Bereich für eine Bastion-Host-VM zu reservieren, sämtliche externen IPs zu eliminieren und Private Cluster zu konfigurieren. Erstellen Sie eine Managed Instance Group mit einer Instanz, sodass GCP bei Ausfall automatisch eine neue startet. Sie können sich entweder per VPN mit dem Bastion verbinden oder – moderner und sicherer – Cloud Identity Aware Proxy (IAP) nutzen. Zusätzliche Absicherung erreichen Sie, indem Sie die SSH-Keys der Nutzer einschränken.

Quelle: Google

Es gibt zahlreiche Artikel zu Kubernetes Best Practices, doch der Beitrag der Google Engineers zu "Completely Private GKE Clusters With No Internet Connectivity" ist eine gute Referenz und untermauert die oben vorgeschlagene Grundstruktur.

Sie müssen Ihre Infrastruktur so planen und designen, dass sie die Vorgaben Ihres Security-Teams erfüllt – und das umfasst häufig unterschiedliche Verschlüsselungsanforderungen. GCP-Ressourcen sind standardmäßig at rest verschlüsselt; klären Sie aber, welche Schlüsselverwaltung (Google-managed, self-managed, BYOK) für "at rest" und "in transit" erforderlich ist.

Möglicherweise möchten Sie den Datenzugriff innerhalb Ihrer Organisation zudem bis auf Personen- oder Anwendungsebene isolieren. Das erreichen Sie mit VPC Service Controls, wie unten dargestellt.

Wenn Sie – wie im Beispiel der Ressourcen-Hierarchie – Logs oder Daten zur Überwachung versenden, können Sie Ihre Log Sinks so konfigurieren, dass die Cloud Data Loss Prevention (Cloud DLP)-APIs vor dem Speichern fast 100 Arten personenbezogener Daten (PII) entfernen.

Ein echter Geheimtipp in GCP ist das Cloud Security Command Center. Dieses Produkt liefert eine zentrale Übersicht für Asset Management, Threat- und Anomalie-Erkennung, WAF und Vulnerability Scanning. Eines der coolsten Features ist meiner Meinung nach das Scanning – Sie können konfigurieren, welche Projekte gescannt werden, aber nicht, wann gescannt wird (1–2 mal pro Tag). Es zeigt CIS- und NIST-Benchmark-Verstöße jedes Projekts und jeder Ressource auf und liefert Schritt-für-Schritt-Anleitungen zur Behebung.

Hinweis: Das neue Pricing teilt CSCC in zwei Stufen (Free, Premium).

Cloud Security Command Center – Quelle: wideops.com

• Eine hervorragende Ressource und Checkliste sind die CIS Benchmarks for Google Cloud – es gibt spezifische Benchmarks für Kubernetes und andere Systeme, alle kostenfrei.

Zudem gibt es starke Drittanbieter-Tools wie Forseti Security und Palo Alto Networks Prisma Cloud (vormals Twistlock und Redlock) zum Scannen und zur Optimierung von Konfigurationen und Code-Deployments.

Es versteht sich von selbst, dass Sie für sämtliche Daten – ob in Buckets oder Datenbanken – einen automatisierten Backup- und Recovery-Plan brauchen. Üben Sie den Backup- und Restore-Prozess mindestens einmal pro Jahr, besser sogar häufiger.

Für Business Continuity und ein gutes Bauchgefühl ist es dringend zu empfehlen, Ihre Infrastruktur als Code (IaC) mit Terraform zu definieren. Wenn Ihr Team den Zustand der Infrastruktur diszipliniert als Code pflegt, lassen sich Audit-Reports für Compliance-Zwecke und die Wiederherstellung nach katastrophalen Ausfällen mühelos umsetzen.

Ich habe nur an der Oberfläche der wichtigsten Aspekte einer Enterprise-Cloud-Transformation gekratzt – das mag erschlagend wirken, aber das Beste ist, einfach loszulegen. Ich bin sicher voreingenommen, doch das Zweitbeste, was Sie für Ihre Erfolgschancen tun können, ist, sich mit Profis zusammenzutun, die das schon viele Male erfolgreich umgesetzt haben.

DoiT International hat bereits Tausenden Unternehmen auf ihrer Cloud-Reise geholfen – mit Architecture Reviews, Expert Support und maßgeschneiderten Tools für Cloud-Budgetierung und -Reporting, alles ohne Mehrkosten für unsere Kunden (wir sind Cloud Reseller Partner). Unser Ziel ist es, Ihr Team zu befähigen, die eigene Cloud-Infrastruktur erfolgreich zu managen – und wenn nötig, sind wir immer für Sie da.

Mehr Beiträge von Mike gefällig? Schauen Sie in unseren Blog auf Medium oder folgen Sie Mike auf Twitter.