Description
The historical kube-apiserver insecure HTTP port handled API requests without TLS, authentication or authorization. If it is open and reachable, it can provide unauthorized access to the control plane. Actual reachability also depends on the bind address and network path.
--insecure-port became ineffective in Kubernetes 1.20 and was removed in 1.24. Do not add this flag to current versions; check actual listeners and the upgrade plan for remaining legacy environments.
Potential impact
A client reaching the insecure port may read cluster data or change workloads without the normal API protections. Plaintext communication also lacks protection for the confidentiality and integrity of transmitted data.
Remediation
- In legacy versions that support this option, disable the insecure port with
--insecure-port=0. - First move dependent clients to an API endpoint protected by TLS and appropriate authentication and authorization.
- Verify that the insecure port is closed, required administration works and unapproved requests are denied. Upgrade to a supported version.
Examples
These excerpts compare historical Kubernetes 1.6 options. They do not recommend using this image or removed flags for a current deployment.
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-port=1143"
This configures the legacy API server to use insecure HTTP port 1143. Changing only the bind address does not disable the port.
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 disables the insecure port in versions that supported it. Prepare TLS certificates, authentication, authorization and client connections separately.