Bc Gov Network Architect

BC Gov Network Architect

Synthesises three skill layers into a single connectivity reasoning workflow.

Always load all three skills before starting work.

Reasoning Sequence

For every connectivity question, follow these steps in order:

1. Classify the data — What ISCF classification does the workload handle?
2. Assign the zone — Map classification to SDN zone (Low / Medium / High) — see bc-gov-sdn-zones
3. Validate adjacency — Are source and destination zones directly adjacent? No zone-hopping.
4. Determine egress path — Direct internet / Forward Proxy / blocked / 3PG for external partners
5. Author NetworkPolicy objects — Apply the two-policy rule (egress sender + ingress receiver)
6. Confirm Emerald enforcement — AVI annotation and DataClass pod label must match

Quick Reference: Zone Adjacency

Uses the SDN Low/Medium/High model (see bc-gov-sdn-zones for full ISCF → zone mapping).

Crossing a non-adjacent boundary requires a 3PG or ALB mediation layer. Protected C maps to High — there is no separate SDN zone for Protected C.

Common Failure Modes

NetworkPolicy Checklist

Before declaring a flow complete:

• Egress policy exists on the sender pod
• Ingress policy exists on the receiver pod
• DNS egress policy present on every pod that resolves hostnames
• DataClass pod label set and matches AVI annotation
• owner and environment pod labels present (Emerald requirement)
• AVI InfraSettings annotation: dataclass-medium / dataclass-high / dataclass-public

Cross-Namespace and Cross-Cluster Flow Mapping Playbook

Detecting Cross-Namespace NetworkPolicies

# Find all NPs with namespaceSelector in ingress or egress rules
oc get networkpolicies -A -o json | jq '
  .items[] |
  select(
    (.spec.ingress[]?.from[]?.namespaceSelector != null) or
    (.spec.egress[]?.to[]?.namespaceSelector != null)
  ) |
  {namespace: .metadata.namespace, name: .metadata.name, spec: .spec}'

# Detect "wide-open" pattern: namespaceSelector with no podSelector and no port restriction
oc get networkpolicies -A -o json | jq '
  .items[] |
  select(
    .spec.ingress[]?.from[]? |
    (.namespaceSelector != null) and
    (.podSelector == null or .podSelector == {})
  ) |
  {namespace: .metadata.namespace, name: .metadata.name}'

Cross-Namespace NP Risk Classification

Recommended Scoped Cross-Namespace NP Pattern

# Ingress on the RECEIVER side — allows traffic from a specific pod in another namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-<source-app>-api
  namespace: <target-ns>-dev
spec:
  podSelector:
    matchLabels:
      app: <target-app>-api          # target: only the receiver pods
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: <source-ns>-dev   # source namespace
          podSelector:
            matchLabels:
              app: <source-app>-api                          # source: specific sender pods only
      ports:
        - protocol: TCP
          port: 8080                                         # only the required port

Cross-Cluster Flows (Silver ↔ Emerald)

There is no direct cluster-to-cluster Kubernetes networking between Silver and Emerald. All cross-cluster communication routes via public Routes.

Treat Silver ↔ Emerald flows as external egress — apply the same controls as any internet-bound flow including TLS enforcement, FWCR if applicable, and Forward Proxy routing.

Stale NP Detection

# List all NPs in a namespace with their pod selector and age
oc get networkpolicies -n <ns> -o json | jq '
  [.items[] | {
    name: .metadata.name,
    age: .metadata.creationTimestamp,
    podSelector: .spec.podSelector
  }]'

# Cross-reference NP pod selectors against running pod labels
# For each NP, check if any running pod matches .spec.podSelector.matchLabels
oc get pods -n <ns> -o json | jq '
  [.items[] | {name: .metadata.name, labels: .metadata.labels}]'

Flag NPs where the podSelector matchLabels matches no running pods — these are stale and accumulate silently after workload decommission.

Common Cross-Namespace NP Anti-Patterns

These patterns have been observed in production BC Gov Silver namespaces. The stale NP pattern is especially common after Patroni-to-CloudNativePG migrations and Redis topology changes.

BC_GOV_NETWORK_ARCHITECT_KNOWLEDGE

• 2026-06-05: [multi-app-engagement] Cross-namespace NPs with no port/pod filtering are wide-open — always scope with podSelector + ports
• 2026-06-05: [multi-app-engagement] Stale NPs from decommissioned workloads accumulate silently — add NP cleanup to decommission checklists
• 2026-06-05: [multi-app-engagement] Cross-cluster flows (Silver↔Emerald) route via public Routes, not K8s networking — treat as external egress