Learn Multigress - Egress & Service-to-Service Routing

#Introduction

Security isn't only about inbound traffic. Pods slipping out to the internet without control are a major risk. Episode 13 covers egress and service-to-service routing: directing outbound traffic through an egress gateway, managing access to external services explicitly, and using NetworkPolicy to limit lateral movement inside the cluster.

The end goal: every byte of outbound and service-to-service traffic passes through a path that is recorded, governed by policy, and auditable.

#Configuring Outbound Traffic Policies

#Why You Need an Egress Gateway

Without an egress gateway, every pod has its own internet access through the node IP. That's hard to audit and hard to govern. With an egress gateway, all outbound traffic goes through a single point where it can be observed and limited. Multigress supports this mode with egress-specific listeners and routes.

#Egress Gateway and EgressRoute

Declare egress as a dedicated Gateway with a TCP or TLS listener:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: egress-gateway
  namespace: multigress-system
spec:
  gatewayClassName: multigress
  listeners:
    - name: egress-tls
      protocol: TLS
      port: 443
      hostname: "*.internal-out.example.com"

Internal pods are then pointed at this egress gateway. Outbound traffic is forced through the monitored SNI:

apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: egress-route
spec:
  parentRefs:
    - name: egress-gateway
      namespace: multigress-system
  hostnames:
    - "*.internal-out.example.com"
  rules:
    - backendRefs:
        - name: external-vip
          port: 443

With this pattern, only the domains on the list can be accessed externally. Other domains have no route, so they're rejected.

#Managing Access to External Services

#ExternalName Service as the Access Gateway

To expose an external service inside the cluster as a regular Service, use ExternalName:

apiVersion: v1
kind: Service
metadata:
  name: payment-gateway
  namespace: platform
spec:
  type: ExternalName
  externalName: api.payment.example.com
  ports:
    - port: 443
      targetPort: 443

The payment-gateway Service provides an internal DNS name for the payment API. Applications don't need to know the external address — they just call payment-gateway.platform.

#Per-Service Egress Policy

Combine ExternalName with an egress policy to control which services can be accessed:

apiVersion: gateway.multigress.io/v1
kind: SecurityPolicy
metadata:
  name: egress-payment-policy
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: egress-route
  authorization:
    rules:
      - when:
          - key: request.host
            values: ["payment-gateway.platform"]
        action: ALLOW
      - action: DENY

The policy above allows only payment-gateway.platform to exit the cluster. This pattern turns the external access list into reviewable code.

#Network Policy Considerations in Kubernetes

#NetworkPolicy Complements Egress

The egress gateway manages outbound traffic, while NetworkPolicy manages pod traffic at the network level. The two complement each other: the egress gateway governs where, NetworkPolicy governs from-where-to-where at the pod layer.

An example NetworkPolicy that lets the app pod only receive from the gateway proxy and same-tenant pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-ingress-policy
  namespace: team-a
spec:
  podSelector:
    matchLabels:
      app: app-a
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: multigress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              tenant: team-a

This policy only allows inbound traffic from the Multigress namespace, and outbound traffic only to the team-a namespace. A default deny on egress is very effective at preventing pods from opening rogue connections.

#Recommended Order of Application

• Egress gateway: governs traffic exiting the cluster.
• ExternalName: exposes external services explicitly.
• NetworkPolicy: restricts communication between pods.

kubectl get networkpolicy -A
kubectl get gateway egress-gateway -n multigress-system

The kubectl get networkpolicy -A command lists the policies in effect. If it's empty, inter-pod traffic isn't restricted yet — evaluate the need before production.

#Closing

Episode 13 extended control outward: egress traffic passes through a governed gateway, external services are exposed explicitly via ExternalName, and NetworkPolicy limits pod movement inside the cluster.

The key takeaways:

• An egress gateway unifies outbound traffic through a single point.
• ExternalName turns an external address into an internal Service.
• Egress policies determine which external services may be accessed.
• NetworkPolicy governs inter-pod traffic; it requires a supporting CNI.
• Egress gateway and NetworkPolicy complement each other, they don't replace one another.

In the next episode 14 we'll discuss DDoS protection & rate limiting — implementing rate limiting and throttling, protection patterns against abusive clients, and logging and alerting for traffic anomalies. Your egress and ingress gateways will become the laboratory for silencing malicious traffic.