Network Topology and Port Requirements

You can learn about the network topology and port requirements necessary for secure installation of the Apinizer platform. You can configure DMZ and LAN zones, define firewall rules, meet Kubernetes and Apinizer component port requirements, and apply secure deployment patterns.

Network topology and port requirements are critical for secure installation of the Apinizer platform. This section provides detailed information about secure deployment patterns, firewall zones, Kubernetes port requirements, Apinizer component ports, and access requirements for installation.

Firewall Zones

DMZ Zone (Demilitarized Zone)

DMZ is a secure network zone that is open to the external world but isolated from the internal network.

Components Running in DMZ:

Worker Nodes

API Gateway components:

• Proxy Handler
• Token Provider API
• Local Cache

Port Requirements:

• 443/80 (HTTPS/HTTP) - Client access
• 30080/30090 (NodePort) - Apinizer API Gateway
• 32080 (NodePort) - Manager access

Load Balancer

Traffic distribution:

• HAProxy / Nginx
• SSL/TLS termination
• Health check

Port Requirements:

• 443/80 (HTTPS/HTTP) - External access
• 30080/30090 (Backend) - Access to Workers

DMZ Security Rules:

• Inbound:

  • Port 443/80: From Internet to Load Balancer
  • Port 22: SSH (optional, recommended via VPN)

• Outbound:

  • Port 8080: To Manager (LAN)
  • Port 25080: To MongoDB (LAN)
  • Port 9200: To Elasticsearch (LAN)
  • Port 5701: To Cache (LAN)
  • Port 443: To External APIs (Backend)

LAN Zone (Local Area Network)

LAN is the secure internal network zone. It cannot be accessed from the external world.

Components Running in LAN:

Manager Module

Management and configuration:

• Web Manager
• Analytics Engine
• Monitoring & Alerting
• Scheduled Jobs

Port Requirements:

• 8080 (HTTP) - Web Manager
• 8080 (Management API) - Access from Workers

MongoDB

Database:

• Configuration data
• Metadata
• Audit logs

Port Requirements:

• 25080 (MongoDB) - From Manager and Workers
• 25080 (Apinizer DB Port) - Apinizer configuration database

Elasticsearch

Log and analytics:

• API traffic logs
• Analytics data

Port Requirements:

• 9200 (HTTP) - From Manager and Workers
• 9300 (Transport) - Cluster communication

Cache Cluster

Distributed cache:

• Hazelcast cluster
• Shared cache data

Port Requirements:

• 5701 (Hazelcast) - Cluster communication

LAN Security Rules:

• Inbound:

  • Port 8080: From DMZ to Manager
  • Port 25080: From DMZ to MongoDB
  • Port 25080: From DMZ to MongoDB (Apinizer DB)
  • Port 9200: From DMZ to Elasticsearch
  • Port 5701: From DMZ to Cache
  • Port 22: SSH (via VPN)

• Outbound:

  • Port 443: To external services (optional)
  • Port 53: DNS queries

Network Segmentation

Network Segmentation Best Practices

VLAN Configuration

Recommended VLAN Structure:

• VLAN 10: DMZ Zone
• VLAN 20: LAN Zone (Manager)
• VLAN 30: LAN Zone (Database)
• VLAN 40: Management Network (SSH, Monitoring)

This structure enables isolation of network traffic and facilitates security controls.

Subnet Configuration

Recommended Subnet Structure:

• DMZ: 10.0.1.0/24
• LAN (Manager): 10.0.2.0/24
• LAN (Database): 10.0.3.0/24
• Management: 10.0.4.0/24

Each subnet should have its own firewall rules and access policies.

Routing Rules

Routing Configuration:

• From DMZ to LAN: Only necessary ports open
• From LAN to DMZ: Management access
• From Internet to DMZ: Only Load Balancer
• From LAN to Internet: Restricted access

Kubernetes Port Requirements

Addresses to Access for Installation

Internet access to the following addresses is required for Kubernetes and Apinizer installation:

• archive.ubuntu.com, security.ubuntu.com / cdn.redhat.com
• *.docker.com
• *.docker.io
• *.k8s.io
• *.amazonaws.com (Kubernetes documentation)
• *.mongodb.org
• *.mongodb.com
• artifacts.elastic.co

Note: These port accesses have been checked and approved for Kubernetes 1.31.0 and Flannel 0.27.4 version. Ports may vary for different Kubernetes and Flannel versions.

Port Access from Kubernetes Worker Servers to Master Servers

For Kubernetes Worker Nodes to communicate with Master Nodes, the following ports must be open from all Worker Nodes to Master Nodes:

Port	Protocol	Description
6443	TCP	Kubernetes API server
8285	UDP	Flannel
8472	UDP	Flannel

Port Access from Kubernetes Master Servers to Worker Servers

For connections from Kubernetes Master/Control Plane servers to Worker servers, the following ports must be open from all Master Nodes to Worker Nodes:

Port	Protocol	Description
10250	TCP	Kubelet API
8285	UDP	Flannel
8472	UDP	Flannel

Port Access Between Kubernetes Master Servers

For connections between Kubernetes Master servers, the following ports must be open between all Master Nodes:

Port	Protocol	Description
6443	TCP	Kubernetes API server
2379-2380	TCP	etcd server client API
10250	TCP	Kubelet API
10257	TCP	Kube-controller-manager
10259	TCP	Kube-scheduler
8472	UDP	Flannel
8285	UDP	Flannel

Important: If applications such as Ingress Controller, Metric Server, Rancher, Lens will be used or if Kubernetes will be installed in a cloud environment, port requirements should be checked externally.

Kubernetes High Availability (HA) Cluster

When setting up a Kubernetes High Availability (High Availability) Cluster:

Load Balancer VIP Access:

On Kubernetes Master/Control Plane and Worker servers, necessary permissions should be defined to access the Load Balancer’s VIP on port 6443. This VIP performs load balancing by routing to port 6443 of Master nodes.

HAProxy Load Balancer Example Configuration:

frontend kubernetes-cluster
    bind *:6443
    mode tcp
    option tcplog
    default_backend kubernetes-master

backend kubernetes-master
    option httpchk GET /healthz
    http-check expect status 200
    mode tcp
    option ssl-hello-chk
    balance roundrobin
    server <master1hostname> <MASTER_1_IP>:6443 check fall 3 rise 2
    server <master2hostname> <MASTER_2_IP>:6443 check fall 3 rise 2
    server <master3hostname> <MASTER_3_IP>:6443 check fall 3 rise 2

VIP Access Rules:

SOURCE: <KUBERNETES_CONTROL_PLANE_IP_ADDRESSES> <KUBERNETES_WORKER_IP_ADDRESSES>
DESTINATION: <VIRTUAL_IP>
6443/tcp

ROUTING: <KUBERNETES_CONTROL_PLANE_IP_ADDRESSES> tcp/6443

If desired, a DNS can also be defined for this routing virtual IP. SSL will be created during installation from one of the servers and communication will be established with it. SSL control will not be performed on the system performing routing. This SSL will be renewed annually via Kubernetes.

Apinizer Component Port Requirements

Kubernetes uses ports in the 30000-32767 range by default for external access. Although specific default ports are used for Apinizer, these can be customized as needed.

Ports for Worker Servers

Port	Protocol	Description
32080	TCP	Default NodePort for API Management Console access
30180	TCP	Default NodePort for API Portal access
30080	TCP	Default NodePort for Apinizer API Gateway access (different ports can also be used if multiple environments will be installed)
30090	TCP	Apinizer API Gateway alternative port

Ports for MongoDB Servers

Port	Protocol	Description
25080	TCP	MongoDB standard port
25080	TCP	Apinizer configuration database port

Ports for Elasticsearch Servers

Port	Protocol	Description
9200	TCP	Application port of the Analytics server where API Traffic logs are written
9300	TCP	Elasticsearch Transport port (intra-cluster communication)

Port and Protocol Requirements Summary

DMZ → LAN Communication

Source	Destination	Port	Protocol	Description
Worker	Manager	8080	HTTP	Configuration retrieval
Worker	MongoDB	25080	TCP	Data read/write
Worker	MongoDB	25080	TCP	Apinizer configuration database
Worker	Elasticsearch	9200	HTTP	Log sending
Worker	Cache	5701	TCP	Cache access

LAN → DMZ Communication

Source	Destination	Port	Protocol	Description
Manager	Worker	8080	HTTP	Deployment operations
Manager	Worker	8080	HTTP	Health check

Internet → DMZ Communication

Source	Destination	Port	Protocol	Description
Internet	Load Balancer	443	HTTPS	API access
Internet	Load Balancer	80	HTTP	HTTP → HTTPS redirect

Port Access Permission Request Template

Port access request template prepared for communication to network and security teams:

Port Access Requests for Kubernetes Master and Worker Servers:

SOURCE: <KUBERNETES_WORKER_IP_ADDRESSES>
DESTINATION: <KUBERNETES_CONTROL_PLANE_IP_ADDRESSES>
6443/tcp
8285/udp
8472/udp

---
SOURCE: <KUBERNETES_WORKER_IP_ADDRESSES>
DESTINATION: <MONGODB_IP_ADDRESSES>
25080/tcp

---
SOURCE: <KUBERNETES_WORKER_IP_ADDRESSES>
DESTINATION: <ELASTICSEARCH_IP_ADDRESSES>
9200/tcp

---
SOURCE: <KUBERNETES_CONTROL_PLANE_IP_ADDRESSES>
DESTINATION: <KUBERNETES_WORKER_IP_ADDRESSES>
10250/tcp
8285/udp
8472/udp

---
# If there is no free access between Kubernetes Control Plane servers
SOURCE: <KUBERNETES_CONTROL_PLANE_IP_ADDRESSES>
DESTINATION: <KUBERNETES_CONTROL_PLANE_IP_ADDRESSES>
6443/tcp
2379:2380/tcp
10250/tcp
10257/tcp
10259/tcp
8472/udp
8285/udp

Note: All default ports can be changed, but in this case, operations and permissions should be done carefully.

Security Layers

Defense in Depth Strategy

Apinizer is protected with a layered security approach:

Layer 1: Network Firewall
    │
    ▼
Layer 2: Application Firewall (WAF)
    │
    ▼
Layer 3: TLS/SSL Encryption
    │
    ▼
Layer 4: API Security Policies
    │
    ▼
Layer 5: Data Encryption & Masking

Security Controls

Network Layer

• Firewall rules
• Network segmentation
• VLAN isolation
• DDoS protection

Transport Layer

• TLS/SSL encryption
• Certificate management
• mTLS (mutual TLS)
• Perfect Forward Secrecy

Application Layer

• OAuth2 / JWT authentication
• Rate limiting
• IP whitelisting
• API key management

Data Layer

• Data encryption at rest
• Data masking in logs
• PII redaction
• Audit logging

Security Best Practices

Critical Security Rules:

1. Never place MongoDB and Elasticsearch in DMZ
2. Never place Manager module in DMZ
3. Always use TLS/SSL (in production)
4. Always configure firewall rules with least privilege principle
5. Always perform regular security updates
6. Always correctly configure Kubernetes port requirements

Security Checklist

• DMZ and LAN separation is implemented
• Firewall rules are configured with least privilege principle
• TLS/SSL certificates are configured
• MongoDB and Elasticsearch are in LAN
• Manager module is in LAN
• Worker modules are in DMZ
• Load Balancer is in DMZ
• Network segmentation is implemented
• Kubernetes port requirements are configured
• Apinizer component ports are configured
• Internet access for installation is provided
• DDoS protection is active
• Log monitoring and alerting are configured
• Regular security updates are planned

Important: This secure deployment pattern must be used for production environments. DMZ/LAN separation is critical for security and compliance requirements. The system will not work if Kubernetes and Apinizer port requirements are not correctly configured.