Incomplete etcd TLS client certificate settings in kube-apiserver

Description

When the API server authenticates to etcd with a certificate, configure both --etcd-certfile and --etcd-keyfile. Supplying only one leaves that client authentication configuration incomplete and can prevent a connection.

The client certificate pair is separate from the CA used to verify the etcd server. Specifying both files alone does not complete mutual authentication.

Potential impact

• Failed etcd connections can disrupt API server operation.
• Bypassing authentication or server verification to restore connectivity can weaken protection of control plane data.

Remediation

• Set --etcd-certfile and --etcd-keyfile to a valid matching certificate and private key.
• Configure HTTPS etcd endpoints and --etcd-cafile, and configure etcd to trust the API server’s client certificate.
• Check file mounts, permissions and expiry, then test authenticated connectivity after the change.

Examples

These historical excerpts show Kubernetes 1.6.0 arguments. Use a supported version and actual mounted certificate files.

Before

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
spec:
  containers:
    - name: command-demo-container
      image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
      command: ["kube-apiserver"]
      args: ["--etcd-keyfile=/path/to/key/file.key"]

Only the private key is specified. The pair needed for certificate-based client authentication is incomplete.

After

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
spec:
  containers:
    - name: command-demo-container
      image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
      command: ["kube-apiserver"]
      args: ["--etcd-keyfile=/path/to/key/file.key", "--etcd-certfile=/path/to/cert/file.crt"]

The client certificate and private key are specified together. HTTPS endpoints and CA trust on both sides still need separate configuration.

References

• CWE-287
• Kubernetes kube-apiserver reference