Skip to main content
Gå til innhold

Multi-tenancy principles

Platon PaaS is a multi-tenant Kubernetes cluster: many teams share the same control plane and worker nodes, and each GitLab project only has access to its own namespaces (one for prod and one for dev). These principles explain how we keep that shared cluster secure and operable for everyone.

Why multi-tenancy needs strict boundaries​

In a shared cluster, one tenant's mistake or compromise must not be able to affect another tenant. We enforce this through:

  • Namespace isolation — a project's service account can only act within its own namespaces.
  • Restricted RBAC — tenants cannot grant themselves cluster-wide permissions or create/modify RBAC (Role, RoleBinding, etc.). Self-granted RBAC is a privilege-escalation path and is blocked by design.
  • Restricted cluster-level objects — resources that affect cluster operations (e.g. PodDisruptionBudget, which can stall node drains) are not tenant-managed.

The single most important security property of a multi-tenant cluster is that the platform team can answer, at any time: "what access exists, and why?" Every exception we cannot enumerate erodes that property.

No custom "hacks"​

We regularly get requests to manually apply custom RBAC or other privileged objects that a tenant's CI cannot create on its own. We almost always decline these — not because the access is necessarily dangerous, but because bespoke, manually-applied configuration is ungovernable:

  1. It lives outside the reconciliation loop. Anything applied by hand is not in GitOps — nothing detects drift, recreates it, or tracks it. It is invisible maintenance that grows with every tenant.
  2. Ownership is split-brain. The platform owns the object, but the tenant owns the reason it exists. When an API is deprecated or a name changes, the side with the signal cannot fix it and the side that can fix it has no signal.
  3. It does not scale and sets precedent. Exceptions are easy to grant and nearly impossible to revoke. Each one becomes the precedent for the next, and eventually no one can reason about cluster RBAC as a whole.

What we do support​

The platform contract is intentionally small and uniform. Every capability is either a supported, platform-owned feature — versioned, documented, and applied by automation — or it does not exist. We do not maintain a middle tier of "bespoke but blessed" manual artifacts, because that is precisely where governability breaks down.

If you have a recurring need that the standard contract does not cover:

  • Prefer a solution that needs no extra access. Many needs have a tenant-side alternative — for example, spreading pods for resilience with topologySpreadConstraints and pod anti-affinity instead of a PodDisruptionBudget, or DNS-based service discovery instead of reading the Kubernetes API.
  • If the need is real and shared by multiple teams, contact the Platon team. If it is a common pattern we can build it as a supported, platform-owned capability — so it benefits everyone and stays maintainable, rather than living as a one-off in your namespace.