Networking, Firewalls, and DNS
Private network and CIDR rules
Place all machines on one private routed network, for example 10.10.0.0/20. Any
non-overlapping private CIDR is suitable if the same CIDR is recorded as
ceph.nodesSubnet in the install configuration.
Provide unrestricted communication between Codesphere hosts on the private network. Kubernetes, Ceph, PostgreSQL, container registry, and SSH traffic all cross this network. If internal firewalls must be restrictive, derive and test an explicit port matrix for the selected Kubernetes and Ceph versions before installation.
Hosts without public addresses need outbound access through NAT or an HTTP proxy. They must be able to reach package repositories, the selected container registry, certificate endpoints, and any source URLs referenced by the installer.
Avoid CIDR overlap between the host network, Kubernetes pod network, Kubernetes service network, connected corporate networks, and VPNs.
Configure external access and firewalls
Reserve three stable external addresses and connect them to Kubernetes
LoadBalancer services using the infrastructure's load-balancer implementation:
- The platform gateway serves HTTP and HTTPS.
- The public workspace gateway serves workspace HTTP and HTTPS traffic.
- The workspace SSH proxy serves SSH traffic for workspaces.
On a public cloud, install and configure that provider's Kubernetes cloud controller or load-balancer integration. On bare metal or other infrastructure without a native implementation, configure MetalLB with an address pool containing the reserved addresses. The addresses must remain stable across service and node restarts. See Gateway and load balancing. If the integration can be completed only after Kubernetes is running, finish it in Complete the infrastructure integration.
Apply these boundary firewall rules:
| Source | Destination | Ports | Purpose |
|---|---|---|---|
| Trusted administrator networks | Jumpbox | TCP 22 | Administration |
| Internet | Platform gateway | TCP 80, 443 | Codesphere UI and API; ACME HTTP-01 when used |
| Internet | Workspace gateway | TCP 80, 443 | Hosted workspaces and custom domains |
| Internet | Workspace SSH proxy | TCP 22 | Workspace SSH |
| Codesphere private network | All Codesphere hosts | All required internal traffic | Kubernetes, Ceph, PostgreSQL, registry, and SSH |
| Codesphere hosts | Internet or approved proxies | Required outbound traffic | Packages, images, certificates, and integrations |
Do not expose SSH or PostgreSQL to 0.0.0.0/0. PostgreSQL TCP 5432 normally needs to
be reachable only from Codesphere hosts and approved administration or monitoring
networks.
DNS records
Three stable external addresses map to four DNS records. The platform gateway serves both the bare base domain and the datacenter-specific domain; only the wildcard under the datacenter-specific domain routes to the workspace gateway:
| Record | Kubernetes service | Target |
|---|---|---|
<base-domain> | gateway-controller | Platform gateway IP |
<dc-id>.<base-domain> | gateway-controller | Platform gateway IP |
*.<dc-id>.<base-domain> | public-gateway-controller | Workspace gateway IP |
<dc-id>.ssh.<base-domain> | ssh-workspace-proxy | Workspace SSH proxy IP |
These records are created as part of Encrypt the secrets and configure DNS, once the addresses are known. Plan the DNS zone and delegation now so that step is not blocked later.
Certificate options
Choose a certificate issuer for the platform: a self-signed CA, an organization CA,
or ACME (DNS-01 or HTTP-01). See
Cluster ingress CA options for the
supported certIssuer types and their vault requirements. If using ACME, ensure the
DNS zone supports the chosen solver, or that TCP 80 reaches the platform gateway for
HTTP-01.
Next
Continue to Provision the hosts.