Description
--client-cert-auth=false alone does not establish that etcd client certificate authentication is disabled. In etcd 3.4, specifying --trusted-ca-file also enables HTTPS client certificate authentication. Review the actual CA and HTTPS configuration together.
etcd stores critical cluster data, so access control matters. Manage client certificate authentication together with the required data-access permissions.
Potential impact
Unauthorized parties with network access may not be distinguished by client certificates. If other authentication and permission controls are also insufficient, they may gain access to critical data, alter it or disrupt service.
Remediation
- Set
--client-cert-auth=trueand--trusted-ca-file, and provide trusted certificates and keys to approved clients. - Configure the server certificate, key and HTTPS addresses, and make clients verify the server certificate.
- Restrict data permissions and network access, and verify successful approved connections and rejection of invalid certificates.
Examples
These excerpts compare arguments from a historical etcd version. Actual deployments also require HTTPS addresses, a server certificate and key, a trusted CA and client certificates.
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: ["--client-cert-auth=false"]
The argument is false, but actual authentication also depends on the trusted CA and HTTPS settings. This excerpt alone does not establish that certificate authentication is disabled.
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: ["--client-cert-auth=true"]
This requires client certificate verification. Configure the trusted CA and certificate files as well; the argument alone is not a complete TLS deployment.