Best Practices für die Richtlinienverwaltung mit Anthos Config Management und GitLab

In diesem Dokument wird erläutert, wie Sie mit Anthos Config Management und GitLab mehrere Kubernetes-Cluster in einer Produktionsumgebung verwalten. Die Sicherung des Anthos Config Management-Repositorys ist ein wichtiger Deployment-Schritt, bei dem Sie das vorliegende Dokument unterstützen kann. Dieses Dokument ist hilfreich, wenn Sie gerade im Begriff sind, Anthos Config Management in einer Produktionsumgebung bereitzustellen. Im Dokument wird davon ausgegangen, dass Sie mit Kubernetes, Git und GitLab vertraut sind.

Wenn Sie eine Plattform betreiben, auf der Anwendungen für Ihre Organisation gehostet werden, ist es wichtig, dass Sie Richtlinien zum Schutz der Plattform implementiert haben. Richtlinien sind Regeln, die sowohl die Plattform selbst als auch die Anwendungen und Daten auf der Plattform schützen sollen. Die Plattform erzwingt diese Richtlinien anhand von Konfigurationen, die die Richtlinien beschreiben. Die Erzwingung von Richtlinien trägt zu mehr Sicherheit und Stabilität der Plattform bei.

Mit Anthos Config Management können Sie Richtlinien in großem Maßstab für Plattformen verwalten, die auf Google Kubernetes Engine (GKE), Anthos-Clustern oder anderen Kubernetes-Distributionen basieren. Mit Anthos Config Management können Sie Kubernetes-Objekte in mehreren Clustern gleichzeitig erstellen und verwalten. Obwohl sich jedes Kubernetes-Objekt mit Anthos Config Management verwalten lässt, ist das Tool besonders nützlich, um Richtlinien wie die folgenden zu erzwingen:

  • PodSecurityPolicies: verhindern, dass Pods den Linux-Root-Nutzer verwenden.
  • NetworkPolicies: steuern den Netzwerktraffic innerhalb der Cluster.
  • ClusterRoles und ClusterRoleBindings: steuern Berechtigungen innerhalb eines Clusters.

Wie im folgenden Diagramm dargestellt, ist Anthos Config Management ein GitOps-ähnliches Tool. Es verwendet ein Git-Repository als Speichermechanismus und "Source of Truth".

Grafik: Architektur der Kubernetes-Konfiguration in Git.

Mit Anthos Config Management können Sie durch Interaktion mit diesem Git-Repository Kubernetes-Objekte bereitstellen und verwalten. Wenn Sie Schreibzugriff auf den Haupt-Branch des Anthos Config Management Git-Repositorys erhalten, müssen Sie Administrator der von Anthos Config Management verwalteten Cluster sein. Da das Anthos Config Management-Repository Informationen enthält, die potenziellen Angreifern in die Hand spielen, ist die Sicherung dieses Repositorys von großer Wichtigkeit.

In diesem Dokument wird GitLab Source Code Management (SCM) als Hostingdienst für das Git-Repository verwendet. Außerdem werden die Best Practices für die gemeinsame Verwendung von Anthos Config Management und GitLab zur Verwaltung mehrerer Kubernetes-Cluster beschrieben.

Anthos Config Management und GitLab-Architektur

Das folgende Diagramm zeigt die Deployment-Architektur von Anthos Config Management mit GitLab. In dieser Architektur werden drei Kubernetes-Cluster verwaltet: einer in GKE, einer in Anthos-Clustern auf VMware und einer in einem anderen Cloud-Anbieter.

Grafik: Deployment-Architektur von Anthos Config Management mit GitLab.

Das obige Diagramm veranschaulicht die folgenden Schritte in der Pipeline:

  1. Ein Nutzer sendet eine Änderung, die Zusammenführungsanfrage (Merge Request, MR) genannt wird, um eine Konfigurationsänderung an einem oder allen dieser Cluster vorzunehmen. Diese Anfrage muss in GitLab geprüft werden.
  2. Der MR löst eine automatisierte Pipeline in GitLab CI/CD aus, um die Konfiguration zu testen und zu prüfen. GitLab CI/CD ist das in GitLab eingebundene System für Continuous Integration und Continuous Delivery.
  3. Der MR wird von einem Administrator entweder genehmigt oder abgelehnt. Nach der Genehmigung wird die Änderung im Git-Repository zusammengeführt.
  4. Nach der Genehmigung lesen die in jedem Cluster ausgeführten Anthos Config Management-Agents diese Änderung aus GitLab ein und wenden sie auf ihren Cluster an.

Best Practices für GitLab-Hosting im Kontext von Anthos Config Management

Dieser Abschnitt enthält Best Practices, an denen Sie sich bei Verwendung von GitLab SCM zum Hosten und Verwalten von Anthos Config Management-Repositories orientieren können. Die allgemeinen Best Practices für das Hosting von GitLab, beispielsweise für das Einrichten einer Hochverfügbarkeitsarchitektur und regelmäßiger Datensicherungen, haben ebenfalls Gültigkeit, würden jedoch den Rahmen dieses Dokuments sprengen.

Administratorzugriff beschränken

Jede Person mit Root-Zugriff auf die virtuelle Maschine (oder den Kubernetes-Cluster), die (bzw. der) GitLab hostet, kann GitLab-Sicherheitsfeatures umgehen und sollte daher als Administrator für Anthos Config Management angesehen werden. Diese Annahme gilt auch für jede Person, die Administrator in GitLab ist oder Schreibzugriff auf die GitLab-Datenbank hat. Wenn Sie Nutzern GitLab-Administratorberechtigungen, Root-Zugriff auf die für das Hosting von GitLab verwendete virtuelle Maschine (oder den verwendeten Kubernetes-Cluster) oder Zugriff auf die GitLab-Datenbank gewähren, können diese Nutzer auch Änderungen in Anthos Config Management vornehmen. Weitere Informationen finden Sie in der Dokumentation zu Berechtigungen von GitLab.

Wenn Sie Compute Engine verwenden, legen Sie mit Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) und dem Dienst OS Login fest, wer Zugriff auf die Instanz hat. Insbesondere wird Nutzern über die Rolle Compute OS-Administrator-Login Root-Zugriff auf die Instanz gewährt.

Wenn Sie GKE verwenden, legen Sie mit IAM und RBAC fest, wer Zugriff auf den Cluster hat.

Regelmäßig Updates einspielen

GitLab veröffentlicht einen Release pro Monat und mehrere Patchreleases zwischen den einzelnen Releases. Wie jede andere Software bietet GitLab Sicherheitspatches in einigen dieser Releases. Aus diesem Grund sollten Sie Ihre GitLab-Instanz so aktuell wie möglich halten. Weitere Informationen finden Sie im Abschnitt zum Aktualisieren von GitLab.

An die Google Cloud-spezifischen Best Practices für das Hosting von GitLab in Google Cloud halten

Wenn Sie GitLab in Google Cloud hosten, sollten Sie dem Tool ein eigenes Cloud-Projekt zuweisen. Platzieren Sie dieses Cloud-Projekt direkt unter dem Knoten Organisation und nicht in einem Ordner. Diese Empfehlungen können die Wahrscheinlichkeit der folgenden IAM-Fehlkonfigurationen verringern:

  • Wenn GitLab ein Cloud-Projekt mit anderen Anwendungen teilt, könnten Sie versehentlich Administratorzugriff auf GitLab gewähren, wenn Sie Nutzern Zugriff auf die anderen Anwendungen erteilen.
  • Wenn Sie dieses Cloud-Projekt in einem Ordner ablegen, könnten Sie versehentlich Zugriff auf das Cloud-Projekt gewähren, wenn Sie Nutzern Zugriff auf den Ordner erteilen.

Wenn Sie GitLab in Google Cloud bereitstellen, empfehlen wir Ihnen außerdem, die folgenden verwalteten Dienste zu nutzen:

  • Verwenden Sie Cloud SQL for PostgreSQL, um die GitLab-Datenbank zu hosten. Cloud SQL kümmert sich um Hochverfügbarkeit und Datensicherungen.
  • Verwenden Sie Memorystore for Redis als GitLab-Redis-Server. Memorystore kümmert sich um Hochverfügbarkeit.
  • Verwenden Sie Cloud Storage, um Datensicherungen, Build-Artefakte und Nutzeruploads zu speichern.

Authentifizierung und Zugriffssteuerung für GitLab

Für Auditing- oder Debugging-Zwecke ist es wichtig, dass Sie die Personen identifizieren können, die eine Richtlinienänderung vorgenommen haben, und dass die Identitäten auch von Ihren IT-Mitarbeitern zur Verwaltung verschiedener Ressourcen verwendet werden.

Einheitliche Identitäten verwenden

Standardmäßig interagieren Sie mit Anthos Config Management über ein Git-Repository, in dem Sie Ressourcen erstellen, aktualisieren und löschen. Im Git-Repository steuern Sie, welche Nutzer was tun können. Außerdem können Sie dort sämtliche Aktivitäten prüfen. Die Implementierung von Zugriffssteuerung und Auditing ist einfacher, wenn die von Ihren Mitarbeitern verwendeten Identitäten überall gleich sind: in Google Cloud, in GitLab und in Ihren lokalen Systemen. Mit einheitlichen Identitäten lassen sich Berechtigungen und Audit-Logs über verschiedene Systeme hinweg vergleichen.

In GitLab können Sie gruppen-, projekt- und instanzübergreifend Ereignisse prüfen sowie GitLab-Service-Level-Ereignisse in den Systemlogs abfragen. Die Features für GitLab-Audit-Ereignisse gehören zu lizenzpflichtigen Enterprise-Stufen.

Wenn Sie Google nicht als Identitätsanbieter verwenden

Google Cloud lässt sich mit vielen beliebten IdPs wie Active Directory, Azure Active Directory oder Okta verbinden. Sie können GitLab zur Verwendung von Active Directory oder Okta konfigurieren.

Wenn Sie Google als Identitätsanbieter verwenden

Wenn Sie Google als Identitätsanbieter verwenden, können Sie entweder den OmniAuth-Anbieter von Google OAuth 2.0 oder Secure LDAP nutzen. Allerdings müssen Sie Secure LDAP verwenden, wenn Sie Gruppen mit GitLab synchronisieren möchten, wie im nächsten Abschnitt empfohlen. Secure LDAP ist mit der Cloud Identity Premiumversion und Google Workspace Enterprise verfügbar. Weitere Informationen finden Sie unter Secure LDAP.

Gruppen mit GitLab synchronisieren

Unabhängig von der Technologie, mit der Ihre Nutzer identifiziert werden, ist es sinnvoll, Nutzer zum Konfigurieren ihres Zugriffs zu gruppieren. Mithilfe von Gruppen können Sie diese Nutzer beim Erteilen von Berechtigungen auf übergeordneter Ebene zusammenfassen und damit beispielsweise Ihrer Operations-Gruppe Administratorzugriff auf die Produktionsumgebungen erteilen und nicht einzelnen, benannten Personen. Wenn die Prozesse Ihrer Personalabteilung gut in Ihre IT-Systeme eingebunden sind, wird außerdem die Gruppenmitgliedschaft automatisch verwaltet, wenn ein Mitarbeiter eingestellt wird, das Unternehmen verlässt oder die Rolle wechselt. Falls Sie Gruppen verwenden, bedeutet dies, dass Sie normalerweise die Einstellungen der Zugriffssteuerung nicht aktualisieren müssen.

Anthos Config Management ist ein sensibles System. Daher ist es wichtig, dass Sie den Zugriff auf Anthos Config Management mithilfe von Nutzergruppen steuern. In GitLab können Sie ein Projekt für eine Gruppe von Nutzern freigeben und festlegen, auf welcher Zugriffsebene Mitglieder dieser Gruppe angesiedelt werden.

Zwei-Faktor-Authentifizierung erzwingen

Sie sollten die Zwei-Faktor-Authentifizierung (2FA) verwenden, die auch Bestätigung in zwei Schritten genannt wird, um die Sicherheit Ihrer Organisation zu verbessern. Gestohlene Anmeldedaten und Phishing-Angriffe sind zwei gängige Angriffsvektoren, vor denen Sie 2FA schützen kann. Aufgrund des sensiblen Inhalts des Git-Repositorys von Anthos Config Management sollten die Konten der Nutzer, die mit Anthos Config Management interagieren, so gut wie möglich geschützt werden. Dies bedeutet, dass 2FA für diese Nutzer aktiviert werden muss.

Wenn Sie die Einmalanmeldung (SSO) für GitLab konfigurieren, sollten Sie 2FA bei Ihrem SSO-Anbieter erzwingen. Bei Verwendung von Google als SSO-Anbieter können Sie 2FA aktivieren.

Wenn Sie SSO nicht für GitLab konfiguriert haben, können Sie 2FA in GitLab direkt erzwingen.

Anthos Config Management-Agents über Deployment-Schlüssel oder -Tokens mit GitLab verbinden

Wie im Dokument Anthos Config Management installieren beschrieben, können Sie für die Verbindung von Anthos Config Management-Agents mit dem Repository die üblichen Methoden für Git verwenden: HTTP(S) oder SSH. Wenn Sie über HTTP(S) auf Repositories zugreifen, die auf GitLab gehostet werden, sollten Sie kein Nutzerkonto verwenden. Dies kann Probleme mit der Lizenzierung oder Nutzern verursachen, die ihre eigenen Konten zum Konfigurieren von Anthos Config Management verwenden. Deployment-Schlüssel und Deployment-Token aus GitLab sind eine bessere Alternative. Ein Deployment-Schlüssel ist ein SSH-Schlüssel, der nicht mit einem bestimmten Nutzer verknüpft ist, aber von automatisierten Systemen zum Ausführen von Git-Vorgängen verwendet werden kann. Dies ist die Art von sicherem Zugriff, die für Anthos Config Management erforderlich ist. Ein Deployment-Token wird genauso verwendet wie ein Deployment-Schlüssel, allerdings können Sie sich damit über HTTP(S) anstelle von SSH authentifizieren.

Mit eindeutigen Deployment-Schlüsseln und -Tokens können Sie den Zugriff der Anthos Config Management-Agents auf das Git-Repository pro Cluster steuern und widerrufen. Vermeiden Sie <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="opBB/mAJqPUFZffWWDKJfMvOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwlKMkBQSfMxp5fl+Mc9AjFx4o6T+DhcfK0B6wN+3j0FU=" track-metadata-position="body" track-name="externalLink" track-type="solution">globale Deployment-Schlüssel for Anthos Config Management und <atarget="external" class="external" l10n-attrs-original-order="href,target,track-type,track-name,track-metadata-position,class" l10n-encrypted-href="EVE38A1n4riTbiBLnLIE18vOmiJSf/VmdDg1Ype1pCNaVc0Q87JXiv/tqn8GXWhwnjars0LTR/vDhAa2T615gjvG0B0C/P1DzOlB98jatvw=" track-metadata-position="body" track-name="externalLink" track-type="solution">Gruppen-Deployment-Tokens. Sie können sie für andere Zwecke als Anthos Config Management nutzen, was zu unbeabsichtigten Nebenwirkungen führt, wenn sich ihre Konfiguration ändert.</atarget="external"></atarget="external">

Verwalten, wer Zusammenführungsanfragen genehmigen kann

Standardmäßig verwendet GitLab Rollen, um Berechtigungen für GitLab-Projekte zu erteilen. Beispielsweise kann ein Nutzer mit der Entwicklerrolle ("Developer") eine Zusammenführungsanfrage öffnen und ein Nutzer mit der Administratorrolle ("Maintainer") die Anfrage genehmigen. Auch wenn dieses Berechtigungssystem für Anthos Config Management anfangs vielleicht gut funktioniert, kann es zu Problemen kommen, wenn Ihre Kubernetes- und Anthos Config Management-Strukturen wachsen. Die Menge der zu verarbeitenden und zu genehmigenden Zusammenführungsanfragen könnten die Administratoren des Anthos Config Management-Repositorys überlasten.

Die Premiumfeatures von GitLab helfen Ihnen bei der Bewältigung dieses Problems:

  • Sie können Code-Inhaber verwenden, um Genehmigungsberechtigungen auf Basis von Dateien oder Verzeichnissen zu erteilen. Dieses Feature ist hilfreich, weil Anthos Config Management eine Verzeichnisstruktur zum Beschreiben von Clustern und Namespaces verwendet. Mithilfe von Code-Inhabern können Sie beispielsweise Genehmigungsberechtigungen für einen bestimmten Namespace über alle Cluster hinweg erteilen.
  • Mit den Genehmigungen für Zusammenführungsanfragen können Sie festlegen, dass verschiedene Personen aus verschiedenen Teams eine Anfrage genehmigen müssen, bevor sie zusammengeführt wird. Zur Genehmigung einer Zusammenführungsanfrage könnten beispielsweise zwei Genehmiger erforderlich sein: einer aus dem Operations-Team und einer aus dem Sicherheitsteam.

Das folgende Diagramm zeigt die technische Abteilung einer Organisation und ein Beispiel dafür, wie das Erteilen von Genehmigungen in einer Produktionsumgebung aussehen kann.

Grafik: Beispielarchitektur der Hierarchie in einer Organisation.

Das obige Diagramm enthält einen Chief Technical Officer (CTO), dem mehrere Teams unterstellt sind: ein Sicherheitsteam, ein Plattformteam und mehrere Anwendungsteams.

Das Anthos Config Management-Git-Repository dieser Organisation hat die folgende Struktur (es werden nur Verzeichnisse dargestellt, keine Dateien):

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

Weitere Informationen zu den einzelnen Verzeichnissen finden Sie unter Anthos Config Management-Repository verwenden.

Mit dieser Struktur kann die Organisation mithilfe der zuvor genannten GitLab-Features den folgenden Prozess implementieren:

  • Jede Änderung am Stammverzeichnis des Repositorys oder am Verzeichnis system muss vom CTO genehmigt werden.
  • Jede Änderung am Verzeichnis clusterregistry muss von einem Mitglied des Plattformteams genehmigt werden.
  • Jede Änderung am Verzeichnis cluster muss sowohl von einem Mitglied des Plattformteams als auch von einem Mitglied des Sicherheitsteams genehmigt werden.
  • Jede Änderung am Verzeichnis namespaces muss von einem Mitglied des Plattformteams genehmigt werden.
  • Jede Änderung an den Unterverzeichnissen im Verzeichnis namespaces muss von den folgenden Teams genehmigt werden:

    • Das Unterverzeichnis cicd stellt einen Namespace für CI/CD-Tools (Continuous Integration/Continuous Delivery) dar. Jede Änderung muss von einem Mitglied des Plattformteams genehmigt werden.
    • Das Unterverzeichnis audit stellt einen Namespace für Auditingtools dar. Jede Änderung muss von einem Mitglied des Sicherheitsteams genehmigt werden.
    • Das Unterverzeichnis applications enthält alle Ressourcen, die für die einzelnen Anwendungs-Namespaces erstellt wurden. Jede Änderung muss sowohl von einem Mitglied des Plattformteams als auch von einem Mitglied des Sicherheitsteams genehmigt werden.
    • Die Unterverzeichnisse team-a und team-b stellen die Namespaces für Team A und Team B dar. Jede Änderung muss vom Leiter des jeweiligen Teams genehmigt werden.

Die Implementierung dieses Prozesses ist einfacher, wenn die Gruppen Ihres Identitätsanbieters mit GitLab synchronisiert werden. Sie können festlegen, dass für eine Zusammenführungsanfrage verschiedene Genehmigungen von verschiedenen Gruppen erforderlich sind. Weitere Informationen finden Sie unter Gruppen mit GitLab synchronisieren und Genehmigungen bearbeiten.

Freigegebene Runner deaktivieren

Mit GitLab CI können Sie Ihre Anthos Config Management-Richtlinien automatisch testen, bevor Sie sie bereitstellen. GitLab CI verwendet Runner, um die gewünschten Jobs auszuführen. Diese Runner können entweder für die gesamte GitLab-Instanz freigegeben oder für bestimmte GitLab-Gruppen oder GitLab-Projekte abgestellt werden. Im ersteren Fall werden die Runner vom selben Team verwaltet, das auch die GitLab-Instanz selbst verwaltet.

Aufgrund des sensiblen Inhalts des Anthos Config Management-Repositorys sollten Sie nach Möglichkeit keine freigegebenen Runner zum Testen von Anthos Config Management-Code verwenden. Verwenden Sie stattdessen Runner, die für die Anthos Config Management-Projekte abgestellt sind und von den Personen verwaltet werden, die Zusammenführungsanfragen genehmigen können.

Zusammenfassung der Empfehlungen

In diesem Abschnitt werden die Empfehlungen aus den vorherigen Abschnitten zusammengefasst. Wenn Sie das Git-Repository von Anthos Config Management mit GitLab hosten, empfehlen wir Folgendes:

  • Steuern Sie, wer Administratorzugriff auf GitLab hat, da diese Personen auch Administratorzugriff auf Anthos Config Management erhalten.
  • Aktualisieren Sie GitLab regelmäßig und bei jeder Veröffentlichung eines Sicherheitspatches.
  • Weisen Sie GitLab ein eigenes Cloud-Projekt unter Ihrem Organisationsknoten zu, wenn Sie GitLab in Google Cloud hosten.
  • Konfigurieren Sie alle Systeme, einschließlich GitLab, zur Verwendung desselben Identitätsanbieters.
  • Verwenden Sie zum Synchronisieren Ihrer vorhandenen Nutzergruppen mit GitLab möglichst das Feature LDAP Group Sync, das ein lizenziertes Feature von GitLab Enterprise ist.
  • Erzwingen Sie 2FA für Nutzer, die mit Anthos Config Management interagieren, um Probleme mit gestohlenen und per Phishing abgeschöpften Anmeldedaten zu vermeiden.
  • Führen Sie beim Konfigurieren von Anthos Config Management-Agents folgende Schritte aus:
    • Konfigurieren Sie Anthos Config Management-Agents so, dass SSH und Deployment-Schlüssel oder HTTPS und Deployment-Tokens für die Verbindung mit GitLab verwendet werden.
    • Verwenden Sie nach Möglichkeit kein unverschlüsseltes HTTP.
    • Erstellen Sie einen eindeutigen Deployment-Schlüssel oder ein eindeutiges Deployment-Token pro Kubernetes-Cluster in Ihrem Anthos Config Management-Repository.
    • Konfigurieren Sie die Deployment-Schlüssel und -Tokens direkt im Anthos Config Management-Repository und verwenden Sie nach Möglichkeit weder globale Deployment-Schlüssel noch Gruppen-Deployment-Tokens für Anthos Config Management.
  • Achten Sie auf Verzögerungen bei der Genehmigung von Zusammenführungsanfragen im Anthos Config Management-Repository. Wenn Sie feststellen, dass sie unverhältnismäßig ansteigen, verwenden Sie Code-Inhaber oder die erweiterten Genehmigungen für Zusammenführungsanfragen, um mehr Personen in Ihrer Organisation Genehmigungsberechtigungen zu erteilen.
  • Deaktivieren Sie freigegebene Runner für Ihr Anthos Config Management-Projekt und verwenden Sie nur Runner, die für dieses Projekt abgestellt sind.

Nächste Schritte