AKS-platform: identiteit en toegang¶

Deze pagina beschrijft wie en wat toegang heeft tot het platform en via welk mechanisme: toegang voor mensen, Kubernetes- en Azure- autorisatie, workload identity, CI/CD-identiteiten, de Key Vault en break-glass-toegang. Het principe is geen statische credentials: alles gebruikt Entra ID, managed identities of federated identities.

Referentieontwerp, jouw deployment kan afwijken

Groeps- en identiteitsnamen zijn de patronen van de referentieconfiguratie. Voor het MCP-brede model zie Identiteits- en toegangsmodel en Toegang, groepen en PIM.

Principes¶

Mensen krijgen rechten alleen via Entra ID-groepen, nooit als individuele toewijzing.
Productie en niet-productie hebben aparte groepen. Toegang voor ontwikkelaars in productie is standaard alleen lezen.
Functiescheiding: infrastructuurdeployment, image build en GitOps-updates zijn aparte identiteiten.
Toegang tot Azure-resources wordt met Terraform beheerd. Autorisatie in het cluster wordt beheerd als YAML in de GitOps-repository en gewijzigd via pull request.
Lokale Kubernetes-accounts zijn uitgeschakeld. Aanmelden gaat via Entra ID met MFA.

Identiteitstypen¶

Identiteit	Authenticeert via	Geautoriseerd bij	Mechanisme
Menselijke gebruikers	Entra ID (MFA)	Kubernetes API	Kubernetes RBAC gebonden aan Entra ID-groepen
AKS-clusteridentiteit	User-assigned managed identity	Azure Resource Manager	Azure RBAC (Cluster baseline)
Workload pods	Service account naar federated credential	Azure-services	Workload identity en Azure RBAC
CI/CD-pipelines	GitHub OIDC federated credential	Azure en Kubernetes	Azure RBAC en cluster roles
Break-glass	Entra ID met PIM, MFA	Hele cluster	`cluster-admin`-binding

Groepen¶

Groepsnamen volgen grp-aks-<scope>-<role>[-<team>][-<env>]. De Terraform identity layer maakt de groepen aan die in de map entra_groups van de configuratie staan, plus de break-glass-groep.

Groep	Rol	Cluster
`grp-aks-platform-admins`	Platformbeheerders, `cluster-admin`	Beide
`grp-aks-platform-operators`	Ingress, monitoring en certificaten beheren	Beide
`grp-aks-auditors`	Alleen lezen, clusterbreed	Beide
`grp-aks-breakglass`	Noodtoegang	Beide
`grp-aks-<team>-leads-<env>`	Teamleads	Per omgeving
`grp-aks-<team>-devs-<env>`	Ontwikkelaars van het team	Per omgeving

De platform admin-groep en de break-glass-groep worden aan het cluster meegegeven als zijn Entra ID-admingroepen. De hub-integrated configuratie gebruikt een eigen groepenset met een -integrated-suffix, zodat de twee clusters geen groepen delen.

Groepslidmaatschap en PIM-activatie worden niet in Terraform geconfigureerd (beperkte providerondersteuning). Het platformteam of het identiteitsteam van de klant beheert ze.

Kubernetes-autorisatie¶

Kubernetes RBAC is native (roles en bindings als manifests), uitgerold door GitOps. Azure RBAC voor Kubernetes-autorisatie staat aan op het cluster, en de pipeline-identiteiten gebruiken de Azure-rol Azure Kubernetes Service RBAC Admin.

Rol	Soort	Doel
`cluster-admin`	Ingebouwd	Platformbeheerders en break-glass
`platform-operator`	ClusterRole	Platformnamespaces beheren: workloads, services, secrets, gateway- en certificaatresources, monitoringresources, network policies. Nodes en events bekijken
`auditor`	ClusterRole	Alleen lezen in het hele cluster
`namespace-admin`	Role	Volledig beheer van een teamnamespace
`namespace-developer`	Role	Applicaties deployen en debuggen, inclusief `exec` en routes
`namespace-viewer`	Role	Lezen en pod logs

Toegangsmatrix¶

Rol	dev	test	accp	prod
Developer	`namespace-developer`	`namespace-developer`	`namespace-viewer`	`namespace-viewer`
Teamlead	`namespace-admin`	`namespace-admin`	`namespace-admin`	`namespace-developer`
Platform operator	Bekijken, clusterbreed	Bekijken, clusterbreed	Bekijken, clusterbreed	Bekijken, clusterbreed
Auditor	Bekijken, clusterbreed	Bekijken, clusterbreed	Bekijken, clusterbreed	Bekijken, clusterbreed
Platformbeheerder	`cluster-admin`	`cluster-admin`	`cluster-admin`	`cluster-admin`

Namespaces heten <team>-<env> (bijvoorbeeld team-a-dev). Het netwerkontwerpdocument toont <env>-<team>; de RBAC- manifests, de identiteitsconfiguratie en de load test gebruiken allemaal <team>-<env>.

Beschermde platformnamespaces¶

kube-system, gateway-system, cert-manager, monitoring, logging, argocd, policy-system en vergelijkbare platform- namespaces zijn beschermd: geen role bindings voor applicatieteams, platformlabels, admission policies die bindings door niet-platformsubjects weigeren, en alleen GitOps-wijzigingen in productie. Labels gebruiken een configureerbaar domein (<labelDomain>/type, <labelDomain>/protected, <labelDomain>/team, <labelDomain>/environment), per klant ingesteld in de GitOps-repository.

Break-glass-toegang¶

Aspect	Ontwerp
Groep	`grp-aks-breakglass`, gebonden aan `cluster-admin`
Leden	Maximaal twee of drie senior platform engineers
Activatie	PIM, tijdelijk, maximaal 4 uur, MFA en motivatie vereist
Monitoring	Alert op PIM-activatie en op Kubernetes-auditactiviteit van de groep
Review	Kwartaalreview van het lidmaatschap

Workload identity¶

Elke applicatie krijgt een eigen user-assigned managed identity per omgeving, gefedereerd met één Kubernetes service account. Identiteiten worden niet gedeeld tussen applicaties, teams of omgevingen.

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)

Wat Terraform aanmaakt voor elk item van de map workload_identities:

Resource	Naampatroon	Opmerkingen
Managed identity	`mi-<map key>-<env>`	In `rg-<env>-identity`
Federated credential	`fc-<env>-<namespace>-<service account>`	Issuer is de OIDC issuer van het cluster, subject is `system:serviceaccount:<namespace>:<service account>`
Roltoewijzingen	Zoals per item vermeld, bijvoorbeeld Key Vault Secrets User op de Key Vault	Least privilege per applicatie

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>"
      }
    ]
  }
}

Twee stappen op een nieuw cluster

De workload identity-module draait alleen als oidc_issuer_url is ingesteld, en de issuer-URL bestaat pas nadat het cluster is aangemaakt. Deploy op een nieuwe omgeving eerst het cluster, kopieer de issuer-URL naar de configuratie en pas daarna opnieuw toe. Op Azure Local print het bootstrapscript de URL.

CI/CD-identiteiten¶

Elk item in cicd_identities wordt een user-assigned managed identity mi-cicd-<name> met een federated credential fc-github-<name> voor de GitHub OIDC issuer. Het subject noemt een repository en een GitHub Environment, dus alleen runs van die environment kunnen de identiteit gebruiken. Er bestaan geen client secrets.

Identiteit	Verantwoordelijkheid	Mag niet
`infra-deploy`	Infrastructuur deployen	Images pushen, GitOps wijzigen, apps deployen
`image-build`	Images bouwen en pushen	Infrastructuur deployen, Key Vault lezen, het cluster wijzigen
`gitops-update` (ontwerp)	GitOps-manifests bijwerken	Infrastructuur deployen, images pushen, Azure benaderen

Toegang van pipelines tot het cluster (bijvoorbeeld voor de load test) wordt gegeven als Azure-roltoewijzing op het cluster (cicd_aks_role_assignments), met opzet buiten de identity-module gehouden. Zie Deployment.

Azure-roltoewijzingen voor mensen¶

Het ontwerp geeft de platformbeheerders Azure Kubernetes Service Cluster Admin Role op het cluster, operators en auditors Cluster User Role, en de auditors Reader. In de code worden deze aangeleverd via de map identity_role_assignments, die in de referentiebestanden leeg of uitgecommentarieerd is. Vul hem per omgeving in.

Key Vault¶

Instelling	Waarde
Autorisatie	Azure RBAC, geen access policies
Netwerk	Publieke netwerktoegang uitgeschakeld, default ACL-actie deny, alleen private endpoint (Azure-variant)
Bescherming	Purge protection aan, soft delete 90 dagen (configureerbaar)
SKU	`standard` (kan `premium` zijn voor HSM-backed keys)
Naam	Wereldwijd uniek, patroon `kv-<purpose>-<env>`, ingesteld in de configuratie
Logging	`AuditEvent` en policy-evaluatielogs naar Log Analytics als een workspace is ingesteld

Workloads krijgen alleen Key Vault Secrets User. Het ontwerp kiest voor toegang via de SDK met workload identity boven de CSI driver: elke applicatie gebruikt zijn eigen identiteit, er worden geen secrets naar Kubernetes Secret-objecten gekopieerd en de applicatie bepaalt de caching. De CSI driver add-on staat in de configuratiebestanden van de referentie toch aan (zie Cluster baseline). Regels voor Kubernetes Secrets (geen plaintext secrets in Git, liever Key Vault, eigenaarslabels) staan in Security policy.

Audit¶

Het ontwerp noemt gebeurtenissen om te monitoren en naar Log Analytics te sturen: wijzigingen in Azure-roltoewijzingen, wijzigingen in managed identities en federated credentials, break-glass-activatie, wijzigingen in cluster-admin-bindings, mislukte Kubernetes-aanmeldingen en het aanmaken van service principal- secrets. Diagnostic settings staan in de referentieconfiguratie standaard uit, dus hiervoor zijn vóór go-live een Log Analytics workspace en de bijbehorende switches nodig.