Description
To use a managed TLS server certificate in etcd, configure both --cert-file and --key-file. TLS configuration can fail if the private key corresponding to the certificate is missing.
etcd handles critical cluster data, so manage matching certificates and keys, file permissions and renewal. Check that the actual connection addresses use HTTPS as well as specifying the files.
Potential impact
Certificate or key errors can prevent server startup or client connections. Switching to unencrypted connections to avoid those failures can expose data on the network path.
Remediation
- Set
--cert-fileand--key-fileto a matching server certificate and private key. - Mount the files at their actual paths, restrict private-key read permissions, and configure HTTPS listening and connection addresses.
- Configure client CA verification and any required client authentication separately, and verify certificate renewal and actual connections.
Examples
These excerpts compare certificate and key arguments in a historical etcd version. Actual deployments also require a supported version and HTTPS addresses; replace the example file paths with actual values.
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: ["--cert-file=/etc/env/file.crt"]
Only a server certificate is specified, without its private key, leaving the manual TLS configuration incomplete.
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: ["--cert-file=/etc/env/file.crt", "--key-file=/etc/env/file2.key"]
This specifies both the server certificate and key. Verify that the files match and check their permissions and HTTPS addresses; file paths alone do not complete transport protection.