Description
Binding a container port through hostPort uses a port directly on the node running the Pod. This differs from a Service NodePort, and actual reachability depends on node networking and firewalls.
Unless direct node access is required, the appropriate Service or Ingress path is easier to manage. These resources still need separately configured authentication and network restrictions.
Potential impact
- An unnecessary node-port binding can create an unintended access path.
- Workloads that need the same port on a node can conflict and face scheduling constraints.
Remediation
- If direct node-port access is not needed, remove hostPort and configure the required Service or Ingress path.
- If hostPort is required, check the actual listening port, binding address and protocol, and restrict node firewalls and access scope. Check for port conflicts during placement.
Examples
These existing nginx excerpts compare hostPort use only. Separate Services or Ingress resources are omitted; provide the required connection path and controls for the actual environment.
Before
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
hostPort: 8080
Container port 80 is bound to node port 8080. Actual external reachability depends on network controls.
After
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
The hostPort binding is removed, leaving only the container-port declaration. Configure any required service access path separately.