Azure AKS Enterprise Platform Baseline

Überblick

Diese Referenzimplementierung demonstriert eine Azure Kubernetes Service (AKS) Plattform-Baseline, die auf Prinzipien des Platform Engineerings basiert.

Der Fokus liegt nicht auf der Komplexität von Anwendungen, sondern auf dem Aufbau einer sicheren, beobachtbaren und betrieblich stabilen Containerplattform unter Verwendung Azure-nativer Dienste.

Wesentliche Aspekte sind:

• Authentifizierung von Workloads ohne Secrets mittels Azure Workload Identity
• Day-1 Observability mit Managed Prometheus und Azure Managed Grafana
• Infrastrukturbereitstellung über modular strukturierte Terraform-Konfigurationen
• Automatisierte Infrastruktur- und Applikationsbereitstellung über CI/CD-Pipelines
• Richtlinienbasierte Governance mit Azure Policy für Kubernetes

Das Projekt zeigt exemplarisch, wie Plattformteams Kubernetes-Infrastruktur in Enterprise-Azure-Umgebungen bereitstellen und betreiben.

Kontext

Teams, die Kubernetes einführen, stehen häufig vor ähnlichen Herausforderungen:

• Verwaltung von Credentials und Secrets für Workloads
• Aufbau von Observability, bevor Anwendungen produktiv deployt werden
• Kontrolle der operativen Komplexität von Cluster-Tools
• Durchsetzung von Sicherheits- und Compliance-Anforderungen von Beginn an
• Strukturierung von Infrastruktur-Code für Wiederverwendbarkeit und Automatisierung

Diese Plattform-Baseline adressiert diese Herausforderungen durch Azure-native Services und Platform-Engineering-Praktiken, wobei der Schwerpunkt auf operativer Klarheit statt auf Anwendungskomplexität liegt.

Architektur

Architekturüberblick

Azure Subscription
┌───────────────────────────────────────────────┐
│ │
│ AKS Cluster │
│ • OIDC Issuer + Workload Identity │
│ • Azure CNI Networking │
│ • Application Routing (NGINX Ingress) │
│ • Secrets Store CSI Driver │
│ • Azure Policy Add-on │
│ • Container Insights │
│ │
│ Azure Monitor Workspace │
│ • Managed Prometheus Metrics │
│ • Data Collection Rules │
│ │
│ Azure Managed Grafana │
│ • Entra ID Authentifizierung │
│ • Plattform-Dashboards │
│ │
│ Azure Key Vault │
│ • Secret Storage │
│ • Workload Identity Authentifizierung │
│ │
│ Azure Container Registry │
│ • Image Storage und Pull-Berechtigungen │
│ │
└───────────────────────────────────────────────┘

Die Architektur setzt bewusst auf Managed Services in Azure, um den operativen Aufwand zu reduzieren und gleichzeitig hohe Sicherheits- und Observability-Standards zu gewährleisten.

Infrastrukturstruktur

Die Infrastruktur wird über eine modulare Terraform-Struktur bereitgestellt.

infra/terraform/
├── modules/
│ ├── aks
│ ├── networking
│ ├── monitoring
│ ├── keyvault
│ ├── acr
│ └── workload-identity
└── envs/dev

Grundlegende Designprinzipien:

• modulare Infrastrukturkomponenten
• klare Abhängigkeitsstruktur zwischen Modulen
• konsistente Namenskonventionen für Ressourcen
• Remote-Terraform-State mit Locking

Diese Struktur ermöglicht wiederverwendbare Infrastrukturmuster und unterstützt zukünftige Multi-Environment-Deployments.

Sicherheitsmodell

Workload Identity

Die Authentifizierung zwischen Kubernetes-Workloads und Azure-Diensten erfolgt über Azure Workload Identity mit OIDC Federation.

Kubernetes ServiceAccounts werden über Federated Credentials Azure Managed Identities zugeordnet.
Anwendungen können dadurch sicher auf Azure-Dienste wie Key Vault zugreifen, ohne Zugangsdaten in Pods oder Pipelines speichern zu müssen.

Dieser Ansatz ersetzt das frühere Pod Identity Modell und entspricht modernen Zero-Trust-Authentifizierungsprinzipien.

Integration von Azure Key Vault

Secrets werden über den Secrets Store CSI Driver bereitgestellt.

• Secrets werden im Azure Key Vault gespeichert
• sie werden als read-only Dateien in Pods gemountet
• die Authentifizierung erfolgt über Workload Identity

Der Key Vault verwendet Azure RBAC für die Zugriffskontrolle, wodurch klassische Access-Policy-Modelle vermieden werden.

Netzwerksicherheit

Der Cluster wird in einem dedizierten virtuellen Netzwerk betrieben.

Sicherheitsmechanismen umfassen:

• Azure CNI Networking
• Network Security Groups
• Kubernetes Network Policies
• isoliertes Subnetz für Cluster-Nodes

Private Endpoints für Key Vault und Container Registry können bei Bedarf ergänzt werden.

Observability

Die Observability-Architektur basiert vollständig auf Azure-nativen Managed Services:

• Azure Monitor Managed Service für Prometheus
• Azure Managed Grafana
• Container Insights für Logs und Clusterdiagnosen

Metriken werden gesammelt von:

• Kubernetes Nodes
• kube-state-metrics
• Application Endpoints
• Ingress Controller Metrics

Grafana-Dashboards bieten operative Einblicke in:

• Clusterzustand und Ressourcenauslastung
• Ingress-Traffic und Fehlerquoten
• Performancekennzahlen von Anwendungen

Die Dashboards folgen dem RED-Prinzip (Rate, Errors, Duration) zur Überwachung von Services.

CI/CD-Automatisierung

Die Plattform verwendet ein Two-Pipeline-Modell.

Infrastruktur-Pipeline

Verantwortlich für die Bereitstellung und Aktualisierung der Infrastruktur.

Pipeline-Stufen:

1. Terraform-Validierung
2. Terraform-Plan-Erstellung
3. Manuelle Freigabe
4. Terraform Apply

Der generierte Plan wird als Artefakt veröffentlicht, sodass Infrastrukturänderungen vor der Ausführung geprüft werden können.

Applikations-Pipeline

Verantwortlich für den Build und das Deployment von Container-Workloads.

Pipeline-Stufen umfassen:

• Build des Container-Images
• Push in das Azure Container Registry
• Kubernetes Deployment
• Rolling Updates mit Health Checks

Freigabestufen sorgen für Governance, ohne die Deployment-Geschwindigkeit zu stark zu beeinträchtigen.

Governance mit Azure Policy

Der AKS-Cluster integriert das Azure Policy Add-on mit OPA Gatekeeper.

Die Richtlinien setzen grundlegende Kubernetes-Sicherheitspraktiken durch.

Beispiele:

• Blockieren privilegierter Container
• Erzwingen von Resource Requests und Limits
• Verhindern von :latest Image-Tags
• Verpflichtende Health Probes
• Einschränkung gefährlicher Linux-Capabilities

Zu Beginn laufen Richtlinien im Audit-Modus, sodass Verstöße identifiziert werden können, bevor eine vollständige Durchsetzung erfolgt.

Verantwortlichkeiten: Plattform vs. Anwendungen

Eine klare Trennung der Verantwortlichkeiten ermöglicht skalierbaren Plattformbetrieb.

Plattformteam

Verantwortlich für:

• Infrastrukturbereitstellung mit Terraform
• AKS-Lifecycle-Management
• Konfiguration des Ingress Controllers
• Observability-Stack
• Sicherheitsrichtlinien und Policies
• CI/CD-Pipeline-Templates

Applikationsteams

Verantwortlich für:

• Kubernetes-Manifeste
• Container-Images der Anwendungen
• Applikationsspezifische Dashboards
• Namespace-Konfiguration
• Service-Routing und Ingress-Definitionen

Dieses Modell ermöglicht Self-Service-Deployments für Anwendungsteams, während die Plattformkonsistenz erhalten bleibt.

Mögliche Erweiterungen

Die Plattform kann um zusätzliche Funktionen erweitert werden:

• mehrere Umgebungen (Dev / Staging / Produktion)
• GitOps-Deploymentmodell mit Flux oder Argo CD
• privater AKS-Cluster und Private Endpoints
• Cluster-Autoscaling und Kostenoptimierung
• erweitertes Traffic-Management über Gateway API

Umfang

Dieses Projekt konzentriert sich bewusst auf Plattformarchitektur statt Anwendungskomplexität.

Die Implementierung demonstriert:

• Azure-native Kubernetes-Plattformarchitektur
• sichere Workload-Authentifizierung und Secret Management
• Infrastrukturautomatisierung mit Terraform
• Observability von Beginn an
• Kubernetes-Governance über Policies
• CI/CD-Automatisierung für Infrastruktur und Workloads

Eine minimale Demo-Anwendung dient lediglich dazu, die Plattformfunktionen zu validieren.

Letzte Aktualisierung: März 2026
Geschätzte monatliche Kosten (Dev-Umgebung): ~200 USD