Description
A Service with type: LoadBalancer can create an endpoint reachable from outside the cluster. Internet exposure depends on the cloud and controller configuration. Publishing a service intended for internal use can create an unintended access path.
Determine whether external access is required. For internal communication, consider ClusterIP or an internal-only LoadBalancer configuration first.
Potential impact
- Internal services may become directly reachable from the internet or other external networks.
- Services with weak authentication or access controls can become targets for external scanning.
- Unrecognized public routes can make security controls harder to manage.
Remediation
- Use an internal Service or internal LoadBalancer when external exposure is unnecessary.
- Apply the internal configuration supported by the installed controller, and verify the actual load balancer and access rules.
- Approve and manage public exposure only for services that require it.
Examples
The after-example annotation is for AWS controllers that support it. AWS Load Balancer Controller supports this legacy setting but gives precedence to aws-load-balancer-scheme; check the installed version's recommended settings and actual configuration.
Before
yaml
apiVersion: v1
kind: Service
metadata:
name: sample-service-public
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: LoadBalancer
selector:
app: nginx
After
yaml
apiVersion: v1
kind: Service
metadata:
name: sample-service-internal
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: LoadBalancer
selector:
app: nginx
Explanation:
- Before: Requests a LoadBalancer. Its exposure depends on controller defaults and configuration.
- After: Requests an internal LoadBalancer on a supporting AWS controller. Check other public paths and access controls as well.