# Prove an isolated export worker stays isolated

Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.

Your export worker should read one tenant store and write to one output service. Determine whether the intended policy is actually enforced.

## Supplied material

```text
Workload export-worker in namespace jobs uses service account exporter. Required: non-root, no host namespaces, read-only root filesystem, DNS and TCP/443 access to output only.
Manifest requests runAsNonRoot=true but hostPID=true. Admission policy is configured in audit mode.
NetworkPolicy P1 allows only output:443. P2 in the same namespace selects the same worker and allows all egress. Network policies are additive.
Cloud role trust accepts any service account in namespace jobs. Role permissions allow GetObject for every tenant prefix and PutObject for output/*.
Gateway requires an authenticated tenant claim; origin service also has a public listener that trusts X-Tenant sent by callers.
GraphQL export query asks for 20 reports × 30 attachments; each attachment costs one unit and each report costs one. Budget is 500 units.
Logs: 10:00 new worker starts; 10:01 role assumed by jobs/debug; 10:02 direct-origin request with X-Tenant:south; 10:03 unusual object reads. Logs identify actor, request ID and artifact revision but include no credential values.
```

## Task 1

Write an intended-vs-effective boundary table for admission, network, cloud identity, origin access and resource cost.

Your assessment:

## Task 2

Calculate the query cost and identify which control denies the request before fan-out.

Your assessment:

## Task 3

Design actual allow/deny probes, including a positive output connection and a blocked unapproved destination.

Your assessment:

## Task 4

Create a containment and evidence plan from the timeline without claiming the events alone prove all read content.

Your assessment:

## Decide the fixed cases

### The GraphQL export query

- Its cost in units (20 reports × 30 attachments): ______

### Is each control effective as configured?

Choose from: Effective as intended; Not effective as configured.

- Admission: the hostPID manifest: ______
- Network: egress limited to output:443 by P1: ______
- Cloud identity: role trust: ______
- Origin access: tenant selection: ______
- Resource cost: the 500-unit budget for this query: ______

## Evidence

- Five-boundary policy diff.
- Cost calculation with enforcing checkpoint.
- Probe plan naming cluster/CNI, identities, endpoints and expected outcomes.
- Timeline, corroborating evidence requests and containment order.

## Rubric

Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.

### 1. Finds all five effective-policy failures including additive network behavior. (2 points)

- 0 points: Reads the manifests as written and declares the worker isolated.
- 1 point: Finds three or four of the five failures: hostPID admitted under audit mode, P2 widening egress, jobs/debug assuming the role, the origin trusting X-Tenant and the query over budget.
- 2 points: All five, each with its intended and effective state and the reason: audit mode records but admits; network policies are additive, so P2’s allow-all applies alongside P1; the role trusts any service account in jobs; the public listener trusts a caller-sent X-Tenant; the query costs more than the budget.

Your score:

### 2. Calculates 620 and rejects before expensive work begins. (2 points)

- 0 points: A wrong cost, or rejection only after the attachments are fetched.
- 1 point: The correct total of 620, but no enforcement point, or one after fan-out.
- 2 points: 20 reports plus 20×30 attachments is 620 units, over the 500-unit budget, so the query is rejected when it is admitted, by cost analysis before execution, with a clear error; a query within 500 units still runs.

Your score:

### 3. Includes allowed and prohibited probes against the real enforcement components. (2 points)

- 0 points: No probes, or a review of YAML only.
- 1 point: Denial probes only, with a timeout taken as proof, or probes not tied to the installed CNI.
- 2 points: A probe plan naming the cluster, CNI and versions: the worker reaches output:443 and DNS (the positive control); a connection to an unapproved destination fails; a hostPID Pod is refused once admission enforces; jobs/debug cannot assume the role; a direct-origin request with X-Tenant is refused. Each lists its expected and observed result.

Your score:

### 4. Contains access paths while preserving evidence and limiting unsupported impact claims. (2 points)

- 0 points: Deletes the debug account and its logs, or states exactly which data was read from the timeline alone.
- 1 point: Contains the access paths but does not preserve the role and application records first, or requests no corroborating evidence.
- 2 points: An ordered plan: preserve role-assumption and object-access records; remove the jobs/debug trust path; isolate the public origin listener; confirm the worker still produces output; request object-access logs before stating what was exposed.

Your score:

Critical failures (resolve before calling the case complete):

- [ ] Calls audit-mode admission enforcing.
- [ ] Assumes P1 overrides P2.
- [ ] Uses caller X-Tenant as authorization.

## Implementation option: Verify Kubernetes admission and network boundaries

Repair the warning-only admission binding and the overbroad ingress rule until the 12 offline tests pass, then, if you can run Docker and kind, apply them to the disposable cluster and run verify-cluster.mjs.

Keep: Offline test output, and for the live path the tool versions, CNI rollout output and verify-cluster.mjs output showing both allowed and denied probes.

Download: https://softwaresecurity.com/downloads/projects/kubernetes-enforcement-6d129f5f9f250337.zip (Node.js 22+ offline · kind/Docker/kubectl for live cluster, 12 tests). Instructions: https://softwaresecurity.com/labs/#project-kubernetes-enforcement

## Worked assessment (read after completing the case)

The effective configuration is unsafe: hostPID remains admitted in audit mode; P2 broadens egress despite P1; jobs/debug can assume the role; the origin trusts caller-selected tenancy; the query costs 20+20×30=620 and exceeds 500. Enforce admission, remove or narrow the broad egress selection, bind role trust to the intended workload and permissions to necessary prefixes, and require origin authentication with trusted tenant context. Test against the installed cluster/CNI rather than treating YAML as proof. Preserve role and application event records, revoke the debug path and isolate the public origin while verifying legitimate worker operation. Correlate object access records before stating exact data exposure.

Original teaching material: CC BY 4.0. Attribution: Software Security.