Verteilen von Secrets

Der Problembereich der Verteilung von Secrets ist weit verbreitet. Sie haben eine sensible Information, möchten sie an einen Dienst verteilen und diese Aktion auf sichere Weise umsetzen. Diese sensible Information kann ein Passwort, ein API-Schlüssel, ein TLS-Zertifikat oder alles andere sein, was Sie geheim halten möchten.

Ein häufiges Problem bei der Verteilung von Secrets ist auch die Notwendigkeit, diese Daten rotieren zu lassen. Dies ist eine bewährte Sicherheitsmethode und wird häufig von Compliance-Standards gefordert. Das Rotieren von Secrets kann ein komplexer Prozess sein, insbesondere wenn Sie es über mehrere Dienste hinweg durchführen müssen.

Sie sind sich vielleicht auch des Problems bewusst, dass verteilte Secrets schwer zu verwalten sein können. Möglicherweise haben Sie diese sensiblen Informationen an mehreren Orten gespeichert, und es kann schwierig sein, den Überblick darüber zu behalten, wo sie sich befinden und wer Zugriff darauf hat.

Authentifizierung von Gitlab mittels HashiCorp Vault

HashiCorp Vault ist ein Verwaltungstool für sensitive Informationen, das Ihnen bei der Lösung dieser Probleme helfen kann. Vault kann Informationen speichern, an Dienste verteilen und rotieren. Es kann Ihnen auch dabei helfen, den Zugriff auf Secrets zu verwalten, sodass Sie steuern können, wer Zugriff auf was hat.

Sie können Gitlab so konfigurieren, dass es sich bei HashiCorp Vault authentifiziert, um notwendige Secrets ohne Datenduplizierung abzurufen. Auf diese Weise können Sie Ihre Geheimnisse an einem zentralen Ort speichern und sie auf sichere Weise von Ihren Diensten abrufen. Für dieses Setup gibt es bereits eine Dokumentation in der Gitlab-Dokumentation, wir möchten Ihnen jedoch zeigen, wie Sie die Authentifizierung mit HashiCorp Terraform einrichten.

Json Web Token Authentifizierung (JWT)

1resource "vault_jwt_auth_backend" "jwt_gitlab" {
2  description        = "Gitlab.com auth backend"
3  path               = "jwt_gitlab"
4  oidc_discovery_url = "https://gitlab.com"
5  bound_issuer       = "https://gitlab.com"
6  default_role       = "gitlab_readonly"
7}

Als ersten Schritt müssen wir das JWT-Authentifizierungs-Backend für unsere Gitlab-Instanz definieren – in unserem Beispiel bleiben wir auf gitlab.com. In diesem ersten Konfigurationsblock befindet sich bereits ein Verweis auf die Standardrolle, die im Authentifizierungsworkflow verwendet wird, wenn der Client keine dedizierte Rolle anfordert.

 1resource "vault_jwt_auth_backend_role" "jwt_gitlab_readonly" {
 2
 3  backend                = vault_jwt_auth_backend.jwt_gitlab.path
 4  role_name              = "gitlab_readonly"
 5  role_type              = "jwt"
 6  user_claim             = "user_email"
 7  token_explicit_max_ttl = 60 * 10
 8  token_policies         = [vault_policy.packer_ansible_update.name, vault_policy.tfc_access.name, "default"]
 9  bound_claims_type      = "glob"
10  bound_claims = {
11    namespace_path = "infralovers"
12    project_path   = "**/*"
13  }
14}

Als Standardrolle in diesem Beispiel definieren wir bound_claims so, dass sie mit dem Namespace der infralovers-Organisation innerhalb von gitlab.com übereinstimmt. In der Dokumentation von Gitlab finden Sie eine detailliertere Beschreibung der Parameter, deren Kenntnis hilfreich sein kann, wenn Sie die bound_claims Definition für Ihre Rollen entsprechend den tatsächlichen Anforderungen bestimmter Clients anpassen.

JWT Authentifizierung in Gitlab CI/CD Pipelines

Anschließend können wir unsere Gitlab CI/CD-Pipeline ändern, um die vorherige Konfiguration zu nutzen und auf Secrets unserer Vault-Installation zuzugreifen.

 1variables:
 2  VAULT_ADDR: "https://vault.example.com"
 3  VAULT_ROLE: "gitlab_readonly"
 4  VAULT_PATH: "jwt_gitlab"
 5  VAULT_AUTH_PATH: "auth"
 6
 7job_with_secrets:
 8  id_tokens:
 9    VAULT_ID_TOKEN:
10      aud: $VAULT_ADDR
11  secrets:
12    STAGING_DB_PASSWORD:
13      vault: secret/myproject/staging/db/password@secrets # authenticates using $VAULT_ID_TOKEN
14  script:
15    - access-staging-db.sh --token $STAGING_DB_PASSWORD

Der Block variables beinhaltet Umgebungsvariablen, um die Parameter zu definieren, die wir in der vorherigen Terraform-Konfiguration angegeben haben. Der eigentliche Block id_tokens und der Block secrets fügen Informationen in die Pipeline ein, die Gitlab mit unserer HashiCorp Vault-Instanz interagieren lässt, um die referenzierten Secrets abzurufen und diese Informationen als Umgebungsvariable an den eigentlichen Pipeline-Job zu übergeben.

Viel Spaß beim Ausprobieren!