AKS Platform: Service Description¶
This page describes what the AKS Platform offers, which variants exist, how changes are made and where the boundaries are. The other pages go into the details: Using the cluster, Security policy, Architecture and the pages linked from there.
Reference design, set per platform
The service is delivered by the platform team under an agreement (Operating models). Support hours, response times, contacts and fees are part of that agreement and are not in this documentation. Where a page names a default (a size, a window, a retention), it is the value of the reference configuration. Your platform can differ.
In short¶
The platform team builds and maintains AKS clusters as infrastructure as code with Terraform. Every cluster gets the same baseline: private API server, sign-in through Entra ID only, workload identity, a fixed node pool layout, maintenance windows and a security policy baseline. Workload teams deploy into namespaces of those clusters and use the cluster through groups and GitOps, not through shared credentials.
What is offered¶
| Area | Included |
|---|---|
| Cluster | One AKS cluster per environment (production and non-production), with system and user node pools, autoscaling, availability zones in production, and maintenance windows (Cluster baseline). |
| Network | A spoke with separate subnets for nodes, ingress, private endpoints and the API server. In the hub-integrated mode the spoke comes from the hub and landing zone (Networking). |
| Access | Entra ID groups for platform admins, operators, auditors, break-glass and per team. Local Kubernetes accounts are disabled (Identity and access). |
| Workload identity | A user-assigned managed identity per application and per environment, federated to a Kubernetes service account. No stored client secrets. |
| Secrets | A Key Vault with RBAC authorisation, purge protection and no public access, reached through a private endpoint (Azure variant). |
| Security policy | Azure Policy for Kubernetes, and Kyverno policies, default-deny network policies and namespace quotas from the GitOps repository (Security policy). |
| Deployment | Terraform through pipelines with one state per platform and environment (Deployment). |
| Operations | Planned upgrade windows, an optional start and stop schedule for non-production, an on-call setup in PagerDuty (Operations). |
| Load testing | A repeatable load test and alert validation for the non-production cluster (Load testing). |
Variants¶
| Variant | What it is | Status in the sources |
|---|---|---|
| Azure, standalone | The solution builds its own spoke VNet, subnets, route table and Private DNS zone. Egress goes through the AKS load balancer. | Deployed in the reference configuration for nonprod and prod. |
| Azure, hub-integrated | The cluster uses a spoke that the hub and landing zone created. Egress follows the hub (user-defined routing). Private DNS zones come from the hub. | Implemented in code and used by a nonprod-integrated environment. The design document still says "implementation pending". |
| Azure Local | AKS on Azure Local (AKS Arc). The cluster is created with the Azure CLI, Terraform manages Arc extensions, identity, policy and Key Vault. | Code and pipeline exist. In the committed configuration every layer switch is false, so what has been deployed is not visible in the sources. |
See AKS on Azure Local for the differences.
How changes are made¶
There are two kinds of change, and they use two paths.
- Azure resources (cluster, network, identities, Key Vault, Azure Policy): a change to the Terraform configuration, planned and applied by a pipeline run (Deployment). Manual changes in the Azure portal to resources that Terraform manages are drift and are reverted by the next run.
- In-cluster resources (namespaces, RBAC bindings, policies, quotas, platform services, applications): a pull request on a GitOps repository. Argo CD applies it. The Kubernetes manifests that used to live in the Terraform repository are deprecated and kept only as history.
Typical standard changes:
- onboard a team: Entra ID groups and namespaces, RBAC bindings;
- add a workload identity for an application and its role on a Key Vault;
- add a policy exception (pull request with justification, reviewed by the security team, with an expiry date);
- change node pool size or add a user node pool;
- move to a new Kubernetes minor version, non-production first.
Responsibilities¶
| Platform team | Workload team | |
|---|---|---|
| Terraform code, layers, cluster baseline, new versions | Yes | |
| Kubernetes minor upgrades and node image upgrades | Yes | Tests the application after non-production upgrades |
| Entra ID groups, group membership process, Azure role assignments | Yes | Requests, names the team leads |
| Workload identity for an application | Creates it | Requests it, uses the service account in the application |
| Namespaces, resource quotas, limit ranges, default network policies | Yes | |
| Application network policies on top of the defaults | Reviews | Writes them |
| Kyverno and Azure Policy baseline, policy exceptions | Yes (security team approves exceptions) | Requests exceptions |
| Ingress gateway, certificates, monitoring stack | Yes | |
Routes (HTTPRoute), application deployments and manifests |
Yes | |
| Container images, scanning, what the application does with secrets | Yes | |
| Alerts about the application | Yes | |
| Alerts about the platform and the on-call response | Yes | |
| Break-glass access and its review | Yes |
The generic split is described in Responsibilities. Contract details such as hours and response times are in your agreement.
Boundaries¶
| Not part of the service | Why |
|---|---|
| Persistent volume backup | Not part of the cluster baseline. The design suggests Azure Backup for AKS or Velero, planned per workload. |
| Application workloads and their data | They belong to the workload team. |
| A web application firewall | Not included in the initial design. |
| Defender for Containers | Disabled in the reference configuration. It can be switched on, see Security policy. |
| A firewall in the standalone mode | The design describes egress through Azure Firewall. The Terraform code of the standalone mode does not deploy one. In the hub-integrated mode egress follows the hub (Networking). |
| Azure Local hardware, Arc Resource Bridge, custom location, logical network | Infrastructure prerequisites of the Azure Local variant, with their own lifecycle (Prerequisites). |
| Changes made by hand in the cluster | In production the design allows GitOps changes only. Direct changes are reverted by Argo CD. |