Die Verwaltung von Cloud Infrastrukturen durch manuelle Arbeiten in Portalen kann schnell fehleranfällig werden sowie auch Inkonsistenzen hervorbringen. Mit Infrastructure as Code (IaC) sowie dem Einsatz von automatisierten Pipelines können diese Gefahren minimiert und die Verwaltung der eigenen Cloud Infrastruktur simpler gestaltet werden. Wie dies mittels Terraform und GitHub Actions in einer Azure Umgebung aussehen kann, werde ich in diesem Beitrag aufzeigen.

Übersicht des Workflow

Der Workflow wird gestartet, indem ein Pull Request (PR) erstellt wird. Dabei wird die GitHub Action Aktion „Terraform Plan“ ausgeführt. Sobald der PR akzeptiert wird, wird dieselbe Action jedoch mit der „Terraform Apply“ Aktion ausgeführt. Diese Aktion deployed dadurch den Terraform Code in die Produktionsumgebung.

Für die Ausführung der Terraform Aktionen wie „terraform plan“ und „terraform apply“ werden zwei unterschiedliche App Registration im Entra ID Tenant erstellt, dies aufgrund dessen, dass für die beiden Aktionen jeweils andere Berechtigungen nötig sind und das Least-Privilege Prinzip befolgt werden soll.

App Registrations Erstellen

Die App Registrations und dazugehörige Credentials werden hier via Azure CLI erstellt, du kannst dies aber auch via Portal oder Terraform durchführen.

Wie in der Übersicht des Workflow aufgezeigt, werden zwei Application Registrations mit unterschiedlichen Berechtigungen benötigt. Daher muss der folgende Befehl zweimal mit unterschiedlichen App Namen durchgeführt werden. Ich empfehle, im App Namen bereits die entsprechende Rolle (Write oder Read-Only) zu beinhalten.

az ad app create --display-name {APP_NAME}

Federated Credentials für beide App Registrations erstellen. Mit diesen Authentifiziert sich die GitHub Action gegenüber Entra ID:

 az ad app federated-credential create \
  --id {APP_ID} \
  --parameters '{
    "name": "my-federated-cred",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:{GITHUB_USERNAME}/{REPO_NAME}:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"]
  }'

Rollenzuweisung App Registration

Damit die App Registrations auch die nötigen Aktionen in der Infrastruktur ausführen können, benötigen diese noch die entsprechenden RBAC Rollen:

Ressource	Read only App Role	Write App Role
TFState Storage Account	Storage Blob Data Contributor	Storage Blob Data Contributor
Subscription	Reader	Owner

Je nach Architektur kann die Reader bzw. Owner Rolle auch einer Management Group zugewiesen werden.

GitHub Repository Konfiguration

Bevor die GitHub Action erstellt werden kann, müssen noch diverse Environment Variablen gesetzt werden, auf welche innerhalb der Action zugegriffen wird.

Die Variablen können in GitHub unter den Repository Settings erstellt werden.

Variabel Typ	Name	Wert
Environment Secret (Production)	AZURE_CLIENT_ID	Client ID der Read/Write App Registration
Repository Secret	AZURE_CLIENT_ID	Client ID der Read-Only App Registration
Repository Secret	AZURE_SUBSCRIPTION_ID	Azure Subscription ID
Repository Secret	AZURE_TENANT_ID	Azure Tenant ID

Für das Repository ist die folgende Verzeichnisstruktur vorgesehen:

 

 

 

 

 

GitHub Action Definition

Die GitHub Action YAML Definition kann hier heruntergeladen werden: https://storageblogdemo01.blob.core.windows.net/public/tf-deploy.yml
Diese Definition muss im Repository unter „/.github/workflows“ abgelegt werden.

Insgesamt beinhaltet die Definition zwei Jobs:

• Terraform Plan
• Terraform Apply

Der erste Job prüft die korrekte Formatierung des Terraform Codes und führt ein „terraform plan“ gegen die entsprechenden Ressourcen durch. Sollten diese Schritte keine Fehler enthalten, wird der Plan als Artefakt abgelegt und im PR angezeigt.

Der Terrafom Apply Job wird jeweils nur ausgeführt, sollte es sich um einen merge nach main handeln. In diesem wird das zuvor erstellte Artefakt heruntergeladen und dem „terraform apply“ Befehl hinzugefügt.

Beispielausführung

Anhand eines Beispiels werde ich hier aufzeigen, wie sich die Pipeline in der Praxis verhaltet und dieses in GitHub angezeigt wird.
Sobald der PR erstellt wird, startet die GitHub Action und stellt den Output von terraform plan innerhalb des PR dar.

Im Plan sind dem Reviewer sämtliche Änderungen sichtbar, die an der Infrastruktur vorgenommen werden sollten. Sind diese sowie der Code selbst in Ordnung, wird der PR akzeptiert und die Action wird wieder gestartet um den Apply durchzuführen.

Die ausgeführte Action kann im Tab „Actions angezeigt werden, dabei sind auch die einzelnen Aktionen sowie die darin enthaltenen Schritte ersichtlich. Sollten Fehler bei der Ausführung der Action vorkommen, kannst du in dieser Übersicht die entsprechenden Fehlermeldung einsehen.

Fazit

Die Erstellung und Verwendung von Pipelines für die automatisierte Bereitstellung von Cloud Infrastruktur verändert zwar den grundlegenden Prozess wie Infrastruktur erstellt und verwaltet wird. Dadurch wird jedoch ein einheitlicher Prozess ermöglicht welcher durchgängigkeit in den bereitgestellten Ressourcen, schafft sowie eine klare Nachverfolgbarkeit von Änderungen.

 

Dieser Blogbeitrag wurde mit Unterstützung von KI erstellt.