Learn OpenClaw - Ingress & Egress Management

#Introduction

Welcome to episode 5 of the Learn OpenClaw series! In episode 4 you wrote network policies governing service-to-service communication inside the cluster — east-west traffic. Now we move to the cluster boundary: traffic coming in from outside (north-south) and traffic going out to the world.

This episode covers three things: ingress configuration with TLS termination, egress control to external services, and gateway and route policies for mesh entry and exit points. If episode 4 was managing the intersections inside the city, episode 5 is managing the city gates — and who's allowed in and out.

#Gateway, Ingress, and Egress Concepts

Before writing configuration, let's straighten out terms that are often confused:

• Ingress: the mechanism for accepting traffic from outside the cluster and forwarding it to services inside.
• Egress: the mechanism for allowing services inside the cluster to communicate outward, for example to third-party APIs.
• Gateway: a managed entry or exit point — where TLS terminates, routing begins, and policies apply.

In OpenClaw, all three are managed with declarative resources consistent with the policy concepts from episode 4. Incoming traffic still passes through policy evaluation before being forwarded to the destination service.

#Ingress Configuration and TLS Termination

Ingress in OpenClaw starts with a gateway that listens on a specific host, then a route that maps paths to services. Here's an example gateway configuration with TLS:

apiVersion: openclaw.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: sample
spec:
  listener:
    - host: api.example.com
      port: 443
      tls:
        mode: terminate
        secretName: api-tls-cert

The api-tls-cert secret stores the certificate and private key. OpenClaw terminates TLS at this gateway, so traffic to services inside can be plain HTTP. Apply it and check its status:

kubectl apply -f gateway.yaml{:bash}
kubectl get gateway public-gateway -n sample -o yaml

For the certificate, use a regular Kubernetes Secret, or automate it with cert-manager if available. Make sure the host actually points to the gateway — you can test with a local request:

curl --resolve api.example.com:443:$(kubectl get svc -n openclaw-system -l app=gateway -o jsonpath="{.spec.clusterIP}") https://api.example.com/healthz

If the response comes back with a success status, ingress and TLS are working. Remember: the host and IP above are placeholders for this example — adjust them for your own gateway.

#Egress Control to External Services

Not all outgoing traffic may pass. Egress control in OpenClaw ensures services can only reach approved external endpoints. This concept builds on the outbound policies from episode 4, but with a representation of external targets:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: web-payment-external
  namespace: sample
spec:
  selectors:
    - matchLabels:
        app: web
  match:
    to:
      - external:
          host: payment-gateway.example.com
          port: 443
  rules:
    - allow:
        methods: [POST]

This policy allows web to call payment-gateway.example.com over HTTPS and only with the POST method. Requests to other hosts or with other methods are automatically denied.

There are two common egress models: explicit allow-list (everything is denied except what's listed) and deny-list (everything is allowed except what's denied). For production, always start from an explicit allow-list — it's easier to audit and more secure.

#Gateway and Route Policies for Mesh Entry/Exit Points

Gateways don't only serve external traffic. OpenClaw can create internal gateways as mesh entry points — for example, a service in one namespace accesses the mesh through a gateway that already applies security policies. This pattern is often used for mesh entry points.

Here's a route policy connecting the gateway to a service inside the mesh with method restrictions:

apiVersion: openclaw.io/v1
kind: Route
metadata:
  name: api-public-route
  namespace: sample
spec:
  gatewayRef: public-gateway
  match:
    pathPrefix: /api
  forwardTo:
    service: api
    port: 8080
  rules:
    - allow:
        methods: [GET]

This route accepts requests with the /api prefix from public-gateway, forwards them to service api on port 8080, and only allows GET. By separating gateway, route, and policy, you get layers that can be tested and replaced independently.

#Wrap-Up

In episode 5 you managed the cluster boundary: ingress with TLS termination through a gateway, egress control to external services with an allow-list, and gateway and route policies that serve as mesh entry and exit points.

Key takeaways:

• Ingress handles incoming traffic, egress handles outgoing traffic, and the gateway is the point of control for both.
• TLS termination happens at the gateway: the certificate is stored in a Secret and verified with real requests.
• Use an explicit allow-list for production egress so it's easy to audit.
• Separate gateway, route, and policy so each layer can be tested and changed independently.
• Every traffic passing through the gateway is still evaluated by OpenClaw policies.

In the next episode, episode 6, we'll cover security policy enforcement: enabling authentication, authorization, and mTLS, enforcing policies for service-to-service communication, plus audit logging and policy change tracking. This is where OpenClaw truly becomes a fortress.