AKS-Plattform: Identität und Zugriff¶

Diese Seite beschreibt, wer und was auf die Plattform zugreifen kann und über welchen Mechanismus: Zugriff von Menschen, Kubernetes- und Azure- Autorisierung, workload identity, CI/CD-Identitäten, der Key Vault und Break-glass-Zugriff. Das Prinzip lautet: keine statischen Zugangsdaten. Alles nutzt Entra ID, managed identities oder federated identities.

Referenzdesign, dein Deployment kann abweichen

Gruppen- und Identitätsnamen sind die Muster der Referenzkonfiguration. Das MCP-weite Modell steht unter Identitäts- und Zugriffsmodell und Zugriff, Gruppen und PIM.

Prinzipien¶

Menschen bekommen Berechtigungen nur über Entra-ID-Gruppen, nie als Einzelzuweisung.
Production und Non-production haben getrennte Gruppen. Der Zugriff von Entwicklern auf Production ist standardmäßig nur lesend.
Funktionstrennung: Infrastruktur-Deployment, Image-Build und GitOps-Updates sind getrennte Identitäten.
Der Zugriff auf Azure-Ressourcen wird mit Terraform verwaltet. Die Autorisierung im Cluster wird als YAML im GitOps-Repository verwaltet und per pull request geändert.
Lokale Kubernetes-Konten sind deaktiviert. Die Anmeldung läuft über Entra ID mit MFA.

Identitätstypen¶

Identität	Authentifiziert über	Autorisiert bei	Mechanismus
Menschen	Entra ID (MFA)	Kubernetes API	Kubernetes RBAC, gebunden an Entra-ID-Gruppen
AKS-Cluster-Identität	User-assigned managed identity	Azure Resource Manager	Azure RBAC (Cluster baseline)
Workload-Pods	Service Account zu federated credential	Azure-Services	Workload identity und Azure RBAC
CI/CD-pipelines	GitHub OIDC federated credential	Azure und Kubernetes	Azure RBAC und Cluster Roles
Break-glass	Entra ID mit PIM, MFA	Ganzer Cluster	Binding an `cluster-admin`

Gruppen¶

Gruppennamen folgen grp-aks-<scope>-<role>[-<team>][-<env>]. Der Terraform Identity layer erstellt die Gruppen, die in der Map entra_groups der Konfiguration stehen, plus die Break-glass-Gruppe.

Gruppe	Rolle	Cluster
`grp-aks-platform-admins`	Plattform-Administratoren, `cluster-admin`	Beide
`grp-aks-platform-operators`	Ingress, Monitoring und Zertifikate verwalten	Beide
`grp-aks-auditors`	Nur lesend, clusterweit	Beide
`grp-aks-breakglass`	Notfallzugriff	Beide
`grp-aks-<team>-leads-<env>`	Team Leads	Pro Umgebung
`grp-aks-<team>-devs-<env>`	Entwickler des Teams	Pro Umgebung

Die Gruppe der Plattform-Admins und die Break-glass-Gruppe werden dem Cluster als seine Entra-ID-Admin-Gruppen übergeben. Die hub-integrated Konfiguration nutzt einen eigenen Gruppensatz mit dem Suffix -integrated, damit sich die beiden Cluster keine Gruppen teilen.

Gruppenmitgliedschaft und PIM-Aktivierung werden nicht in Terraform konfiguriert (begrenzte Provider-Unterstützung). Das Plattform-Team oder das Identity-Team des Kunden verwaltet sie.

Kubernetes-Autorisierung¶

Kubernetes RBAC ist nativ (Roles und Bindings als Manifeste) und wird per GitOps deployt. Azure RBAC für die Kubernetes-Autorisierung ist am Cluster eingeschaltet, und die pipeline-Identitäten nutzen die Azure-Rolle Azure Kubernetes Service RBAC Admin.

Rolle	Art	Zweck
`cluster-admin`	Eingebaut	Plattform-Admins und Break-glass
`platform-operator`	ClusterRole	Plattform-namespaces verwalten: Workloads, Services, Secrets, Gateway- und Zertifikatsressourcen, Monitoring-Ressourcen, network policies. Nodes und Events ansehen
`auditor`	ClusterRole	Nur lesend im ganzen Cluster
`namespace-admin`	Role	Volle Verwaltung eines Team-namespace
`namespace-developer`	Role	Anwendungen deployen und debuggen, einschließlich `exec` und Routes
`namespace-viewer`	Role	Lesen und Pod-Logs

Zugriffsmatrix¶

Rolle	dev	test	accp	prod
Entwickler	`namespace-developer`	`namespace-developer`	`namespace-viewer`	`namespace-viewer`
Team Lead	`namespace-admin`	`namespace-admin`	`namespace-admin`	`namespace-developer`
Plattform-Operator	Ansehen, clusterweit	Ansehen, clusterweit	Ansehen, clusterweit	Ansehen, clusterweit
Auditor	Ansehen, clusterweit	Ansehen, clusterweit	Ansehen, clusterweit	Ansehen, clusterweit
Plattform-Admin	`cluster-admin`	`cluster-admin`	`cluster-admin`	`cluster-admin`

Namespaces heißen <team>-<env> (zum Beispiel team-a-dev). Das Networking-Designdokument zeigt <env>-<team>; die RBAC- Manifeste, die Identitätskonfiguration und der Load Test nutzen alle <team>-<env>.

Geschützte Plattform-namespaces¶

kube-system, gateway-system, cert-manager, monitoring, logging, argocd, policy-system und ähnliche Plattform- namespaces sind geschützt: keine Role Bindings für Anwendungsteams, Plattform-Labels, Admission Policies, die Bindings durch Nicht-Plattform-Subjects ablehnen, und in Production nur Änderungen per GitOps. Labels nutzen eine konfigurierbare Domain (<labelDomain>/type, <labelDomain>/protected, <labelDomain>/team, <labelDomain>/environment), die pro Kunde im GitOps-Repository gesetzt wird.

Break-glass-Zugriff¶

Aspekt	Design
Gruppe	`grp-aks-breakglass`, gebunden an `cluster-admin`
Mitglieder	Höchstens zwei oder drei Senior-Plattform-Engineers
Aktivierung	PIM, zeitlich begrenzt, höchstens 4 Stunden, MFA und Begründung erforderlich
Monitoring	Alert bei PIM-Aktivierung und bei Kubernetes-Audit-Aktivität der Gruppe
Review	Vierteljährliches Review der Mitgliedschaft

Workload identity¶

Jede Anwendung bekommt eine eigene user-assigned managed identity pro Umgebung, federated mit einem Kubernetes Service Account. Identitäten werden nicht zwischen Anwendungen, Teams oder Umgebungen geteilt.

sequenceDiagram
    participant Pod
    participant SA as Service account
    participant OIDC as AKS OIDC issuer
    participant Entra as Entra ID
    participant KV as Key Vault
    Pod->>SA: Runs as the annotated service account
    SA->>OIDC: Projected token
    OIDC->>Entra: Token exchange (federated credential)
    Entra-->>Pod: Azure token of the managed identity
    Pod->>KV: Read secret (Azure RBAC)

Was Terraform für jeden Eintrag der Map workload_identities erstellt:

Ressource	Namensmuster	Hinweise
Managed identity	`mi-<map key>-<env>`	In `rg-<env>-identity`
Federated credential	`fc-<env>-<namespace>-<service account>`	Issuer ist der OIDC issuer des Clusters, Subject ist `system:serviceaccount:<namespace>:<service account>`
Rollenzuweisungen	Wie pro Eintrag aufgelistet, zum Beispiel Key Vault Secrets User auf dem Key Vault	Least Privilege pro Anwendung

workload_identities = {
  "orders-api-prod" = {
    namespace            = "team-a-prod"
    service_account_name = "orders-api"
    roles = [
      {
        role_definition_name = "Key Vault Secrets User"
        scope                = "<key-vault-resource-id>"
      }
    ]
  }
}

Zwei Schritte bei einem neuen Cluster

Das module für workload identity läuft nur, wenn oidc_issuer_url gesetzt ist, und die Issuer-URL existiert erst, nachdem der Cluster erstellt wurde. Deploye in einer neuen Umgebung zuerst den Cluster, kopiere die Issuer-URL in die Konfiguration und wende dann erneut an. Auf Azure Local gibt das Bootstrap-Skript die URL aus.

CI/CD-Identitäten¶

Jeder Eintrag in cicd_identities wird zu einer user-assigned managed identity mi-cicd-<name> mit einer federated credential fc-github-<name> für den GitHub-OIDC-Issuer. Das Subject benennt ein Repository und ein GitHub Environment, sodass nur Läufe dieses Environments die Identität nutzen können. Es gibt keine Client Secrets.

Identität	Verantwortung	Darf nicht
`infra-deploy`	Infrastruktur deployen	Images pushen, GitOps ändern, Apps deployen
`image-build`	Images bauen und pushen	Infrastruktur deployen, Key Vault lesen, den Cluster ändern
`gitops-update` (Design)	GitOps-Manifeste aktualisieren	Infrastruktur deployen, Images pushen, auf Azure zugreifen

Der pipeline-Zugriff auf den Cluster (zum Beispiel für den Load Test) wird als Azure-Rollenzuweisung auf dem Cluster vergeben (cicd_aks_role_assignments), bewusst außerhalb des Identity modules gehalten. Siehe Deployment.

Azure-Rollenzuweisungen für Personen¶

Das Design gibt den Plattform-Admins die Rolle Azure Kubernetes Service Cluster Admin Role auf dem Cluster, Operatoren und Auditoren die Cluster User Role und den Auditoren Reader. Im Code werden sie über die Map identity_role_assignments geliefert, die in den Referenzdateien leer oder auskommentiert ist. Fülle sie pro Umgebung aus.

Key Vault¶

Einstellung	Wert
Autorisierung	Azure RBAC, keine Access Policies
Netzwerk	Public network access deaktiviert, ACL-Default-Aktion deny, nur private endpoint (Azure-Variante)
Schutz	Purge protection an, Soft Delete 90 Tage (konfigurierbar)
SKU	`standard` (kann `premium` sein für HSM-gestützte Schlüssel)
Name	Global eindeutig, Muster `kv-<purpose>-<env>`, in der Konfiguration gesetzt
Logging	`AuditEvent` und Policy-Auswertungs-Logs nach Log Analytics, wenn ein workspace gesetzt ist

Workloads bekommen nur Key Vault Secrets User. Das Design entscheidet sich für SDK-basierten Zugriff mit workload identity statt für den CSI driver: Jede Anwendung nutzt ihre eigene Identität, keine Secrets werden in Kubernetes-Secret-Objekte kopiert, und die Anwendung steuert das Caching. Das CSI-driver-Add-on ist trotzdem in den Referenzkonfigurationsdateien eingeschaltet (siehe Cluster baseline). Regeln für Kubernetes Secrets (keine Klartext-Secrets in Git, Key Vault bevorzugen, Owner-Labels) stehen unter Security policy.

Audit¶

Das Design listet Ereignisse, die zu überwachen und an Log Analytics zu senden sind: Änderungen an Azure-Rollenzuweisungen, Änderungen an managed identities und federated credentials, Break-glass-Aktivierung, Änderungen an cluster-admin-Bindings, fehlgeschlagene Kubernetes-Anmeldungen und das Erstellen von Service-Principal- Secrets. Diagnoseeinstellungen sind in der Referenzkonfiguration standardmäßig aus, deshalb brauchen diese Ereignisse vor go-live einen Log Analytics workspace und die passenden Schalter.