APP.4.4.A20

[sluetze]

No description provided.

[ermeratos]

The file systems containing the persistent data of the control plane (etcd in particular in this context) and the application services SHOULD be encrypted.

There are different approaches to achieve encryption.

• Encryption of etcd can be activated from within ACM using a policy
• Use of FIPS 140-2 certified encryption modules

fips_mode_enabled_on_all_nodes
api_server_encryption_provider_cipher (for additional information on how to check if etcd encryption is enabled)

[ermeratos]

Maybe only manual check?

[benruland]

The two suggested policies sound good to check.

For application data, I do not see a good way to check that.

[sluetze]

I would only check

rules:
  - api_server_encryption_provider_cipher

FIPS mode only means, that the encryption libraries used for encryption (IF you use encryption) are certified. FIPS is a US Government standard. While some German & European institutions might think it is more secure or safe to use FIPS mode, this is not a default. I guess more than 95% of customers wont use FIPS mode. As BSI does not require this, I would not add this as check to avoid confusion.

The Requirement only states that etcd SHOULD be encrypted, not that it must be encrypted using a specific method or encryption library.

additionally some info from my analysis of etcd encryption in openshift

From my understanding, https://docs.openshift.com/container-platform/4.14/security/encrypting-etcd.html describes how to enable etcd. encryption. this only encrypts keys, of some types (configmap, secrets and so on). The encryption is transparent for the kube-apiserver. So the only place where the encryption really gives a “protection” is when someone is directly accessing etcd or an etcd backup (if you store the key separately).
to directly access etcd (in a standard openshift cluster) i need a key and cert and either access to the podnetwork (access to the nodes), or the ability to forward a port (oc port-forward). the keys are stored with root:root 600 perms on the master/etcd nodes. So i need root permissions on the master node to be able to directly connect to etcd. If I have root access on the master node, i dont care about etcd encryption, because I have access to the apiserver with the keys lying next to the etcd keys or can just impersonate kubelet and access the kubernetes api (Also the encryption keys are there as well if I am not using a KMS).
The other possibility to access etcd would be through the etcd pods or the etcdctl container in openshift itself. To do this, I need permissions to that - normally etcd pods are only available to clusteradmins, so someone accessing etcd this way does not need to use etcdctl and can query the apiserver anyway.
so the only undisputable benefit of etcd encryption would be if an attacker finds the etcd backup. Otherwise if he has access to etcd he already has access to apiserver which makes the encryption transparent anyway.
Do I miss something?

[ermeratos]

I agree sluetze. The rule you mentioned should be enough for implementation.

Any suggestions for testing the correct behaviour, since activating/deactivating encryption isn't trivial?

[sluetze]

ComplianceAsCode#11997 was merged, closing