In-Cluster Networking¶

This guide explains communication between application Pods in the Workload Cluster. For DNS, Ingress and TLS for clients outside the Cluster, see External Access. The Network Model shows how these topics fit together.

Private Network¶

Application Pods communicate using private IP addresses, including when they run on different Nodes. Pods of additional services can also be reached when the applicable network rules allow it. A private IP address does not itself guarantee isolation or encryption.

Most Welkin Environments use Calico for networking. The Platform Administrator can enable Calico's Node-to-Node WireGuard encryption for your Welkin Environment. With encryption enabled on the participating Nodes, Pod traffic between those Nodes is encrypted while crossing the physical or virtual network. Pod-to-Pod traffic within a single Node is not encrypted by this feature. Contact your Platform Administrator to request encryption or confirm its configuration.

Cilium is being introduced in Welkin. For Environments using it, see the Cilium guide, including predictable outgoing IP addresses.

Private DNS¶

By standard Kubernetes design, Pod IP addresses can change as Pods are replaced. Use Services to provide stable access to your application components instead of connecting to individual Pod IP addresses.

A Service named my-svc in namespace my-namespace can be reached using my-svc.my-namespace from Pods using the Cluster's DNS. Within the same namespace, my-svc is sufficient. The Service selects backend Pods and forwards traffic to them; DNS resolves the Service name. Resolving a name does not grant permission to connect to its backend.

Use these Service names for communication between your application components and with additional services such as PostgreSQL.

NetworkPolicies¶

Use NetworkPolicies to allow the connections your application needs and reduce the blast radius of an attack. Namespaces organize resources, but do not by themselves isolate network traffic.

In the standard Kubernetes NetworkPolicy model:

A Pod is isolated for ingress or egress when a policy selects it and specifies that direction.
Allowed traffic is the union of the applicable policies' allow rules. Adding a more restrictive policy does not override an existing allow rule.

When the source is isolated for egress and the destination for ingress, both directions must allow the connection.
A podSelector selects Pods in the policy's namespace; use a namespaceSelector when allowing Pods in other namespaces.
Egress rules must allow required DNS traffic as well as application connections.

These are Kubernetes semantics, not a statement about the default policies in your Welkin Environment. Review the policies that select your Pods and check both required connections and connections that should be blocked.

Use the user demo NetworkPolicy and NetworkPolicy recipes as starting points. Adapt selectors, ports and DNS access to your application and Environment. See the NetworkPolicy guardrail for checks that Pods have a matching policy. A matching policy is not proof that its rules provide the intended isolation.

Limitations¶

Standard NetworkPolicies control network connections; they do not encrypt traffic or authenticate application users. Use suitable encryption and application authentication where required.

Traffic to and from a Pod's own Node has exceptions to NetworkPolicy filtering. Welkin's default Restricted Pod Security Standard disallows hostNetwork for application Pods. Any exception requires review and approval by the Platform Administrator through a custom Pod Security Policy. See the upstream NetworkPolicy limitations for details.

Cross-namespace Forwarding¶

Warning

A trusted intermediary can forward traffic to a backend that the original client cannot reach directly. A NetworkPolicy that allows the intermediary cannot distinguish whether its forwarded traffic was authorized by your application.

CVE-2021-25740 describes how users who can create or modify Endpoints or EndpointSlices can direct an Ingress or LoadBalancer implementation to backend IP addresses they should not be able to expose. When the target's NetworkPolicy trusts that intermediary, this can bypass the intended separation between namespaces.

This forwarding is possible by Kubernetes' design. In Welkin, Application Developers cannot create or modify Endpoints and EndpointSlices by default. Write access requires a risk acceptance process, as described in ADR-0054. If your application requires this access, contact your Platform Administrator. Before permissions are granted, you must confirm that there is no viable alternative for your use case and that you understand and accept the associated security risks.

If a risk-accepted exception has been granted, Platform Administrators should review the Roles and RoleBindings that provide write access and revoke permissions that are no longer needed. They should also review manually managed Endpoints and EndpointSlices associated with Services without selectors, and remove or correct forwarding to unintended backends. Revoking write access does not remove existing resources. Platform Administrators should coordinate these changes with the affected Application Developers to avoid disrupting legitimate connections.

Forwarding through ExternalName Services is another possible path through an Ingress Controller. Traefik supports Ingress backends that reference ExternalName Services, but its providers.kubernetesIngress.allowExternalNameServices setting is disabled by default. Welkin does not enable this setting in its standard configuration, so these backends are not allowed by default. The Traefik section of the public configuration reference documents Welkin's available Traefik configuration options, but does not list a dedicated option for ExternalName Service forwarding. Ask your Platform Administrator whether your Environment overrides this setting when reviewing forwarding risks.

The default write restrictions mitigate exposure; they do not remove the underlying design limitation. The current upstream CVE guidance and RBAC guidance describe the administrator's checks. Ask your Platform Administrator about the controls in your Environment rather than assuming its Kubernetes version proves isolation.

Demarcation of Responsibilities¶

As an Application Developer, you are responsible for creating Pods through workloads such as Deployments, creating Services, and configuring and verifying NetworkPolicies for the required application traffic.

The Platform Administrator is responsible for the underlying network, the network plugin, platform policies and permissions, and reviewing forwarding features that affect separation between applications.