isolation (ci-isolation)

Purpose: keep the CI namespace from harming the production workloads it sits next to — east-west network isolation plus a hard resource ceiling.

Deploys (manifests/components/isolation/): - default-deny-ingress (all pods) — nothing can open connections into con-ci. Combined with the egress component's default-deny-egress (CI pods only reach the proxy + DNS), this is the east-west isolation: no traffic to/from production namespaces. - con-ci-quota (ResourceQuota) — caps the namespace: requests.cpu 4 / requests.memory 8Gi / limits.cpu 8 / limits.memory 16Gi / pods 20. A runaway build can't exhaust nodes or evict prod pods. - con-ci-limits (LimitRange) — default + max per container, so pods that omit resources still get bounded values (required by the quota).

Key facts: - The runner is outbound-only, so default-deny-ingress costs nothing functionally (only the egress-proxy accepts ingress, and only from CI pods — see the egress component). - Sizing follows the runner: host capacity 5 ≈ runner pod limits 4 CPU / 4Gi, well within the quota.

Operate: kubectl -n con-ci get resourcequota,limitrange,networkpolicy. If new pods are rejected, check the quota usage (kubectl -n con-ci describe resourcequota con-ci-quota).

Related deliverable: the blast-radius sign-off for running CI on prod is docs/risk-acceptance-ci-on-prod.md.