Gnu Group Learning AcademyGnu Group ↗
Platform Engineering Fundamentals · Module 10 of 12

Multi-tenancy, identity, quotas and cost governance

Design shared-platform boundaries using least privilege, tenancy scope, quotas, ownership and cost signals so self-service scales without turning the platform into an uncontrolled shared admin plane.

Learning objectives

By the end of this module, you should be able to:

  • Distinguish tenant identity from workload identity.
  • Explain why quotas and ownership are product controls, not only infrastructure controls.
  • Design a cost-aware self-service boundary without exposing raw billing complexity.

Identity follows the action

Developers, automation and workloads should have distinct identities with least privilege. Shared static credentials destroy attribution and enlarge blast radius.

Secrets management is a delivery contract, not a shared password store

Applications should not receive long-lived platform-team credentials. Prefer workload identity and short-lived credentials where the infrastructure supports them; when a secret must be materialized, define ownership, rotation, scope and auditability. External Secrets, Vault and cloud secret managers are implementation options, not a reason to expose secret-manager internals to every developer.

  • Workload identity
  • Short-lived credentials
  • External secret synchronization
  • Vault/cloud secret-manager integration
  • Rotation and ownership evidence

Tenancy needs explicit boundaries

Namespace/project/account boundaries, network controls, quotas and policy scopes should match the organization’s isolation requirements. A platform cannot promise strong isolation if the underlying boundary does not provide it.

Cost is feedback

Self-service should expose enough cost/size information to support responsible choices, and ownership tags/metadata should make spend attributable. Guardrails can cap obviously excessive requests without turning every request into finance approval.

Worked example

Tenant request

{"team":"payments","namespace":"payments-prod","cpu_quota":8,"memory_gi":16,"cost_center":"FIN-42"}
  • The request is attributable to a tenant and bounded by quota.
  • The platform must still define which identities can administer or consume the resulting capability.

Workload identity over shared static credentials

Workload → workload identity → scoped secret/token → service
NOT: every workload → platform-team static cloud key
  • Separate identities preserve attribution and reduce blast radius.
  • A golden path should make the safer identity path easier than copying secrets into CI variables or manifests.
Core lab · account-free

Lab 10 — Validate tenancy and quota boundaries

Goal: Reject an over-sized or unattributed tenant request before provisioning.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create tenant policy

cat > /tmp/tenant.json <<'EOF'
{"team":"payments","cpu":8,"memory_gi":16,"max_cpu":16,"max_memory_gi":32,"cost_center":"FIN-42","admin_group":"payments-platform-admins"}
EOF
STEP 2

Validate

python3 - <<'PY2'
import json,re
x=json.load(open('/tmp/tenant.json'))
assert x['cpu']<=x['max_cpu'] and x['memory_gi']<=x['max_memory_gi']
assert re.fullmatch(r'[A-Z]+-[0-9]+',x['cost_center'])
assert x['admin_group'].endswith('-admins')
print('tenant boundary valid')
PY2
STEP 3

Define workload identity

Write which identity an application workload should use and why it should not inherit a human/platform-admin credential.

Verify

  • Requested capacity is within quota.
  • Ownership/cost attribution and an admin group are explicit.

Expected outcome

  • A bounded tenant contract.

Diagnose / troubleshoot

  • If one shared service account owns every workload, split identities by workload/tenant need.
  • If quota changes require code edits everywhere, define a policy/config source of truth.
Real-world connection

Good platform tenancy limits blast radius, keeps self-service attributable and makes capacity/cost conversations evidence-based.

Real-tool practicum · optional but recommended

Optional tool lab — Kubernetes quota/RBAC inspection

Inspect ResourceQuota and RoleBinding in a disposable namespace.

Prerequisites

  • Use a disposable local lab or organization-approved sandbox.
  • Pin tool versions in real platform automation; do not blindly depend on latest.

Cost / risk

  • Core learning is account-free. Optional external/sandbox tools may consume local CPU/RAM; do not use production credentials or billable cloud resources.

Warnings

  • Do not point training automation at production clusters, repositories or cloud accounts.
  • A successful command is not proof of a good platform interface; validate the developer outcome and guardrails.
TOOL 1
kubectl get resourcequota -A 2>/dev/null || true
TOOL 2
kubectl get rolebinding -A 2>/dev/null | head || true
Avoid these traps

Common mistakes

  • Using one shared admin identity for developers and workloads.
  • Calling namespaces “hard multi-tenancy” without threat-modeling the isolation boundary.
  • Hiding cost until month-end instead of giving request-time feedback.
Knowledge check

Can you connect the developer need to a platform contract?

Three concept checks plus one scenario check.

1Why separate human, automation and workload identities?

They have different trust, attribution and least-privilege requirements.

2What do quotas protect?

Shared capacity and blast radius by bounding how much a tenant/workload can consume.

3Why require cost ownership metadata?

It makes resource use attributable and supports cost feedback/governance.

4Scenario: every service uses the platform team’s cloud credential. What is the primary risk?

Shared broad identity removes least privilege/attribution and dramatically increases blast radius.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.