etcd Encryption
The only supported method for encrypting some data [1] in etcd on OpenShift 4 is aescbc [2].
This method requires that the encryption keys are stored in plain text on the nodes hosting the Kubernetes API server.
For OpenShift 4 the Kubernetes API server and etcd are hosted on the same nodes.
Due to that, enabling etcd encryption provides negligible benefits, since an attacker who can access etcd data at rest will be able to access the encryption keys as well in most scenarios.
A few scenarios to consider:
-
An attacker with
cluster-adminrights in Kubernetes doesn’t even notice whether etcd is encrypted or not, since the contents which are encrypted at rest in etcd are still returned in "plain text" by the Kubernetes API. -
An attacker with node access to a node hosting an etcd replica has access to the encryption keys in plain text on the node, and so encrypting etcd doesn’t prevent data exfiltration in that case.
-
Since OCP4 backs up the encrypted etcd together with the encryption keys in plaintext to simplify disaster recovery [3], an attacker who manages to get unauthorized access to an etcd dump (For example by accessing the backup S3 bucket), automatically also gets access to the encryption keys. Note that our (VSHN) cluster backups are encrypted by the backup solution we’re using (K8up / restic) and the encryption key for the backups is stored in a Hashicorp Vault instance.
VSHN-internal reference: OpenShift 4 Encrypted etcd.