Kubernetes / Advanced: extensibility, resilience, and lifecycle / Lesson 15
Workload security and multi-tenancy
Combine authorization, admission, runtime restrictions, network controls, and operational ownership for an explicit tenant threat model.
On this page
Lesson goals
- Explain the model, assumptions, and boundaries of workload security and multi-tenancy.
- Interpret both examples and distinguish declared intent from established evidence.
- Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.
State the trust model before choosing controls
Tenants can be mutually trusted teams or hostile parties, and those models require different boundaries. A namespace organizes resources but does not by itself isolate kernels, network traffic, credentials, or cluster administrators. Review whether shared nodes and control-plane authority meet the intended risk. Some workloads require a sandbox runtime, separate nodes, or a separate cluster according to verified platform guarantees. No single setting supplies complete isolation. Define who may create workloads, select identities, change policy labels, attach storage, and inspect execution, then evaluate indirect privilege paths as well as direct reads.
Use admission as enforceable policy
Pod Security Admission can evaluate workloads against named Pod Security Standards using namespace labels and selected policy versions. The first Namespace is illustrative and pins a policy version rather than silently following every new rule. Enforce, audit, and warn serve different purposes. A warning does not deny creation, and restricted policy can reject workloads that need redesign or a narrowly authorized exception. Protect who can alter labels and exceptions. Admission validates a request against policy; it does not prove that an image is benign, a dependency is patched, or the application never exposes sensitive data.
apiVersion: v1
kind: Namespace
metadata:
name: training-restricted
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.35
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: v1.35
The chosen server must support the selected policy version. This object could reject workloads if applied, so it remains non-runnable; the version is an assumption to review, not a recommended permanent pin.
Constrain container capabilities deliberately
The second fragment requests a nonroot process, no privilege escalation, dropped Linux capabilities, a read-only root filesystem, and the runtime’s default seccomp profile. Each setting has application and platform assumptions; required writable paths may need explicit bounded volumes. These controls reduce particular risks and are not a universal sandbox. Avoid privileged containers, broad host mounts, and host namespaces unless a reviewed function truly requires them. A nonroot UID can still read mounted credentials or exercise network access. Match filesystem ownership, runtime class, node trust, and service identity to the workload contract.
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: [ALL]
seccompProfile:
type: RuntimeDefault
This container-level fragment needs a compatible image, UID, writable-path design, and runtime support. It is not a complete Pod or proof of tenant isolation.
Protect the supply and credential paths
Use reviewed immutable artifact identities, trusted registries, vulnerability response, and provenance verification where the delivery policy requires them. A signature needs an expected signer and source policy rather than accepting any valid key. Limit Secret access and workload identities, and avoid storing credential values in source, image layers, annotations, or telemetry. NetworkPolicy must be enforced by the selected implementation and cannot replace application authorization. Audit collection and diagnostic access are sensitive capabilities too. Keep emergency access time limited, accountable, and tested without turning a temporary incident exception into a permanent privileged workload.
Verify assumptions across the whole boundary
Review allowed and denied behavior for tenant identities, workload creation, mounts, network paths, and administrative authority. Use an authorized isolated environment for enforcement and adversarial testing; this course performs none. Static manifests show intent only and are never applied. Reassess isolation after upgrades, new plugins, host integrations, or changed team permissions. A security posture is an ongoing agreement among application, platform, and security owners. The correct question is which threat a control prevents, under which assumptions, and how failure would be detected, not whether a namespace or a checklist has been created.
Common errors and fixes
Restricted labels are treated as complete isolation
- Why it happens
- Admission checks were confused with all runtime and tenant guarantees.
- How to fix it
- Review RBAC, identities, runtime, nodes, and network together.
- Prevent it next time
- Maintain a tenant threat model and enforcement evidence.
A read-only root breaks startup
- Why it happens
- Required writable paths were not identified.
- How to fix it
- Provide narrowly scoped bounded storage or redesign the write.
- Prevent it next time
- Test image behavior with the intended security context.
A tenant changes its own enforcement labels
- Why it happens
- Policy mutation authority exceeded the tenant trust boundary.
- How to fix it
- Restrict policy ownership and review exceptions explicitly.
- Prevent it next time
- Audit indirect administrative authority.
Check your understanding
1. Does nonroot execution prevent a workload from reading a mounted token?
Show worked solution
Not necessarily. File permissions and mount design can make the token readable to that UID. Review whether the workload needs the credential, its identity scope, and token mounting policy. Nonroot reduces specific host-related risks but is not a complete data-access policy.
2. A warning admission mode prints a policy violation. Was creation denied?
Show worked solution
Warning behavior is distinct from enforcement. Check the configured mode and actual admitted result rather than treating a message as a deny. Protect policy ownership and verify the intended reject path in an authorized isolated environment.
Key takeaways
- Tenants can be mutually trusted teams or hostile parties, and those models require different boundaries.
- The second fragment requests a nonroot process, no privilege escalation, dropped Linux capabilities, a read-only root filesystem, and the runtime’s default seccomp profile.
- Review allowed and denied behavior for tenant identities, workload creation, mounts, network paths, and administrative authority.