Description
The legacy kube-apiserver insecure HTTP listener processed API requests without TLS, authentication or authorization protections. --insecure-bind-address selected its address; actual exposure depended on whether the insecure port was enabled and where it listened. Loopback still leaves access to anyone able to reach that local path.
This flag became ineffective in Kubernetes 1.20 and was removed in 1.24. Use protected API endpoints on supported releases.
Potential impact
- A principal reaching the insecure listener can misuse administrative APIs without permission checks.
- Clients depending on the old HTTP path may be interrupted during migration to protected connections.
Remediation
- Prepare an API path protected by TLS, authentication and authorization, then migrate existing clients.
- On historical versions that support the insecure listener, disable it with
--insecure-port=0. Removing only the bind-address flag does not close the port. - Migrate to a supported release and inspect actual listeners and network access to verify that no insecure path remains.
Examples
These excerpts compare historical Kubernetes 1.6 options and are not a current deployment recommendation. TLS certificates and the remaining control-plane configuration are required separately.
Before
apiVersion: v1
kind: Pod
metadata:
name: api-server
spec:
containers:
- name: kube-apiserver
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command:
- "kube-apiserver"
- "--insecure-bind-address=127.0.0.1"
This binds an enabled insecure listener to 127.0.0.1. That address does not itself imply internet exposure, but local HTTP access lacks authentication and authorization.
After
apiVersion: v1
kind: Pod
metadata:
name: api-server
spec:
containers:
- name: kube-apiserver
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command:
- "kube-apiserver"
- "--insecure-port=0"
This explicitly disables the insecure port on that historical version. Verify that required clients connect through the protected API path.