Migration von Pipeline-Variables zu Pipeline-Inputs – für mehr Sicherheit

Pipeline-Variables ermöglichen die Anpassung von GitLab CI/CD-Pipelines zur Laufzeit. Mit der Entwicklung von CI/CD-Sicherheits-Best-Practices wurde jedoch deutlich, dass stärkere Kontrollen bei der Pipeline-Anpassung erforderlich sind. Uneingeschränkte Pipeline-Variables erlauben Nutzern mit Pipeline-Trigger-Berechtigungen das Überschreiben von Werten ohne Validierung oder Typ-Prüfung. Dies schafft Sicherheitsrisiken durch Variable-Injection-Angriffe.

Pipeline-Variables fehlt zudem eine explizite Deklaration und Dokumentation. Dadurch ist schwer nachvollziehbar, welche Eingaben erwartet werden und wie diese in der Pipeline verwendet werden. Dies erschwert die Wartung und etabliert keine klare Governance über CI/CD-Prozesse.

Pipeline-Inputs als sichere Alternative

GitLab Pipeline-Inputs bieten eine systematische Lösung mit folgenden Eigenschaften:

Explizite Deklaration: Inputs müssen in der .gitlab-ci.yml explizit deklariert werden und sind selbstdokumentierend.

Typ-Sicherheit: Unterstützung verschiedener Input-Typen (string, boolean, number, array) mit automatischer Validierung.

Integrierte Validierung: Automatische Validierung von Input-Werten gegen definierte Constraints.

Verbesserte Sicherheit: Kein Risiko von Variable-Injection-Angriffen, da nur deklarierte Inputs von außen übergeben werden können.

Grundlegendes Beispiel

    spec:
      inputs:
        deployment_env:
          description: "Target deployment environment"
          type: string
          options: ["staging", "production"]
          default: "staging"
        enable_tests:
          description: "Run test suite"
          type: boolean
          default: true

    test:
      script:
        - echo "Running tests"
      rules:
        - if: $[[ inputs.enable_tests ]] == true

    deploy:
      script:
        - echo "Deploying to $[[ inputs.deployment_env ]]"

Weitere Details zur typ-sicheren Parameter-Übergabe mit Validierung finden sich im CI/CD-Inputs-Tutorial.

Restriktion von Pipeline-Variables

Für die Migration zu Pipeline-Inputs ist die Konfiguration der Einstellung "Minimum role to use pipeline variables" erforderlich. Diese Einstellung ermöglicht granulare Kontrolle darüber, welche Rolle Pipeline-Variables beim Triggern von Pipelines verwenden darf.

Auf Projekt-Ebene: Navigation zu Settings > CI/CD > Variables > Minimum role to use pipeline variables.

Verfügbare Optionen:

• No one allowed (no_one_allowed) – Empfohlene und sicherste Option. Verhindert alle Variable-Overrides.
• Developer (developer) – Erlaubt Developern und höheren Rollen das Überschreiben von Variables
• Maintainer (maintainer) – Erfordert Maintainer-Rolle oder höher
• Owner (owner) – Nur Projekt-Owner können Variables überschreiben

Auf Group-Ebene: Group-Maintainer können unter Settings > CI/CD > Variables > Default role to use pipeline variables sichere Defaults für alle neuen Projekte innerhalb der Group festlegen. Dies gewährleistet konsistente Sicherheitsrichtlinien. Auch hier wird No one allowed als Default-Wert empfohlen, sodass neue Projekte mit sicherer Standardeinstellung erstellt werden. Projekt-Owner können die Einstellung weiterhin ändern.

Bei vollständiger Restriktion von Pipeline-Variables (mit "No one allowed") erscheinen die prefilled variables nicht im "New Pipeline UI"-Formular.

Migration von Pipeline-Variables

Lücken schließen

Gruppen können Projekte enthalten, bei denen Pipeline-Variables standardmäßig aktiviert sind, obwohl sie nie beim Triggern einer Pipeline verwendet wurden. Diese Projekte können ohne Unterbrechungsrisiko zur sichereren Einstellung migriert werden. GitLab bietet Migrationsfunktionalität über Group-Einstellungen:

• Navigation zu Settings > CI/CD > Variables
• In Disable pipeline variables in projects that don't use them auf Start migration klicken

Diese Migration ist ein Background-Job, der Pipeline-Variables über Projekt-Einstellungen für alle Projekte deaktiviert, die diese historisch nicht verwendet haben.

Konvertierung von Pipeline-Variables zu Inputs

Für jede identifizierte Pipeline-Variable ist ein entsprechender Pipeline-Input zu erstellen.

Vorher (mit Pipeline-Variables):

    variables:
      DEPLOY_ENV:
        description: "Deployment environment"
        value: "staging"
      ENABLE_CACHE:
        description: "Enable deployment cache"
        value: "true"
      VERSION:
        description: "Application version"
        value: "1.0.0"

    deploy:
      script:
        - echo "Deploying version $VERSION to $DEPLOY_ENV"
        - |
          if [ "$ENABLE_CACHE" = "true" ]; then
            echo "Cache enabled"
          fi

Nachher (mit Pipeline-Inputs):

    spec:
      inputs:
        deploy_env:
          description: "Deployment environment"
          type: string
          default: "staging"
          options: ["dev", "staging", "production"]
        enable_cache:
          description: "Enable deployment cache"
          type: boolean
          default: true
        version:
          description: "Application version"
          type: string
          default: "1.0.0"
          regex: '^[0-9]+\.[0-9]+\.[0-9]+$'

    deploy:
      script:
        - echo "Deploying version $[[ inputs.version ]] to $[[ inputs.deploy_env ]]"
        - |
          if [ "$[[ inputs.enable_cache ]]" = "true" ]; then
            echo "Cache enabled"
          fi

Migration von Trigger-Jobs

Bei Verwendung von Trigger-Jobs mit dem trigger-Keyword ist sicherzustellen, dass diese keine Job-Level-variables definieren oder das Erben von Variables von Top-Level variables, extends oder include deaktivieren. Variables könnten implizit als Pipeline-Variables downstream übergeben werden. Bei restriktiven Pipeline-Variables im Downstream-Projekt schlägt die Pipeline-Erstellung fehl.

Die CI-Konfiguration sollte auf Pipeline-Inputs statt Pipeline-Variables aktualisiert werden:

    variables:
      FOO: bar

    deploy-staging:
      inherit:
        variables: false  # sonst würde FOO downstream als Pipeline-Variable gesendet
      trigger:
        project: myorg/deployer
        inputs:
          deployment_env: staging
          enable_tests: true

Zusammenfassung

Die Migration von Pipeline-Variables zu Pipeline-Inputs ist eine Sicherheitsverbesserung, die CI/CD-Infrastruktur vor Variable-Injection schützt und gleichzeitig bessere Dokumentation, Typ-Sicherheit und Validierung bietet. Die Implementierung dieser Restriktionen und Übernahme von Pipeline-Inputs verbessert nicht nur die Sicherheit, sondern macht Pipelines wartbarer, selbstdokumentierend und robuster.

Die Transition erfordert initialen Aufwand, die langfristigen Vorteile überwiegen jedoch die Migrationskosten. Der Einstieg erfolgt durch Restriktion von Pipeline-Variables auf Group-Ebene für neue Projekte, gefolgt von systematischer Migration bestehender Pipelines mittels der oben beschriebenen Vorgehensweise.

Sicherheit ist ein kontinuierlicher Prozess. Pipeline-Inputs sind ein wichtiger Schritt zur Schaffung einer sichereren CI/CD-Umgebung und ergänzen weitere GitLab-Sicherheitsfunktionen wie Protected Branches, Job-Token-Allowlists und Container-Registry-Protections.

Für den Einstieg mit Pipeline-Inputs: Kostenlose GitLab-Ultimate-Testversion anfordern.