s0sta
EN DE NL عربي
Kontakt aufnehmen

DevSecOps-Projekte

Infrastructure as Code

Azure-k3s-Plattform

Eine kleine Kubernetes-Plattform in Produktionsqualität auf Azure, nur aus Code gebaut: Terraform erstellt die Cloud-Teile, Ansible härtet die Server und installiert k3s, und eine Pipeline wendet jede Änderung nach Prüfung an, ohne gespeicherte Secrets.

Code auf GitHub (opens in a new tab) Pipeline-Läufe (opens in a new tab)
  • Terraform
  • Azure
  • Ansible
  • k3s
  • Helm
  • Prometheus
  • Grafana
  • Loki
  • Fluent Bit
  • cert-manager
  • Key Vault
  • GitHub Actions
  • OIDC

Auf einen Blick

3
VMs mit einem Befehl
0
Secrets in der Pipeline (OIDC)
2
Prüfungen vor einer Änderung: Plan und Freigabe
1
Befehl, um alles zu löschen

Das Ziel

Von Hand gebaute Server laufen auseinander, niemand weiß, wer was geändert hat, und eine verlorene VM neu aufzubauen dauert einen Tag. Das Ziel: eine Plattform, in der die ganze Umgebung Code ist, jede Änderung vorher als Plan geprüft wird, die Server jedes Mal gleich gehärtet werden und die Kosten unter Kontrolle bleiben.

Was es zeigt

Infrastructure as Code
Terraform (azurerm 4) mit zwei Modulen (Netzwerk, Knoten) und Remote State in Azure Storage mit Entra-ID-Anmeldung.
Netzwerk
VNet und NSG mit Deny als Standard, NAT-Gateway für ausgehenden Verkehr, Standard Load Balancer für 80/443, Admin-Zugang nur von Ihrer IP.
Identität und Secrets
GitHub OIDC (kein Client-Secret), Managed Identities auf den VMs, das k3s-Join-Token in Key Vault.
Härtung
SSH, sysctl, auditd, fail2ban, automatische Updates; k3s-Secret-Verschlüsselung, Pod Security, Audit-Log und verschlüsseltes Pod-Netzwerk.
Observability
Prometheus, Alertmanager, Grafana, Loki, Fluent Bit mit eigenen Alarmregeln und Azure Monitor für die Systemlogs.
Kostenkontrolle
Ein Budget mit Prognose-Alarm, kleine VM-Größen, eine Log-Grenze und ein Befehl, um alles zu löschen.

Architektur

Die Azure-Umgebung. Nur der Load Balancer ist für Websites öffentlich; SSH und die Kubernetes-API antworten nur der Admin-IP.

The Azure k3s platform: network, nodes, cluster, Key Vault, monitoring and the pipelineAzure — resource group (Terraform)VNet 10.40.0.0/16 · NSG: deny by defaultAdmin laptopadmin_cidrs onlyGitHub ActionsOIDC loginno stored secretUserswebsitesInternetupdates, imagesk3s servercontrol plane · tainted10.40.1.10 · public IPk3s agent 110.40.1.20no public IPk3s agent 210.40.1.21no public IPIn the cluster· Traefik ingress· cert-manager· Prometheus· Alertmanager· Grafana· Loki + Fluent Bit· WireGuard pod network· your appsKey Vaultk3s join token (RBAC)Log Analyticssyslog via Azure Monitor AgentStandard Load Balancer80 / 443 → agentsNAT gatewayall outbound trafficBudget alertforecast at 80 %Storage account: Terraform stateEntra ID login · versioningSSH 22 · API 644380/443ingressoutidentitylogsplan / apply

Schritt für Schritt

  1. Pull Request

    terraform fmt und validate, tflint und ein Trivy-IaC-Scan. Dann meldet sich die Pipeline per OIDC bei Azure an und schreibt den Plan als Kommentar in den Pull Request.

  2. Prüfung

    Ein Mensch liest den Plan: Was wird erstellt, geändert oder gelöscht. In Azure hat sich noch nichts geändert.

  3. Anwenden

    Nach dem Merge wartet das Apply auf eine Freigabe der Umgebung „production“. Dann baut Terraform genau den geprüften Plan.

  4. Konfigurieren

    Ansible härtet die drei Ubuntu-Server, installiert k3s mit Verschlüsselung und Audit-Log und fügt die Plattform-Charts hinzu.

  5. Jede Nacht

    Eine Drift-Prüfung führt terraform plan aus. Weicht Azure vom Code ab, öffnet sie ein Issue.

Nachweis aus einem echten Lauf

Lauf auf dem Branch main am 2026-10-27, aus GitHub Actions. Dauer je Job:

  • fmt, validate, tflint, Trivy 23s
  • ansible-lint (production profile) 22s

Diesen Lauf öffnen (opens in a new tab)

Sicherheitskontrollen

KontrolleWas sie verhindert
NSG mit Deny als Standard + admin_cidrsSSH und Kubernetes-API offen im Internet.
Keine öffentliche IP auf den AgentsDirekte Angriffe auf die Worker-Knoten.
GitHub OIDCEin langlebiges Cloud-Secret, das aus der CI leaken kann.
Key Vault + Managed IdentityDas Cluster-Join-Token in Dateien oder in Git.
Plan-Prüfung + FreigabeEin überraschendes Löschen in Produktion.
tflint + Trivy-IaC-ScanUnsichere oder falsche Einstellungen, bevor sie Azure erreichen.
Nächtliche Drift-PrüfungManuelle Änderungen, von denen niemand weiß.
Budget-AlarmEin vergessenes Lab, das jeden Tag Geld kostet.

Selbst ausprobieren

az login && make bootstrap      # once: state storage + GitHub OIDC app
cp terraform/terraform.tfvars.example terraform/terraform.tfvars   # your IP and SSH key
make init plan apply            # VNet, NSG, NAT, load balancer, 3 VMs, Key Vault, monitoring
make configure                  # Ansible: hardening, k3s, platform charts
make kubeconfig && KUBECONFIG=./kubeconfig kubectl get nodes
make destroy                    # after the demo: everything is gone

Was ich gelernt habe

  • Ein sauberer Plan im Pull Request ist das beste Prüfwerkzeug: Man liest, was sich ändert, nicht den Code.
  • Sichere Standards gehören in den Code: Die Web-Ports bleiben zu, bis man sie bewusst öffnet.
  • Eine Plattform, die man in Minuten löschen und neu bauen kann, ist günstiger und sicherer als eine, die man nicht anzufassen wagt.
Nächste Fallstudie Sichere Delivery-Pipeline