Skip to main content
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 27017: 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:
  • 27017 (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 27017: 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

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.
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 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:
PortProtocolDescription
6443TCPKubernetes API server
8285UDPFlannel
8472UDPFlannel

​
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:
PortProtocolDescription
10250TCPKubelet API
8285UDPFlannel
8472UDPFlannel

​
Port Access Between Kubernetes Master Servers

For connections between Kubernetes Master servers, the following ports must be open between all Master Nodes:
PortProtocolDescription
6443TCPKubernetes API server
2379-2380TCPetcd server client API
10250TCPKubelet API
10257TCPKube-controller-manager
10259TCPKube-scheduler
8472UDPFlannel
8285UDPFlannel
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

PortProtocolDescription
32080TCPDefault NodePort for API Management Console access
30180TCPDefault NodePort for API Portal access
30080TCPDefault NodePort for Apinizer API Gateway access (different ports can also be used if multiple environments will be installed)
30090TCPApinizer API Gateway alternative port

​
Ports for MongoDB Servers

PortProtocolDescription
27017TCPMongoDB standard port
25080TCPApinizer configuration database port

​
Ports for Elasticsearch Servers

PortProtocolDescription
9200TCPApplication port of the Analytics server where API Traffic logs are written
9300TCPElasticsearch Transport port (intra-cluster communication)

​
Port and Protocol Requirements Summary

​
DMZ → LAN Communication

SourceDestinationPortProtocolDescription
WorkerManager8080HTTPConfiguration retrieval
WorkerMongoDB27017TCPData read/write
WorkerMongoDB25080TCPApinizer configuration database
WorkerElasticsearch9200HTTPLog sending
WorkerCache5701TCPCache access

​
LAN → DMZ Communication

SourceDestinationPortProtocolDescription
ManagerWorker8080HTTPDeployment operations
ManagerWorker8080HTTPHealth check

​
Internet → DMZ Communication

SourceDestinationPortProtocolDescription
InternetLoad Balancer443HTTPSAPI access
InternetLoad Balancer80HTTPHTTP → 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.