Network Policies

Your service can reach some things on the platform and not others, and you need
to know which of those is deliberate. Traffic between workloads is controlled by
Kubernetes Network Policies, which CTO2B configures and maintains. Your team
states what access it needs; CTO2B implements it.

The default posture

The rule of thumb is: allowed inside your namespace, denied across
namespaces, allowed outbound to the internet.

Everything that is denied is denied silently from the caller's point of view —
the connection times out or is refused rather than returning a helpful error. A
connection that works in one namespace and fails from another is the signature
of a policy, not of a broken service.

Requesting cross-namespace access

Cross-namespace traffic needs an explicit exception. Raise a request containing
all of the following — a request missing any of it cannot be actioned and will
come back to you:

• Source — the namespace and the Component that needs to make the call
• Destination — the namespace and the Component being called
• Port and protocol — for example 5432/TCP
• Why — one line on what the call is for, so the exception can be scoped
  correctly rather than opened wider than needed

Worked example

A reporting service in the analytics namespace needs to read from a
PostgreSQL database that belongs to the payments namespace. The request would
read:

CTO2B then adds a policy permitting exactly that source to reach exactly that
destination on that port. Other workloads in analytics do not gain access.

Note that reading another namespace's database also needs the credentials to be
injected — that is a separate configuration step, covered in
Application Dependencies.

Restricting egress to the internet

Outbound internet access is open by default. If your organisation needs it
restricted for compliance reasons, raise a request: CTO2B can configure egress
policies that permit only named external destinations. Include the destination
hostname or IP range, the port, and the protocol for each endpoint that must
keep working.

Troubleshooting connectivity

If your application cannot reach another service, check in this order:

1. Is the destination in a different namespace? If so, an exception is
   probably needed — see above.
2. Is the destination Component healthy in SVIEW? A policy is not the cause
   if the target is not running.
3. Are you calling it by hostname through the ingress? Then check the
   ingress configuration rather than network policy — see
   Ingress, Custom Domains and TLS.

If you still believe a policy is blocking traffic incorrectly, raise a request
with the source Component, the destination, the port, and the exact error you
are seeing.

Related articles

• Ingress, Custom Domains and TLS
• Traffic Encryption (mTLS)
• Application Dependencies
• Getting Help