Maximieren Sie die Sicherheit und Effizienz Ihrer GKE-Anwendungen mit Cloud SQL Proxy

Erfahren Sie in unserem neuesten Blogbeitrag, wie Sie mit Cloud SQL Proxy in GKE die Sicherheit und Effizienz Ihrer Kubernetes-Anwendungen maximieren können. Entdecken Sie praktische Schritt-für-Schritt-Anleitungen zur nahtlosen Integration von Cloud-Datenbanken und optimieren Sie Ihre GKE-Infrastruktur. Tauchen Sie ein und verbessern Sie die Leistung Ihrer Anwendungen in der Google Cloud noch heute!

Vorteile von Cloud SQL Proxy

Mit der Modernisierung von Anwendungen bewegen sich die Komponenten der Anwendungen nun in Richtung der Ressourcenhosting in öffentlichen Cloud-Umgebungen wie Google, Azure, Amazon usw. Schlüsselkomponenten wie Datenbanken und Cachespeicher haben ihren Weg zur Modernisierung gefunden. Die meisten Anwendungen werden nun containerisiert, um die Optimierung zu verbessern und den CO2-Fußabdruck zu reduzieren. In Anbetracht dieses Szenarios muss es einen Weg oder einen Pfad geben, um eine Verbindung zwischen den als Container gehosteten Anwendungen und den Cloud-Datenbankinstanzen herzustellen. Hier kommt der Cloud SQL Proxy ins Spiel. Mit dem Cloud SQL Proxy können wir die Verbindung zwischen der containerisierten Anwendung und der Cloud-Datenbankinstanz herstellen. Wir können auch eine Verbindung über die private IP-Adresse der Instanz herstellen, aber die unten aufgeführten Vorteile neigen dazu, den Cloud SQL Proxy als Verbindungsweg für Ihre Anwendungen mit den Cloud-Datenbankinstanzen zu verwenden.

• Sichere Verbindungen herstellen: Der Cloud SQL Proxy ermöglicht sichere Verbindungen, indem der Datenverkehr von und zu den Datenbankinstanzen verschlüsselt wird.
• IAM-basierte Datenbankauthentifizierung: Er ermöglicht die Authentifizierung unter Verwendung von Dienstkonten/Workload-Identitäten und repliziert somit den Zugriff über IAM.

Praktische Umsetzung - Einrichten des Cloud SQL Proxy als Container/POD in GKE

Im Folgenden finden Sie eine Liste der Voraussetzungen für den Aufbau eines Cloud SQL Proxy Pods.

• Ein vollwertiger Google Kubernetes Engine Cluster mit dem installierten kubectl-Tool.
• Falls wir die Verbindungen über eine private IP nutzen möchten, müssen wir sicherstellen, dass der Cloud SQL Proxy und die Datenbankinstanz das gleiche VPC-Netzwerk nutzen.
• Eine Cloud SQL-Instanz (MYSQL, PostgreSQL, SQL Server)
• Ein Konto in der PostgreSQL-Instanz. Die innerhalb des GKE-Clusters ausgeführte Anwendung wird diese Kontozugangsdaten verwenden, um eine Verbindung zur Datenbank herzustellen.

Schritt 1: Erstellen Sie ein Secret mit den Datenbankkonfigurationen

Für unsere Anwendung, die im Cluster läuft, werden wir den Cloud SQL Proxy als Sidecar konfigurieren. In diesem Szenario kommuniziert die Anwendung mit der Datenbankinstanz über den Proxy selbst. Wir müssen also die Datenbankkonfigurationswerte im gleichen Namespace bereitstellen, der vom Anwendungscontainer gemeinsam genutzt wird, wie unten gezeigt:

kubectl create secret generic <IHR-DB-SECRET> \
--from-literal=username=<IHR-DATENBANK-BENUTZER> \
--from-literal=password=<IHR-DATENBANK-PASSWORT> \
--from-literal=database=<IHR-DATENBANK-NAME>

Schritt 2: Holen Sie sich die Konfigurationswerte der Cloud SQL-Instanz

Um die Anwendung mit der Datenbankinstanz zu verbinden, müssen wir den Cloud SQL Proxy entweder als VM oder als Container (Sidecar) einrichten. Dafür benötigen wir die folgenden Informationen über die Cloud SQL-Instanz:

• Der Verbindungsname der Instanz
• Aktivieren Sie die Cloud SQL Admin-API im Projekt, das Ihren GKE-Cluster enthält
• Die JSON-Schlüsseldatei (Anmeldeinformation) des Dienstkontos, das die erforderlichen Berechtigungen im Google-Projekt hat, das die Ressource der Cloud SQL-Instanz enthält.

Schritt 3: Generieren Sie ein Servicekonto, das von Cloud SQL Proxy in GKE verwendet wird

Um eine Cloud SQL Proxy-Instanz innerhalb eines GKE-Clusters auszuführen, müssen wir ein Dienstkonto erstellen und ihm die erforderlichen Berechtigungen geben. Es wird empfohlen, für jede Anwendung ein separates Dienstkonto zu verwenden, um eine sicherere Erfahrung und einen reibungsloseren Übergang zu ermöglichen. Anforderungen des Dienstkontos:

• Es muss im gleichen Projekt erstellt werden, in dem die Cloud SQL-Instanz ausgeführt wird.
• Es muss mindestens die Rolle eines Cloud SQL Client IAM erhalten.
• Im Falle der Verwendung einer privaten IP für die Verbindung müssen die Cloud SQL-Instanz und GKE das gleiche VPC-Netzwerk gemeinsam nutzen.

gcloud iam service-accounts keys create ~/key.json \
--iam-account=YOUR-SA-NAME@project-id.iam.gserviceaccount.com

kubectl create secret generic YOUR-SA-SECRET \
--from-file=service_account.json=~/key.json

Schritt 4: Führen Sie den Cloud SQL Proxy als Sidecar/POD aus

Sobald wir Schritt 4 erreichen, müssen wir einen Sidecar-Proxycontainer innerhalb des Anwendungspods erstellen, aufgrund der folgenden Vorteile:

• Aufgrund der IAM-Datenbankberechtigungen reduziert die Verwendung des Sidecars die Exposition der Instanz für den gesamten Cluster.
• Es reduziert und verhindert die lokale Exposition des SQL-Ausgangsverkehrs, indem es ihn verschlüsselt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      containers:
      - name: <YOUR-APPLICATION-NAME>
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: database
      - name: cloud-sql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.28.0
        command:
          - "/cloud_sql_proxy"
          - "-ip_address_types=PRIVATE"
          - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"
          - "-credential_file=/secrets/service_account.json"
        securityContext:
          runAsNonRoot: true
        volumeMounts:
        - name: <YOUR-SA-SECRET-VOLUME>
          mountPath: /secrets/
          readOnly: true
        resources:
          requests:
            memory: "2Gi"
            cpu: "1"
      volumes:
      - name: <YOUR-SA-SECRET-VOLUME>
        secret:
          secretName: <YOUR-SA-SECRET>

Fazit

Damit sind wir am Ende dieses Themas angelangt. Kommentieren Sie gerne unten, falls Sie auf Fragen stoßen. Für weitere solche Beiträge zu Cloud-Datenbanken und Kubernetes-spezifischen Informationen bleiben Sie mit uns in Verbindung. Bis dahin, viel Spaß beim Lernen!