Skip to content

Configuring Application Networking

The platform operates on a "default-deny" network security model. This means that, by default, all incoming and outgoing network traffic to and from your pods is blocked. While this provides a highly secure environment, it requires you to explicitly define the network paths your application needs to function.

Directly creating Kubernetes NetworkPolicy resources is usually restricted on the platform. This is to prevent common misconfigurations that can lead to security vulnerabilities, policy conflicts, and operational complexity.

Instead, you will use a set of simplified custom resources to declare your application's networking requirements. This guide explains how to use these tools to securely connect your services.

Connecting Pods Within the Same Namespace

The most common task is enabling communication between different pods within your own namespace (e.g., allowing a frontend web server to talk to a backend API). You will use the LocalNetworkConfig resource for this.

The LocalNetworkConfig allows you to define the different "components" of your application and declare their dependencies. The platform then uses this information to automatically generate the correct, secure NetworkPolicy objects.

Example: Frontend to Backend Communication

Imagine you have a frontend application that needs to make API calls to a backend service on port 8080.

First, you define your Deployment or StatefulSet manifests, ensuring they have clear labels (e.g., app.kubernetes.io/name: frontend).

Next, you create a LocalNetworkConfig resource in your namespace to define the connection.

apiVersion: networking.tcs.trifork.com/v1alpha1
kind: LocalNetworkConfig
metadata:
  name: my-app-network-config
spec:
  components:
    frontend:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: frontend
      # This section defines the frontend's dependencies.
      dependsOn:
        - component: backend
          port: 8080
    backend:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: backend

What this manifest does:

  • It defines two components, frontend and backend, using podSelector to identify which pods belong to each.
  • The dependsOn section under frontend is the key. It declares that the frontend needs to talk to the backend on TCP port 8080.
  • The platform controller will see this dependency and automatically create two NetworkPolicy rules:
    1. An egress rule allowing traffic from frontend pods to backend pods on port 8080.
    2. An ingress rule allowing traffic to backend pods from frontend pods on port 8080.

Connecting to Services Outside Your Namespace

To connect to services in other namespaces or to external endpoints on the internet (e.g., a third-party API), you use a NetworkProfile.

A NetworkProfile is a centrally managed, reusable resource that defines an allowed egress destination. Creating NetworkProfiles is a restricted operation managed by the platform team to ensure security.

Your task as a developer is to reference an existing, pre-approved NetworkProfile in your LocalNetworkConfig.

Example: Egress to an External API

Suppose your application needs to connect to the public Cloudflare DNS service at 1.1.1.1 on port 53. The platform team has already created a NetworkProfile for this purpose named allow-egress-to-cloudflare-dns.

You would modify your LocalNetworkConfig to reference this profile:

apiVersion: networking.tcs.trifork.com/v1alpha1
kind: LocalNetworkConfig
metadata:
  name: my-worker-network-config
spec:
  components:
    my-worker-app:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: my-worker
      # This worker depends on the pre-defined NetworkProfile.
      dependsOn:
        - networkProfile: allow-egress-to-cloudflare-dns

This will automatically attach a NetworkPolicy to your my-worker-app pods, allowing them to send traffic to the destinations defined in the allow-egress-to-cloudflare-dns profile.

Reference: What a NetworkProfile Looks Like

For your reference, here is the definition of the NetworkProfile used in the example above. Remember, you do not create this yourself.

apiVersion: networking.tcs.trifork.com/v1alpha1
kind: NetworkProfile
metadata:
  name: allow-egress-to-cloudflare-dns
spec:
  egress:
    - to:
        - ipBlock:
            cidr: 1.1.1.1/32
      ports:
        - protocol: TCP
          port: 53
        - protocol: UDP
          port: 53

If you need to connect to a new external service or another namespace for which a NetworkProfile does not already exist, please contact the platform team for assistance.