Zum Inhalt

AKS-Plattform: Entscheidungen

Diese Seite fasst die Designentscheidungen der Lösung zusammen. Jede Zeile nennt die Entscheidung, den Grund und wo sie sichtbar wird. Die Quellen halten die meisten als während des Designs bestätigt fest. Wo der Code von der Entscheidung abweicht, steht das in der letzten Spalte.

Cluster und Netzwerk

# Entscheidung Grund Stand im Code
1 Zwei Cluster: Production und ein Non-production-Cluster mit einem namespace pro Umgebung Blast Radius, unabhängige Upgrades, unterschiedliche Zugriffsregeln, Compliance, Netzwerktrennung Umgesetzt
2 Zwei spokes, kein Peering dazwischen Starke Netzwerkisolation Umgesetzt. Ein dritter, hub-integrated Cluster existiert für Non-production
3 Azure CNI im Overlay-Modus Vermeidet IP-Erschöpfung im Node-Subnet, einfache Subnet-Planung, Pod-Bereiche dürfen sich zwischen Clustern überschneiden Umgesetzt
4 Calico als Network-Policy-Engine Ausgereift, breite Policy-Unterstützung. Das Kapitel zur Cluster baseline sagt noch Azure Network Policy Calico im Code
5 Privater API-Server mit VNet-Integration Kein öffentlicher Endpunkt, keine Liste autorisierter IPs nötig Umgesetzt
6 Lokale Konten deaktiviert, Entra ID mit Azure RBAC Eine Identitätsquelle, MFA, keine gemeinsamen Admin-Zugangsdaten Umgesetzt
7 Egress über Azure Firewall erzwungen, mit NAT Gateway im Firewall-Subnet Inspektion, Logging und skalierbares SNAT Vom Azure Root nicht deployt. Standalone nutzt den Load Balancer. Hub-integrated nutzt User-Defined Routing
8 Gateway API für Ingress, die Plattform besitzt das Gateway, Teams besitzen Routes Kein Lock-in auf einen Controller Manifeste im GitOps-Repository
9 Private endpoints für alle PaaS, zentral im Besitz des Plattform-Teams Einheitliche Governance Nur Key Vault
10 Keine Web Application Firewall im ersten Deployment Das erste Deployment einfach halten Nicht vorhanden
11 Nur Region westeurope, daher keine Region in Ressourcennamen Einzelne Region Umgesetzt
12 Hub-integrated-Modus als zweiter Networking-Modus mit demselben Output-Vertrag Die landing zone nutzen, ohne die layers darüber zu ändern Umgesetzt. Das Designdokument sagt noch „implementation pending“

Cluster-Betrieb

# Entscheidung Grund Stand im Code
13 Im Normalbetrieb dieselbe Kubernetes-Minor-Version, Non-production zuerst Vor Production validieren Prozess
14 Upgrade-Channel für Production none, für Non-production patch Bewusste Änderungen in Production, aktuelles Non-production Umgesetzt
15 System Pool mit CriticalAddonsOnly, User Pool general Plattform von Workloads trennen Umgesetzt
16 Production über drei Zonen, Non-production kleiner Verfügbarkeit gegenüber Kosten Non-production ist im Code kleiner als im Design
17 Azure Monitor, Image Cleaner, Managed Prometheus und Diagnose standardmäßig aus Kosten. Diagnose Pflicht vor Production-go-live In den Referenzdateien aus
18 Defender for Containers deaktiviert Anfangs nicht aktiviert Schalter vorhanden, aus
19 Der Cluster ist wegwerfbar: Neuaufbau mit Terraform und Wiederherstellung mit GitOps Einfachheit Backup von Persistent Volumes nicht abgedeckt
20 Ein Terraform Root und state pro Plattform und Umgebung, eine Konfigurationsdatei pro Umgebung Isolierter Blast Radius, einfaches Deployment Umgesetzt

Identität und Secrets

# Entscheidung Grund Stand im Code
21 Kubernetes-natives RBAC per GitOps deployt, Azure RBAC für Azure-Ressourcen GitOps-kompatibel, per pull request geprüft Umgesetzt, Azure RBAC for Kubernetes ist ebenfalls eingeschaltet
22 Gruppenbenennung grp-aks-<scope>-<role>[-<team>][-<env>] Vorhersagbar Umgesetzt
23 Entwickler in Production nur lesend, Acceptance eingeschränkt Least Privilege In der Zugriffsmatrix
24 Eine workload identity pro Anwendung und Umgebung Keine geteilten Berechtigungen Umgesetzt
25 GitHub Actions mit federated identity für CI/CD, getrennte Identitäten pro Aufgabe Keine Secrets, Funktionstrennung Umgesetzt
26 Break-glass über PIM, zeitlich begrenzt, überwacht Notfallzugriff mit Nachweis PIM wird manuell konfiguriert
27 Gruppen und Rollenzuweisungen im Besitz des Plattform-Teams in Terraform Ein Owner Umgesetzt
28 Key Vault mit RBAC, nur private endpoint, purge protection. Anwendungen lesen ihn mit dem SDK, kein CSI driver Scoping pro Anwendung, keine Secrets in etcd Das CSI-Add-on ist in den Referenzdateien eingeschaltet
29 Zertifikate in Key Vault, mit Key-Vault-Rotation, statt cert-manager Kein zusätzlicher Controller Nicht verifiziert, cert-manager wird im Design auch als Plattform-namespace genannt

Security policy

# Entscheidung Grund Stand im Code
30 Eingebaute Azure-Policy-Initiativen ab Tag eins, Kyverno, wenn bereit Baseline ohne neuen Controller, danach reichhaltigere Regeln Azure-Policy-Zuweisungen mit Audit und Deny wie in Security policy aufgelistet
31 Kyverno statt OPA Gatekeeper YAML, Mutation und Generierung in einem Tool, Policy Reports Policies vorhanden, in den Manifesten alle auf Audit
32 Policy-Lebenszyklus: Audit, dann Enforce in Non-production nach 7 Tagen, dann Production nach 14 Tagen Keine Überraschungen in Production Prozess
33 Default-deny network policy in jedem Anwendungs-namespace Laterale Bewegung Manifeste im GitOps-Repository
34 Zeitlich begrenzte Policy-Ausnahmen, höchstens 90 Tage, mit Genehmigung der Security Keine dauerhaften Lücken Prozess
35 Manifeste im Cluster wandern als Helm Charts mit konfigurierbarer Label-Domain in ein GitOps-Repository Labels pro Kunde, Umgebungsunterschiede als Werte Die Kopien im Terraform-Repository sind deprecated

Azure Local

# Entscheidung Grund Stand im Code
36 Den Cluster mit der Azure CLI erstellen, nicht mit Terraform Die Cluster-Erstellung mit OIDC und workload identity sowie MetalLB braucht den Azure-CLI-Ablauf Im Bootstrap-Skript umgesetzt
37 Arc-Extensions statt AKS-Add-ons: Argo CD, Azure Policy, Arc Networking Add-ons gibt es auf Azure Local nicht Umgesetzt
38 MetalLB mit ARP, BGP oder Both Load Balancing On-Premises Umgesetzt
39 Die gemeinsamen modules für Identität und Key Vault wiederverwenden Dasselbe Modell auf beiden Varianten Umgesetzt