Why is this an issue?

Exposing administration services increases the attack surface of a container deployment. Administration services like SSH, VNC, or RDP may contain vulnerabilities, hard-coded credentials, or other security weaknesses. Modern container technologies provide built-in management capabilities that make running dedicated administration services inside containers unnecessary.

Kubernetes provides kubectl exec to run commands inside a container, kubectl logs to access container logs, and kubectl cp to transfer files, making SSH and similar services unnecessary.

What is the potential impact?

Lateral movement within the container network

Even when an administration service port is not forwarded to the host, it is by default reachable from other containers on the same network. A malicious actor who compromises one container can exploit exposed administration services to pivot to other containers across the deployment.

Unauthorized external access

When an administration service port is forwarded to the host system or exposed through an external load balancer, it becomes reachable from outside the container environment. An attacker can exploit vulnerabilities or weak credentials in services such as SSH to gain direct access to the container or the underlying host system.

How to fix it

Do not run administration services in Kubernetes pods or expose their ports through services. Use kubectl exec to run commands inside a container, kubectl logs to access container logs, and kubectl cp to transfer files. These tools make SSH and similar services unnecessary. Note that simply removing containerPort or hostPort is not sufficient. A running administration service remains accessible from other pods on the same cluster network.

Kubernetes exposes administration service ports at three severity levels:

containerPort on a pod is informational and does not forward the port to the host; however, the service is still reachable from other pods on the same cluster network.
hostPort on a pod maps the container port directly to the host’s network interface, making it reachable from the host and any client that can reach it.
A Service of type LoadBalancer or NodePort with an administration targetPort exposes the port externally, making it reachable from outside the cluster.

Code examples

Noncompliant code example

apiVersion: v1
kind: Pod
metadata:
    labels:
        app: example_app
spec:
  containers:
    - name: applications
      image: example_image
      command: ["/usr/sbin/sshd", "-f", "/etc/ssh/sshd_config", "-D"]
      ports:
      - containerPort: 22  # Noncompliant

apiVersion: v1
kind: Pod
metadata:
    labels:
        app: example_app
spec:
  containers:
    - name: applications
      image: example_image
      command: ["/usr/sbin/sshd", "-f", "/etc/ssh/sshd_config", "-D"]
      ports:
      - containerPort: 22
        hostPort: 22  # Noncompliant

apiVersion: v1
kind: Service
metadata:
  name: example_lb
spec:
  type: LoadBalancer
  ports:
    - port: 22
      targetPort: 22  # Noncompliant
  selector:
    app: example_app

Compliant solution

apiVersion: v1
kind: Pod
metadata:
    labels:
        app: example_app
spec:
  containers:
    - name: applications
      image: example_image

apiVersion: v1
kind: Pod
metadata:
    labels:
        app: example_app
spec:
  containers:
    - name: applications
      image: example_image

apiVersion: v1
kind: Service
metadata:
  name: example_lb
spec:
  type: LoadBalancer
  selector:
    app: example_app