Networking & Ingress

Conncentric does not manage your network. The platform runs inside your Kubernetes cluster and relies entirely on your organization's networking infrastructure for external connectivity. Your networking team is responsible for firewall rules, IP whitelisting, VPN configuration, TLS certificates, and any other network controls required by your security policy.

This page explains what the platform exposes, how it exposes it, and what your infrastructure and networking teams need to configure.

Two traffic patterns

Conncentric has two distinct networking patterns that require different Kubernetes Service types:

Pattern	What it serves	Kubernetes mechanism	Protocol
HTTP (Portal and API)	Portal UI for users, REST API for adapters and the installer	Ingress resource routed to ClusterIP Services	HTTPS (TLS terminated at the Ingress controller)
TCP (Acceptor sessions)	Inbound protocol connections from external counterparties (e.g., FIX acceptor sessions)	LoadBalancer Service exposing a port range	Raw TCP

If your deployment only uses initiator-mode adapters (outbound connections), the TCP pattern does not apply and no inbound ports need to be opened.

HTTP ingress

The chart can create a single Ingress that routes traffic to two backends:

Path	Backend	Purpose
/api, /actuator	Orchestrator service (port 8080)	REST API and health endpoints
/	Portal service (port 80)	Web UI

TLS is terminated at the ingress layer (the ingress controller or load balancer), not by the application. Terminate HTTPS there with a valid certificate for the Portal hostname.

Built-in Ingress (traefik)

The chart's built-in Ingress targets traefik: it sets ingressClassName: traefik and a traefik entrypoint annotation. This is the convenient default for traefik environments, including a local k3s cluster, which ships traefik as its ingress controller. Enable it with:

ingress:
  enabled: true

Ingress on a non-traefik cluster

The built-in Ingress defaults to traefik (ingressClassName: traefik and a plain-HTTP entrypoint), which suits the bundled k3s path but not a managed cluster serving the Portal over HTTPS behind an OIDC provider. It exposes values so you can point it at your own controller and terminate TLS without replacing it:

ingress:
  enabled: true
  className: alb              # your controller's class (alb, nginx, ...)
  annotations:                # your controller's annotations, replacing the traefik default
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
  host: conncentric.example.com
  tls:                        # omit when TLS terminates at the load balancer (for example ALB with ACM)
    - secretName: conncentric-tls
      hosts: [conncentric.example.com]

That keeps the chart routing /api and /actuator to the Orchestrator and / to the Portal, now through your controller with TLS.

Bring your own Ingress

If you need an Ingress the chart does not manage (unusual routing, or a manifest your platform team owns), set ingress.enabled: false and provide your own:

ingress:
  enabled: false

Route the three paths to the two platform Services, terminating TLS for the Portal hostname at your controller:

Path	Service	Port
/api, /actuator	conncentric-orchestrator	8080
/	conncentric-portal	80

The Service names follow the <release-fullname>-orchestrator and <release-fullname>-portal pattern, which resolves to conncentric-orchestrator and conncentric-portal with the chart's default name. Confirm the exact names in your namespace with kubectl get svc -n conncentric before applying.

The two manifests below are illustrative starting points, not chart output. The chart does not create or manage them. Adapt the hostname, certificate reference, and annotations to your environment, then apply them yourself with kubectl apply -f. List the /api and /actuator rules before the / rule so the more specific paths are matched first.

Example: AWS Load Balancer Controller (ALB)

Here TLS is terminated at the ALB using a certificate from AWS Certificate Manager, referenced by the certificate-arn annotation, so no tls: block is needed.

# ILLUSTRATIVE EXAMPLE. Adapt to your environment; not produced or managed by the chart.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: conncentric
  namespace: conncentric
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:<region>:<account-id>:certificate/<cert-id>
spec:
  ingressClassName: alb
  rules:
    - host: conncentric.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: conncentric-orchestrator
                port:
                  number: 8080
          - path: /actuator
            pathType: Prefix
            backend:
              service:
                name: conncentric-orchestrator
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: conncentric-portal
                port:
                  number: 80

Example: NGINX Ingress

Here TLS is terminated at the controller using a certificate held in a Kubernetes Secret named by the tls: block. Provision that Secret yourself (for example with cert-manager) before applying.

# ILLUSTRATIVE EXAMPLE. Adapt to your environment; not produced or managed by the chart.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: conncentric
  namespace: conncentric
  annotations:
    cert-manager.io/cluster-issuer: <your-cluster-issuer>   # or attach the cert another way
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - conncentric.example.com
      secretName: conncentric-portal-tls
  rules:
    - host: conncentric.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: conncentric-orchestrator
                port:
                  number: 8080
          - path: /actuator
            pathType: Prefix
            backend:
              service:
                name: conncentric-orchestrator
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: conncentric-portal
                port:
                  number: 80

Point a DNS record at the controller's external address once it is provisioned, and attach the certificate there. A common production pattern is to turn the built-in Ingress off and front these paths with your cloud's load balancer controller, for example the AWS Load Balancer Controller with an ALB.

What your networking team needs to do

• Point a DNS record at the Ingress controller's external IP or load balancer hostname.
• Ensure port 443 (HTTPS) is open from your users' network to the Ingress controller.
• Provision and attach a TLS certificate (via cert-manager, cloud-native certificate services, or manual configuration on the Ingress controller).

TCP acceptor ports

When an adapter is configured as an acceptor (listening for inbound connections from external counterparties), it needs a TCP port exposed outside the cluster. The platform handles this through a configurable port range on a LoadBalancer Service.

How port allocation works

1. The Helm chart defines a port range (default: 6700-6750) and creates a Kubernetes LoadBalancer Service exposing every port in that range.
2. When you configure an adapter as an acceptor through the Portal, the Orchestrator allocates a port from this range.
3. The external counterparty connects to the LoadBalancer IP on the allocated port, and Kubernetes routes the traffic to the adapter pod running that session.

Helm configuration

adapter:
  networking:
    portRange:
      enabled: true
      start: 6700
      end: 6750
  service:
    type: LoadBalancer

Set portRange.enabled: false if your deployment only uses initiator-mode adapters and does not accept inbound connections.

For deployments where a cloud load balancer is not available or not desired, set adapter.service.type to NodePort and configure your external load balancer or firewall to forward traffic to the node ports.

Production load balancer configuration

The acceptor endpoint must have a stable IP or hostname. Counterparties whitelist and hard-code it, so a load balancer that changes address when it is recreated will break their sessions. A bare type: LoadBalancer provisions your cloud's default balancer with a dynamic address (and on AWS a classic ELB, which is not ideal for raw TCP). Pass your provider's Service annotations to select the right balancer and a stable address. The chart forwards these fields as-is, so it stays cloud-neutral:

adapter:
  service:
    type: LoadBalancer
    annotations:
      # AWS: internet-facing NLB with pre-allocated Elastic IPs (stable address)
      service.beta.kubernetes.io/aws-load-balancer-type: external
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
      service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
      service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-aaaa,eipalloc-bbbb
    externalTrafficPolicy: Local     # preserve the counterparty source IP
    loadBalancerSourceRanges:        # restrict inbound to known counterparties
      - 203.0.113.10/32

GCP and Azure use their own Service annotations for the equivalent (a network/TCP load balancer with a reserved static IP); consult your provider's cloud-controller documentation. If you prefer to manage the load balancer outside the chart, set adapter.service.type to ClusterIP or NodePort and front the acceptor ports with a load balancer you provision yourself, giving it a static IP.

What your networking team needs to do

This is the most important section for production deployments with acceptor connections. The platform does not configure any external networking. Your networking team must:

1. Open the port range (default 6700-6750) on the firewall between external counterparties and the LoadBalancer or node IPs.
2. IP whitelisting: restrict inbound access to known counterparty IP ranges. Use Kubernetes NetworkPolicies, cloud security groups, or your organization's firewall rules. The platform does not enforce IP restrictions.
3. VPN or private connectivity: if your security policy requires counterparty connections to traverse a VPN, private link, or dedicated circuit, configure this at the network layer. The platform connects to whatever IP and port are reachable from the adapter pod.
4. Provide the connection details to counterparties: the external IP (from the LoadBalancer Service) and the allocated port number. The counterparty's connectivity team needs these to configure their end.

Verifying acceptor connectivity

From inside the cluster, confirm the port is listening:

kubectl exec -it <adapter-pod> -n conncentric -- nc -zv localhost <port>

From outside the cluster, confirm the LoadBalancer is reachable:

nc -zv <loadbalancer-ip> <port>

If a check fails, use this matrix:

Symptom	Likely cause	Action
nc to localhost <port> fails from inside the pod	The adapter is not listening: it is disabled, has not claimed a session, or portRange.enabled is false	Confirm the adapter is enabled and has claimed a session in the Portal, and that adapter.networking.portRange.enabled is true.
Reachable from inside the pod but not from outside the cluster	The LoadBalancer has no external address, or a firewall or security group blocks the port	kubectl get svc -n conncentric and confirm an external IP is assigned; confirm your security group or firewall allows inbound on the port range.
Counterparty connects from the wrong source IP, or sessions drop after a load-balancer recreate	externalTrafficPolicy is not Local, or the acceptor address is not stable	Set externalTrafficPolicy: Local to preserve the source IP, and pin a stable address (see Production load balancer configuration above).

Internal traffic

Within the cluster, platform components communicate over ClusterIP Services:

Source	Destination	Port	Purpose
Adapter pods	Orchestrator	8080	Lease heartbeats, session claims, plugin downloads
Installer job	Orchestrator	8080	Manifest and plugin uploads

The Orchestrator API is also accessible externally through the same Ingress as the Portal. The Ingress routes /api and /actuator paths to the Orchestrator, and the Portal (running in the user's browser) calls these API endpoints. This means the Orchestrator API is protected by the same HTTPS and OIDC authentication as the Portal, not by network isolation.

Use Kubernetes NetworkPolicies to restrict direct access to the Orchestrator ClusterIP Service to only pods within the Conncentric namespace. External access should only be possible through the Ingress.

See also

• Prerequisites for the full network port matrix.
• Security for the platform attack surface diagram and access control patterns.
• Helm Reference for the complete list of networking-related Helm values.
• FIX Adapter Operations for FIX-specific acceptor configuration.