Network Topology and Port Requirements
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:
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
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:
Management and configuration:
- Web Manager
- Analytics Engine
- Monitoring & Alerting
- Scheduled Jobs
Port Requirements:
- 8080 (HTTP) - Web Manager
- 8080 (Management API) - Access from Workers
Database:
- Configuration data
- Metadata
- Audit logs
Port Requirements:
- 25080 (MongoDB) - From Manager and Workers
- 25080 (Apinizer DB Port) - Apinizer configuration database
Log and analytics:
- API traffic logs
- Analytics data
Port Requirements:
- 9200 (HTTP) - From Manager and Workers
- 9300 (Transport) - Cluster communication
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.comartifacts.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
- Firewall rules
- Network segmentation
- VLAN isolation
- DDoS protection
- TLS/SSL encryption
- Certificate management
- mTLS (mutual TLS)
- Perfect Forward Secrecy
- OAuth2 / JWT authentication
- Rate limiting
- IP whitelisting
- API key management
- Data encryption at rest
- Data masking in logs
- PII redaction
- Audit logging
Security Best Practices
Critical Security Rules:
- Never place MongoDB and Elasticsearch in DMZ
- Never place Manager module in DMZ
- Always use TLS/SSL (in production)
- Always configure firewall rules with least privilege principle
- Always perform regular security updates
- 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.