0. Requirements
0.2 Requirements
The requirements of the platform, owned by humans (how we work): a change to a requirement needs a human’s approval. The acceptance column names the acceptance criteria that prove each requirement; the requirement and isolation tests are tagged with the requirement number they cover. How the design meets each requirement is design section 1.2.
| # | Requirement | Acceptance |
|---|---|---|
| R1 | Internal and external workloads isolated – at subscription and cluster level (security, 2026-10-14) | Isolation tests: one exposure per cluster and subscription |
| R2 | Workloads of different countries isolated – node pool and network are enough | Isolation tests: every flow between zones blocked |
| R3 | Isolation = Key Vault + network + node pool per type | Isolation tests: another zone’s pods, nodes and Key Vault blocked; every zone complete |
| R4 | Only connectivity mandatory for Kubernetes allowed between zones | Isolation tests: every flow between zones blocked and logged by the Firewall |
| R5 | Countries can be added online | Isolation tests: every zone complete; adding a country in upgrades and changes |
| R6 | Azure CNI powered by Cilium in every cluster | Design review |
| R7 | Control plane in a dedicated network | Isolation tests: the API server only from the management VNet; local admin and SSH refused |
| R8 | Cost-optimised compute: applications choose amd64 or arm64 and on-demand or spot nodes, the platform supports all of them | Performance: scale-out with arm64 and spot, spot eviction |
| R9 | Workload identities wherever possible, secrets only when needed | Isolation tests: no local auth found by Resource Graph |
| R10 | Key Vault multi-tenancy with Azure RBAC + ABAC | Isolation tests: another application’s secret refused by ABAC |
| R11 | Applications never read Key Vault directly; External Secrets Operator is mandatory for them | Isolation tests: an application that reads Key Vault itself is refused |
| R12 | Certificates distributed through Key Vault, shared by all clusters | Isolation tests: the certificate from the vault to the listener; renewal in upgrades and changes |
| R13 | Applications isolated in namespaces + network policies | Isolation tests: namespace groups and roles |
| R14 | Every workload’s owner and cost are known | Forbidden manifests in the isolation tests; cost in operations |
| R15 | One policy engine | Isolation tests: every forbidden manifest denied by admission |
| R16 | Applications and how they are deployed do not change between clouds (portability of the application contract) | Isolation tests: application repositories scanned for cloud-specific objects |
| R17 | Two cluster types: stateless and stateful | Design review |
| R18 | Stateful cluster is the last option | Design review |
| R19 | Stateful cluster exists at most once per exposure (R1), in the backend network with the Azure PaaS services, no Internet egress and no public endpoints; the only outbound destinations outside Private Link are allow-listed Microsoft control-plane endpoints that have no Private Link (Entra ID for workload identity, the Azure Policy add-on) | Isolation tests: no Internet destination from the stateful cluster but the documented exceptions |
| R20 | Stateful cluster spread over availability zones and running AKS LTS | High availability: AZ outage (stateful cluster, if built) |
| R21 | Stateful cluster: VNet-integrated CNI, no Gateway API implementation (and no Ingress), applications handle TLS | Design review |
| R22 | Stateless clusters: pod subnet CNI, no service mesh / mTLS / application TLS, TLS-only Gateway API (no Kubernetes Ingress); from outside its namespace an application is reached only as HTTPS on 443 through the zone’s gateway, inside its namespace it uses any protocol | CIS benchmark: TLS on every gateway listener; forbidden manifests in the isolation tests |
| R23 | Stateless: separate cluster per availability zone (at least two), ≥ 2 copies of every serving application, scaled on load; workloads that serve no request (jobs, scheduled jobs, queue consumers) are allowed with the copies their work needs, and work that must not repeat runs once per environment | Isolation tests: the cell’s settings; performance and high availability |
| R24 | Every long-running workload has health probes, and every application published through a gateway a health endpoint the platform probes; a finite job reports its result by its exit status | Forbidden manifests in the isolation tests; failover in high availability |
| R25 | dev, acc and prd environments kept in sync | Isolation tests: every cell in sync with Git and its IaC; rebuild |
| R26 | Fully automated zero-downtime upgrades of applications and clusters | Zero-downtime upgrades and changes |
| R27 | Update policy: stateful cluster only when absolutely necessary, stateless clusters at two speeds | Zero-downtime upgrades and changes: minor and node image upgrades |
| R28 | Data at rest encrypted with customer-managed keys: own key for each control plane and each node pool, stored in the platform Key Vault | CIS benchmark: KMS; design review |
| R29 | Traffic exiting the cluster is allowed only to named destinations (FQDNs) | Isolation tests: egress to an unnamed FQDN or an IP address denied |
| R30 | Day 2 operations driven by AI agents, also in prd, but only through GitOps / IaC pull requests within human-defined guardrails | Upgrades and changes: an agent change through every risk tier and the kill switch |
| R31 | Observability, including tracing, with Grafana Cloud; anyone allowed to connect to it may see all data | Operations: telemetry and no secrets in it |
| R32 | Protect against losing the region with immutable backups in another region; back up only persistent data, not whole clusters | Rebuild, backup and recovery |
| R33 | The platform’s rules are non-negotiable and the same for every application: its patch timetable binds every application (base images are rebuilt and promoted on the platform’s schedule, in acc and prd on automated tests alone), automated tests are the only gate of a release, and an application that cannot meet the rules is not onboarded or carries an exception with an expiry date | Zero-downtime upgrades and changes: a base image patch to prd without a human; Isolation tests: an image past its deadline refused |
| R34 | Every team can test a change before it reaches dev: a preview environment per pull request and a longer-running sandbox per team, inside dev and under the same guardrails as dev | Isolation tests: a preview reaches exactly what its application reaches and is removed with its pull request |