KI-Agenten mittels GitLab in Cloud Run bereitstellen

KI-Agents für Production-Umgebungen bereitzustellen erfordert systematische Absicherung. Dieser Leitfaden beschreibt, wie sich AI-Agents mittels Googles Agent Development Kit (ADK) in Cloud Run deployen lassen – mit GitLabs nativer Integration und CI/CD-Komponenten. Cloud Run bietet serverless Deployment ohne Kubernetes-Cluster-Management.

Was sind AI-Agents und warum sind sie relevant?

Agentische KI stellt eine bedeutende Entwicklung im Bereich künstliche Intelligenz dar. Anders als traditionelle generative KI-Tools, die konstante menschliche Anleitung erfordern, nutzen AI-Agents fortgeschrittene Language Models und Natural Language Processing für autonome Aktionen. Diese Systeme können Anfragen verstehen, Entscheidungen treffen und mehrstufige Pläne selbstständig ausführen.

Dieses Tutorial nutzt Googles ADK, ein flexibles und modulares Framework für die Entwicklung und Bereitstellung von AI-Agents. ADK ist für Gemini und das Google-Ökosystem optimiert, bleibt jedoch model-agnostisch, deployment-agnostisch und kompatibel mit anderen Frameworks.

Demo-Anwendung: Canada City Advisor

Das Deployment-Beispiel demonstriert eine praktische Multi-Agent-Architektur: Der Canada City Advisor hilft Nutzenden, die ideale kanadische Stadt basierend auf Präferenzen und Rahmenbedingungen zu finden.

Der Ablauf:

• Nutzende geben Budget-Anforderungen und Lifestyle-Präferenzen ein
• Der Root-Agent koordiniert zwei Sub-Agents:
  • Budget-Analyzer-Agent: Evaluiert finanzielle Rahmenbedingungen (Datenquelle: Canada Mortgage and Housing Corporation)
  • Lifestyle-Preferences-Agent: Matcht Städte mit Nutzer-Anforderungen (nutzt Weather-Service mit Open-Meteo für Stadt-Informationen)
• Das System generiert personalisierte Stadt-Empfehlungen

Diese Multi-Agent-Architektur zeigt die Möglichkeiten agentischer KI: Spezialisierte Agents arbeiten zusammen, um komplexe Probleme zu lösen. Die Sub-Agents werden nur aktiviert, wenn der Root-Agent Budget- und Lifestyle-Analyse als notwendig bestimmt.

Voraussetzungen

Folgende Anforderungen müssen erfüllt sein:

• Google Cloud-Projekt mit aktivierten APIs:
  • Cloud Run API
  • Artifact Registry API
  • Vertex AI API
• GitLab-Projekt für Source Code
• Entsprechende Permissions in GitLab und Google Cloud

Schritt 1: IAM-Integration mit Workload Identity Federation

Der erste Schritt etabliert sichere, keyless Authentifizierung zwischen GitLab und Google Cloud mittels Workload Identity Federation. Dies eliminiert Service-Account-Keys und verbessert die Sicherheit.

Im GitLab-Projekt:

1. Navigieren zu Settings > Integrations > Google Cloud IAM
2. Folgende Angaben bereitstellen:
   • Project ID: Google Cloud Project ID
   • Project Number: In Google Cloud Console zu finden
   • Pool ID: Eindeutiger Identifier für Workload Identity Pool
   • Provider ID: Eindeutiger Identifier für Identity Provider

GitLab generiert ein Script. Dieses Script in Google Cloud Shell ausführen, um die Workload Identity Federation zu erstellen.

Schritt 2: Google Artifact Registry Integration konfigurieren

Als Nächstes wird die Verbindung zu Google Artifact Registry konfiguriert, wo Container-Images gespeichert werden.

1. In GitLab navigieren zu Settings > Integrations > Google Artifact Registry
2. Eingaben:
   • Google Cloud Project ID: Wie in Schritt 1
   • Repository Name: Name eines existierenden Artifact Registry Repository
   • Location: Region des Repository

Wichtig: Das Repository muss bereits in Artifact Registry existieren. GitLab erstellt in diesem Kontext kein neues Repository.

GitLab generiert Commands für die notwendigen Permissions. Diese in Google Cloud Shell ausführen.

Zusätzlich folgende Rollen zum Service Principal für Cloud Run-Deployment hinzufügen:

• roles/run.admin
• roles/iam.serviceAccountUser
• roles/cloudbuild.builds.editor

Die Rollen lassen sich mittels folgender gcloud-Commands hinzufügen:

GCP_PROJECT_ID="<your-project-id>" #replace
GCP_PROJECT_NUMBER="<your-project-number>" #replace
GCP_WORKLOAD_IDENTITY_POOL="<your-pool-id>" #replace

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/run.admin'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/iam.serviceAccountUser'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/cloudbuild.builds.editor'

Schritt 3: CI/CD-Pipeline erstellen

Die Deployment-Pipeline nutzt GitLabs CI/CD-Komponenten. Diese vereinfachen die Konfiguration erheblich.

Eine .gitlab-ci.yml-Datei im Projekt-Root erstellen:

stages:
  - build
  - test
  - upload
  - deploy

variables:
  GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA
  AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA

build:
  image: docker:24.0.5
  stage: build
  services:
    - docker:24.0.5-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $GITLAB_IMAGE .
    - docker push $GITLAB_IMAGE

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main
    inputs:
      stage: upload
      source: $GITLAB_IMAGE
      target: $AR_IMAGE
  - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main
    inputs:
      stage: deploy
      project_id: "<your-project-id>" #replace
      service: "canadian-city"
      region: "us-central1"
      image: $AR_IMAGE

Die Pipeline besteht aus vier Stages:

1. Build: Erstellt den Docker-Container mit dem AI-Agent
2. Test: Führt Security-Scans aus (Container-Scanning, Dependency-Scanning, SAST)
3. Upload: Pusht den Container zu Artifact Registry
4. Deploy: Deployt zu Cloud Run

Der Vorteil von GitLabs CI/CD-Komponenten: Es sind nur wenige Parameter erforderlich – die Komponenten übernehmen die komplexe Authentifizierungs- und Deployment-Logik.

Schritt 4: Deployment und Test

Mit vollständiger Konfiguration erfolgt das Deployment:

1. Code und .gitlab-ci.yml zum GitLab-Repository committen
2. Die Pipeline triggert automatisch
3. Pipeline-Fortschritt im GitLab CI/CD-Interface überwachen
4. Nach Abschluss die Cloud Run-URL in der Google Cloud Console finden

Die Stages werden nacheinander ausgeführt:

• Build-Stage erstellt den Container
• Test-Stage führt umfassende Security-Scans aus
• Upload-Stage pusht zu Artifact Registry
• Deploy-Stage erstellt oder aktualisiert den Cloud Run-Service

Sicherheitsvorteile

Der Ansatz bietet mehrere Sicherheitsvorteile:

• Keine langlebigen Credentials: Workload Identity Federation eliminiert Service-Account-Keys
• Automatisierte Security-Scans: Jedes Deployment wird auf Schwachstellen geprüft
• Audit-Trail: Vollständige Nachvollziehbarkeit, wer was wann deployed hat
• Principle of Least Privilege: Fein-granulare IAM-Rollen limitieren Zugriff

Der systematische Ansatz mit integrierten Security-Scans erfüllt beispielsweise Anforderungen der NIS2-Richtlinie. Die Pipeline erzeugt vollständige Audit-Trails vom Code-Commit bis zur Production. OIDC-Authentifizierung eliminiert Credential-Management und schafft nachvollziehbare Zugriffsprotokolle – relevant für DSGVO-Compliance und interne Audit-Anforderungen.

CLOUD RUN ODER GKE?

Cloud Run (Serverless):

• Kein Kubernetes-Cluster-Management erforderlich
• Automatisches Scaling ohne Konfiguration
• Pay-per-use statt fester Cluster-Kosten
• Schneller Einstieg für einfache AI-Agents

GKE (Kubernetes-Orchestrierung):

• Vollständige Cluster-Kontrolle
• Komplexe Multi-Service-Architekturen
• Enterprise-Orchestrierung mit HPA, Custom Resources

→ Tutorial: KI-Agenten mittels GitLab in GKE bereitstellen

Zusammenfassung

Die Kombination von GitLabs Security-Features mit Google Clouds AI- und Serverless-Plattformen ermöglicht sichere und skalierbare AI-Agent-Deployments. Die Integration zwischen GitLab und Google Cloud vereinfacht den Prozess erheblich.

Das komplette Code-Beispiel zum Testen: GitHub Repository. Noch kein GitLab-Kunde? Die DevSecOps-Plattform lässt sich mit einer kostenlosen Testversion erkunden.