Review exposure of Kubernetes LoadBalancer Services

Verify that the load balancer’s actual exposure matches the service requirements.

Description

A Service of type LoadBalancer can expose a service through a load balancer in supported environments. Internet exposure depends on the provider, controller and internal load balancer settings. Publishing a service that does not need external access through a public endpoint can increase unwanted connection attempts.

Potential impact

  • Vulnerable authentication or application behavior can expose data through external connections.
  • Unnecessary external endpoints can increase the attack surface and operating cost.

Remediation

  • Use ClusterIP for services needed only inside the cluster. If a private-network load balancer is required, configure the provider’s internal load balancer option.
  • For intentionally public services, restrict source ranges, configure authentication and TLS, and verify the assigned endpoint. Review other exposure paths such as Ingress as well.

Examples

These existing examples compare Service types only. Workloads matching the selector are separate. Other Ingress or proxy configurations can still expose a ClusterIP Service.

Before

hcl
resource "kubernetes_service" "example" {
  metadata {
    name = "terraform-example"
  }

  spec {
    selector = {
      app = "my-app"
    }

    port {
      port        = 80
      target_port = 8080
    }

    type = "LoadBalancer"
  }
}

After

hcl
resource "kubernetes_service" "example" {
  metadata {
    name = "terraform-example"
  }

  spec {
    selector = {
      app = "my-app"
    }

    port {
      port        = 80
      target_port = 8080
    }

    type = "ClusterIP"
  }
}

Explanation:

  • Before: The Service uses LoadBalancer. Its actual public or internal endpoint depends on the environment.
  • After: The Service uses ClusterIP and does not directly request a load balancer.

References