Secret-Management mit GitHub

In jedem Softwareprojekt müssen Sie häufig sensible Informationen wie API-Schlüssel, Datenbankzugangsdaten oder Zugriffstokens verwenden. Wenn Sie diese direkt in Ihrem Code oder Repository speichern, stellt das ein erhebliches Sicherheitsrisiko dar.

Secret-Management bezeichnet die sichere Speicherung und Verwaltung dieser sensiblen Daten. Dadurch wird sichergestellt, dass nur autorisierte Systeme und Benutzer darauf zugreifen können, und eine unbefugte Offenlegung wird verhindert.

GitHub bietet mit den sogenannten GitHub Secrets eine sichere Möglichkeit, sensible Informationen zu speichern. Dabei handelt es sich um verschlüsselte Umgebungsvariablen, die Sie in Ihren GitHub-Actions-Workflows verwenden können.

• Sie werden standardmäßig nicht in die Protokolle geschrieben.
• Nach ihrer Erstellung sind sie in der Benutzeroberfläche nicht sichtbar.
• Sie sind nur für ausgewählte Workflows zugänglich.

So bleiben Ihre Zugangsdaten vor einer versehentlichen Offenlegung geschützt.

Sie können Secrets auf verschiedenen Ebenen definieren: Repository, Umgebung oder Organisation. Am häufigsten beginnen Sie mit Repository-Secrets.

So erstellen Sie ein Secret:

1. Öffnen Sie den Tab Settings Ihres Repositorys.
2. Wechseln Sie zu Secrets and variables > Actions.
3. Klicken Sie auf New repository secret.

Geben Sie einen eindeutigen Namen dafür an, z. B. API_KEY, und fügen Sie den Wert Ihres Secrets ein.

Sobald ein Secret definiert ist, können Sie es in Ihren Workflow-YAML-Dateien verwenden. GitHub Actions fügt Secrets automatisch als Umgebungsvariablen in Ihre Jobs ein.

Sie greifen über den Kontext ${{ secrets.SECRET_NAME }} darauf zu. Dieses Skript simuliert einen Schritt, der ein solches Secret verwenden würde. Stellen Sie sich für die Ausführung vor, dass MY_API_KEY von GitHub Actions als Umgebungsvariable gesetzt wurde.

Über Repository-Secrets hinaus bietet GitHub zwei weitere leistungsfähige Geltungsbereiche:

• Organization Secrets: Sind für mehrere Repositorys innerhalb einer Organisation verfügbar. Sie eignen sich für Secrets, die von vielen Projekten gemeinsam genutzt werden, z. B. ein organisationsweiter Deployment-Token.
• Environment Secrets: Sind an bestimmte Deployment-Umgebungen gebunden, z. B. staging oder production. Für sie können Schutzregeln gelten, etwa die Anforderung einer manuellen Genehmigung vor dem Deployment.

Verwenden Sie aus Sicherheitsgründen immer den kleinstmöglichen erforderlichen Geltungsbereich.

OpenID Connect (OIDC) ist eine Authentifizierungsschicht, die auf OAuth 2.0 aufbaut. Dabei handelt es sich um einen Standard, mit dem Clients die Identität eines Endbenutzers anhand der von einem Autorisierungsserver durchgeführten Authentifizierung überprüfen können.

In CI/CD ermöglicht OIDC Ihren Workflows die sichere Authentifizierung bei Cloud-Anbietern wie AWS, Azure oder GCP, ohne langlebige Zugangsdaten wie API-Schlüssel als GitHub Secrets speichern zu müssen.

GitHub Actions kann als OIDC-Anbieter fungieren. Wenn ein Workflow ausgeführt wird, generiert GitHub ein eindeutiges, kurzlebiges OIDC-Token für diesen bestimmten Job.

Dieses Token enthält überprüfbare Angaben zum Workflow, etwa Repository, Branch und Job-ID. Cloud-Anbieter können anschließend so konfiguriert werden, dass sie von GitHub ausgestellten Tokens vertrauen und anhand dieser Angaben vorübergehend Zugriff gewähren.

Die Verwendung von OIDC mit GitHub Actions bietet erhebliche Sicherheitsvorteile:

• Keine langlebigen Zugangsdaten: Sie speichern keine statischen Cloud-API-Schlüssel in GitHub Secrets.
• Geringeres Risiko: Kurzlebige Tokens minimieren die Auswirkungen, falls ein Token kompromittiert wird.
• Feingranularer Zugriff: Cloud-Rollen können bestimmten Workflow-Bedingungen zugeordnet werden, z. B. der Bedingung, dass ein Deployment nur vom main-Branch aus zulässig ist.
• Überwachung: Es lässt sich leichter nachvollziehen, wer was getan hat, da die Identitäten an die Workflow-Ausführung gebunden sind.

Um OIDC zu verwenden, müssen Sie Ihren Cloud-Anbieter, etwa AWS IAM, Azure AD oder GCP IAM, so konfigurieren, dass er GitHubs OIDC-Aussteller vertraut.

Dies umfasst typischerweise:

1. Einrichten eines Identity Providers (IdP) in Ihrem Cloud-Konto.
2. Definieren einer Rolle bzw. Richtlinie, die bestimmte Berechtigungen gewährt.
3. Hinzufügen einer „Trust Policy“ zur Rolle, die es GitHubs OIDC-Tokens erlaubt, diese Rolle zu übernehmen, häufig mit Bedingungen auf Grundlage der Token-Angaben, z. B. nur aus einem bestimmten Repository.

Der Workflow fordert anschließend ein Token an und verwendet es zur Authentifizierung.

Sie haben GitHub Secrets zum Speichern sensibler Daten und OpenID Connect für eine Cloud-Authentifizierung ohne Zugangsdaten kennengelernt.

Welche der folgenden Aussagen zur Verwaltung von Secrets in GitHub Actions sind RICHTIG?

Sehr gut! Sie haben gelernt, wie Sie sensible Daten in Ihren CI/CD-Pipelines sicher verwalten.

• GitHub Secrets bieten verschlüsselten Speicher für API-Schlüssel und Tokens innerhalb Ihres Repositorys, Ihrer Organisation oder bestimmter Umgebungen.
• OpenID Connect (OIDC) ermöglicht eine noch sicherere Authentifizierung bei Cloud-Anbietern, indem kurzlebige, überprüfbare Tokens anstelle statischer Zugangsdaten verwendet werden.

Diese Praktiken sind entscheidend für den Aufbau robuster und sicherer DevOps-Pipelines.