GitLab Secrets Manager unterstützt ESO, Terraform und API

Heutzutage laufen oftmals Secret-Stores für CI/CD, Kubernetes und Terraform unabhängig nebeneinander. Das bedeutet allerdings: mehr Werkzeuge verwalten, Zugriffsmodelle synchron halten und im Fehlerfall Audit-Trails aus verschiedenen Quellen zusammenführen.

GitLab Secrets Manager unterstützt jetzt den External Secrets Operator (ESO) und Terraform und erweitert damit den sicheren Abruf von Secrets über CI/CD-Pipelines hinaus. Auf Basis von OpenBao bietet GitLab Secrets Manager eine einzige verlässliche Quelle für Secrets entlang der gesamten Software-Delivery-Kette. Derselbe Secret-Store bedient jetzt:

• Kubernetes-Workloads über ESO
• Terraform- oder OpenTofu-Runs
• OpenBao- oder Vault-CLI
• CI/CD-Jobs in GitLab (ab Version 19.0)
• jede externe Automatisierung über die Secrets Manager API

Kubernetes: External Secrets Operator

ESO synchronisiert Secrets aus GitLab Secrets Manager über den Vault-Provider. Ein Workload im Cluster hält ein kurzlebiges JSON Web Token (JWT). Damit authentifiziert sich ESO bei OpenBao und schreibt das Secret in ein Kubernetes Secret.

Ein SecretStore legt fest, woher ESO Secrets bezieht und wie authentifiziert wird. GitLab Secrets Manager stellt eine Vault-kompatible KV-v2-API bereit, die sich über den Vault-Provider konfigurieren lässt. Das Feld namespace bildet die GitLab-Hierarchie ab (Organisation, Gruppe, Projekt) und grenzt ein, welche Secrets dieser Store erreichen kann. Die Authentifizierung nutzt ein von GitLab ausgestelltes JWT, das in einem Kubernetes Secret liegt und über secretRef referenziert wird.

      apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gitlab-secrets-manager
  namespace: my-app
spec:
  provider:
    vault:
      server: https://secrets.gitlab.com      # provider.vault.server
      path: secrets/kv                        # provider.vault.path
      version: v2
      namespace: org_5/group_42/project_99    # provider.vault.namespace
      auth:
        jwt:
          path: api_jwt/cel                   # provider.vault.auth.jwt.path
          role: all_api                       # provider.vault.auth.jwt.role
          secretRef:
            name: gitlab-access-token         # Kubernetes secret holding the minted token
            key: token

    

Ein ExternalSecret definiert, welche Secrets geholt werden und wohin sie gehören. Es referenziert den zuvor angelegten SecretStore und bildet Remote-Secrets auf ein Kubernetes Secret ab, das Workloads einhängen oder als Umgebungsvariablen referenzieren können.

ESO erstellt und besitzt das Ziel-Secret (synced-secret) und holt es bei jedem refreshInterval erneut von GitLab, sodass rotierte Werte ohne erneutes Deployment ankommen. Jeder Eintrag unter data bildet ein Remote-Secret auf einen Schlüssel im Ziel ab: remoteRef.key ist der Pfad im GitLab Secrets Manager, property wählt ein Feld innerhalb dieses Secrets aus, und secretKey ist der Schlüssel, unter dem es in Kubernetes landet.

      apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
  namespace: my-app
spec:
  refreshInterval: 45m
  secretStoreRef:
    name: gitlab-secrets-manager
    kind: SecretStore
  target:
    name: synced-secret
  data:
    - secretKey: value
      remoteRef:
        key: explicit/<secret_name>           # <secrets_path>/<secret_name>
        property: value

    

Das Tutorial zeigt GitLab Secrets Manager zusammen mit ESO.

Infrastructure as Code: Terraform und OpenTofu

Terraform-State und .tfvars-Dateien sind eine häufige Quelle geleakter Zugangsdaten, weil Secrets versehentlich auf der Festplatte landen oder in die Versionskontrolle eingecheckt werden. Terraform kann das vermeiden, indem es ein GitLab-Secret als Data Source liest und sich zum Zeitpunkt von plan oder apply mit einem ausgestellten JWT authentifiziert. Zugangsdaten lassen sich damit direkt in Terraform referenzieren, ohne dass etwas in .tfvars-Dateien oder CI/CD-Variablen gespeichert wird.

      data "external" "gitlab_secrets_token" {
  program = ["bash", "${path.module}/scripts/mint_token.sh"]

  query = {
    project_id = var.gitlab_project_id
  }
}

provider "vault" {
  address   = data.external.gitlab_secrets_token.result.server
  namespace = data.external.gitlab_secrets_token.result.namespace

  auth_login_jwt {
    mount = data.external.gitlab_secrets_token.result.auth_path
    role  = data.external.gitlab_secrets_token.result.role
    jwt   = data.external.gitlab_secrets_token.result.jwt
  }
}

data "vault_kv_secret_v2" "my_secret" {
  mount = data.external.gitlab_secrets_token.result.mount
  name  = "${data.external.gitlab_secrets_token.result.secrets_path}/<secret_name>"
}

output "secret_value" {
  value     = data.vault_kv_secret_v2.my_secret.data["value"]
  sensitive = true
}

    

Wie sich Secrets in Terraform lesen lassen, zeigt die Dokumentation.

Kommandozeile: OpenBao- oder Vault-CLI

Nicht jeder Workflow läuft direkt über die API. Wer ohnehin schon Skripte gegen Vault-kompatible Werkzeuge schreibt, liest mit der OpenBao- oder Vault-CLI Secrets aus GitLab Secrets Manager genauso wie aus Vault.

      export VAULT_ADDR="<server>"
export VAULT_NAMESPACE="<namespace>"

# Exchange the minted JWT for an OpenBao token, then export it.
vault write "auth/<auth_jwt_path>/login" role=<role> jwt=<token>
export VAULT_TOKEN="<client_token>"

# Read the secret value.
vault kv get -mount=<path> "<secrets_path>/<secret_name>"

    

Wann die Secrets Manager API sinnvoll ist

Für Automatisierung, die weder zu GitLab CI/CD noch zu Kubernetes oder Terraform passt, ermöglicht die Secrets Manager API beliebigen externen Systemen, Secrets aus dem Secrets Manager abzurufen, statt Zugangsdaten fest zu hinterlegen oder getrennte Variablendateien zu pflegen.

      # Request JWT token using Service Account
RESPONSE=$(curl --silent --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/<project_id>/secrets_manager/access_token")

SERVER=$(echo "$RESPONSE" | jq --raw-output .provider.vault.server)
NAMESPACE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.namespace)
MOUNT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.path)
SECRETS_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.secrets_path)
AUTH_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.path)
ROLE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.role)
JWT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.token)

# Exchange the JWT for a short-lived OpenBao token.
VAULT_TOKEN=$(curl --silent --request POST \
  --header "X-Vault-Namespace: $NAMESPACE" \
  --data "{\"role\":\"$ROLE\",\"jwt\":\"$JWT\"}" \
  "$SERVER/v1/auth/$AUTH_PATH/login" | jq --raw-output .auth.client_token)

# Read the secret value.
curl --silent \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --header "X-Vault-Namespace: $NAMESPACE" \
  "$SERVER/v1/$MOUNT/data/$SECRETS_PATH/<secret_name>"

    

Erste Schritte

GitLab Secrets Manager ist in der Public Beta für Premium und Ultimate. Der Secret-Zugriff über ESO, Terraform oder die API steht derzeit auf GitLab.com und GitLab Self-Managed zur Verfügung, GitLab Dedicated folgt.

Während der Beta-Phase ist Secrets Manager kostenlos. Mit der allgemeinen Verfügbarkeit wird daraus eine kostenpflichtige Funktion, die über GitLab Credits abgerechnet wird. Vor einer Abrechnung ist eine ausdrückliche Zustimmung nötig, und wir kündigen das rechtzeitig an.

Die Dokumentation hilft beim Einstieg. Wer eine Lücke findet oder einen Wunsch hat, kommentiert in diesem Issue. Wir sammeln Feedback vor der allgemeinen Verfügbarkeit.