Container and Kubernetes isolation

Test RBAC, workload identity, admission, networking and host exposure as separate enforcement layers.

Used in these playbooks#

Setup and invariant#

Use an isolated cluster or an explicitly provided test namespace with two tenant identities. Record context, API version, namespace, CNI, admission configuration, image digest and service accounts. Prepare one canary Secret and one inert HTTP service using administrator fixtures. A tenant may not acquire another tenant's data, workload identity or host authority through the deployment features it is allowed to use. A namespace name alone does not specify the isolation promise.

Procedure#

1. Start from the actual low-privilege identity. Use its own kubeconfig context. Separate resource reads, workload creation, role binding, impersonation and token issuance. Review permission grants before using them. kubectl auth can-i asks the authorization layer; it does not prove admission acceptance or exploitation. RBAC risks, permission query reference

2. Compare direct and indirect canary access. The fixture owner reads its canary; the restricted principal should be denied. If workload creation is permitted, inspect whether a pod can choose a more powerful service account or mount a forbidden namespace resource. In the lab, use a one-shot workload that checks only the synthetic marker and exits. Record its resulting service account and generated pod, not only the submitted template. Service-account identity and its authorization are separate configuration elements. Service accounts

3. Exercise admission coverage. Use an allowed manifest as a positive control. Compare one owner-approved manifest that violates the advertised policy, then the equivalent supported update path. In a disposable cluster, compare admission responses and final persisted objects. Avoid actual privileged workloads when admission rejection already answers the test. Server dry-run still contacts admission components; it is not offline inspection. Admission webhook guidance

4. Measure network isolation independently. From two pre-created test pods, request the same tiny canary endpoint once. Record source/destination labels, namespaces, port and policy direction. The allowed source should receive the marker; the disallowed source should not. A timeout is inconclusive until the service and allowed route work. Policy objects require an enforcing network implementation; do not infer isolation from YAML alone. NetworkPolicy behavior

5. Inspect the container-to-host boundary. Record privileged mode, capabilities, host namespaces, host paths, socket mounts and UID mapping. Root inside a container does not establish host root. Where the owner supplies an isolated host fixture, a read of a synthetic host-mounted marker can demonstrate unintended filesystem exposure without reading host credentials. Compare with the restricted deployment. Pod Security Standards, Docker security

Command card#

These commands query one named resource or inspect one owned container. They do not create workloads.

kubectl --context lab-tenant-a --request-timeout=10s \
  -n tenant-b auth can-i get secrets/bounty-canary

kubectl --context lab-tenant-a --request-timeout=10s \
  -n tenant-a auth can-i create pods

kubectl --context lab-owner --request-timeout=10s \
  -n tenant-a get pod bounty-probe \
  -o jsonpath='{.spec.serviceAccountName}{"\n"}'

docker --context lab-engine container inspect bounty-probe \
  --format '{{json .HostConfig.Privileged}} {{json .HostConfig.Binds}}'

Expect no for cross-tenant Secret access. A yes is an authorization finding candidate; verify only the supplied canary when reading is allowed. The inspect output establishes configuration, not an escape exploit. Docker inspect

Evidence, cleanup and checklist#

Store the starting role, requested object, admission decision, resulting workload, canary result and comparison case. Link business-level ownership to the shared authorization matrix. False positives include intended cluster administrators, intentionally shared namespaces and policies ineffective only because the lab omitted the production CNI. Describe those limitations explicitly.

• Namespace, workload, node and network boundaries separated.
• Low-privilege context used for reproduction.
• Only synthetic Secrets and markers accessed.
• Admission acceptance distinguished from runtime impact.
• Saved fixture UIDs checked before deletion.
• Disposable pods, role bindings and markers removed without deleting shared namespaces.

Vulnerability reverse references#

• Kubernetes Secret access exceeds tenant permissions — A restricted cluster principal can read a canary Secret outside its intended resource boundary.
• Workload creation grants unintended service-account authority — An allowed workload-creation path lets a tenant select a service account or resource mount exceeding its promised permissions.
• Admission policy misses a supported object or update path — A tenant can persist an object prohibited by the advertised admission policy through a missed operation, selector or subresource.
• Namespace or workload network restriction is ineffective — A disallowed fixture workload reaches a service across a network boundary that the deployment claims to enforce.
• Container exposes unintended host files or privileges — A supported container configuration gives an untrusted workload access to host resources outside the documented isolation boundary.
• Container daemon management endpoint lacks required client authentication — An untrusted network client reaches protected container-management functionality without the required identity checks.
• Shared CI runner exposes private state across jobs — A job reaches a previous job's private filesystem or image material despite the runner's promised isolation.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity