Im vorherigen Artikel dieser Blogserie wurden bereits Variablen von GitHub Actions vorgestellt. In diesem Artikel wird betrachtet wie die Variablen im Zusammenspiel mit Secrets verwendet werden können. Die meisten Projekte benötigen Secrets, um z.B. Verbindungszeichenfolgen, Passwörter, API-Keys und generell sensitive Informationen zu schützen. Falls diese öffentlich zugänglich werden, so ist dies für jedes Projekt eine Katastrophe.
GitHub Actions verwendet verschlüsselte Variablen, um die Informationen zu schützen. Dabei wird sichergestellt, dass die Informationen GitHub verschlüsselt erreichen und bis zur Verwendung in einem Workflow verschlüsselt bleiben.
Zugriffsebenen von Secrets
Secrets können auf verschiedenen Zugriffsebenen erstellt werden. So können bestimmte Informationen auf Organisationsebene oder Repository spezifisch bereitgestellt werden. Durch Secrets auf Organisationsebene wird sichergestellt, dass Informationen, die über verschiedene Repositories hinweg benötigt werden, nicht doppelt angelegt und verwaltet werden müssen. Spezifische Informationen können auf Ebene des Repositories hinterlegt werden. Durch Policies kann der Zugriff von Repositories auf die Secrets verwaltet werden.
Dieses Konzept verwendet Azure DevOps ebenfalls und die Parallelen können dahingehend gezogen werden, dass dort Pipeline spezifische Variablen und Variablen-Gruppen über Repositories hinweg zum Einsatz kommen.
Anlegen von Secrets
Um Secrets Repository spezifisch anlegen zu können werden Owner-Rechte benötigt. Auf Organisationsebene müssen Adminrechte vorhanden sein.
Für das Anlegen von Secrets für ein spezifisches Repository kann in der Repository-Ansicht auf Einstellungen navigiert werden. Unter dem Punkt Secrets können diese dann angelegt und verwaltet werden. Auf Organisationsebene funktioniert dies ähnlich, dort kann in der Organisations-Ansicht auf Einstellungen navigiert werden und anschließend ebenfalls über den Unterpunkt Secrets auf die Variablen zugegriffen werden.
Secrets in GitHub Workflow verwenden
Damit die Secrets auch geheim bleiben, werden keine Secrets außer das GITHUB_TOKEN an die Runner von Forked Repositories weitergegeben.
Die Verwendung von Secrets sieht genauso aus wie eine Template-Expression in Azure DevOps.
Durch GitHub Actions ist auch ein Zugriff auf Secrets über eine API für authentifizierte Nutzung, OAuth Apps oder GitHub Apps möglich. GitHub Apps benötigen dafür die Secrets-Berechtigung. Authentifizierte Nutzer benötigen Collaboration-Rechte. Dies bedeutet aber auch, sobald jemand diese Rechte auf das Repository hat, kann er auf die Secrets zugreifen. Wenn dies vermieden werden soll, so muss über Forks gearbeitet werden, daher ist es wichtig dieses Detail zu kennen.
Limitierungen von Secrets
Ein GitHub Workflow kann bis zu 100 Secrets besitzen. Die Namen müssen eindeutig sein und die Größenlimitierung beträgt 64KB. Größere Secrets können über Umwege dennoch im Repository verschlüsselt abgelegt und verwendet werden, sofern dies erforderlich wird.
Fazit
Die Verwendung und Verwaltung von Secrets ist sehr ähnlich zu der Handhabung in Azure Pipelines. Wichtig ist hier natürlich der Aspekt der Sicherheit, denn wie eingangs erwähnt muss vermieden werden, dass sensitive Informationen öffentlich werden. Dies ist auf GitHub gut dokumentiert und kann dort entsprechend nachvollzogen werden. Nach einer kurzen Einarbeitungszeit gewöhnt man sich recht schnell an die Verwaltung und Verwendung von Secrets. Verwendet man kein Naming-Schema, so verliert man recht schnell den Überblick, besonders bei Organisationsweiten Secrets und vielen eingebundenen Diensten.
Im nächsten Artikel wird betrachtet, wie Workflows getriggered werden können und welche Berechtigungen dazu benötigt werden – können Externe sogar den Workflow triggern?
Sprechen Sie uns an, wenn Sie Fragen haben oder Unterstützung in Ihrem Softwareentwicklungsprozess benötigen: Von der ersten Idee über die Entwicklung mit einer Build- und Release-Pipeline bis hin zur Inbetriebnahme und Wartung. Wir führen Sie gerne ans Ziel.