etcd automatic TLS is enabled

Description

--auto-tls=true makes etcd generate self-signed certificates for client connections. It can encrypt communication, but this automatic configuration alone does not authenticate the other endpoint.

etcd stores critical Kubernetes data. In production, establish trust with a managed CA and certificates, and retain certificate verification.

Potential impact

Without endpoint verification, an attacker controlling the connection path may impersonate the other party. Certificate issuance, renewal and trust scope may also fail organizational requirements.

Remediation

• Prepare managed certificates, keys and HTTPS connections before removing --auto-tls=true or setting it to false.
• Configure clients to verify the server certificate against a trusted CA, and configure client authentication where needed.
• Manage certificate expiry and renewal, and verify successful intended connections and rejection of untrusted certificates.

Examples

These excerpts compare arguments from a historical etcd version. Actual deployments also need a supported version, HTTPS addresses, mounted certificate files and the remaining configuration.

Before

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-etcd-deployment
spec:
  template:
    spec:
      containers:
        - name: database
          image: gcr.io/google_containers/etcd:v3.2.18
          command: ["etcd"]
          args: ["--auto-tls=true"]

This selects automatically generated self-signed certificates. Encryption and endpoint authentication are separate requirements.

After

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-etcd-deployment
spec:
  template:
    spec:
      containers:
        - name: database
          image: gcr.io/google_containers/etcd:v3.2.18
          command: ["etcd"]
          args: []

This only removes the automatic TLS argument. It does not configure TLS by itself; provide managed certificates, keys and HTTPS settings as well.

References

• CWE-311
• etcd transport security guide