Encrypting etcd in OpenShift

Introduction

Data is the lifeblood of any OpenShift cluster, and protecting it is not just wise – it’s essential! That’s where encrypting etcd in OpenShift comes into play. OpenShift 4.13 introduces also AES-GCM encryption so you get to choose. This post discuss the how-to of encrypting etcd. As i’m sure you are aware, a secure foundation is key to a successful OpenShift deployment.

What encryption types are there in OpenShift?

AES-CBC (Cipher Block Chaining)

AES-CBC (Cipher Block Chaining) encryption is a method where each block of plaintext is XORed with the previous ciphertext block before being encrypted. In kubernetes the AES-CBC etcd encryption is padded with PKCS#7 and a 32 byte key to perform the encryption.

AES-GCM (Galois/Counter Mode)

AES-GCM is an authenticated encryption mode which not only encrypts the data but also computes an authentication tag. This ensures the integrity and authenticity of the data, meaning it can detect if data was tampered with. In kubernetes the AES-GCM etcd encryption is filled with a random nonce and a 32 byte key to perform the encryption.

NOTE: In OCP, both the encryption keys are rotated weekly.

What shall i select?

AES-CBC encryption encrypts data in blocks, chaining them together serially, so each encryption is dependent on the previous while AES-GCM encrypts and authenticates data, ensuring its integrity. AES-GCM is faster and more secure since the blocks are written in parallel. Each block is not dependent on the previous block and instead is encrypted by a pseudorandom value from a “stream”. This is done by having a “counter” for each block. AES-CBC is not recommended also due to CBC’s vulnerability to padding oracle attacks.

Procedure

Before you continue, please make sure you have a working backup of etcd. You can use our Backup your OpenShift etcd guide.

Enable Encryption

Access the openshift cluster as a cluster-admin permitted user

Edit the apiserver

$ oc edit apiserver

Set the etcd encryption by adding the following:

spec:
  encryption:
    type: aesgcm

Verify etcd is encrypted

$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?
(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?
(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

The output should look like:

EncryptionCompleted
All resources encrypted: routes.route.openshift.io
EncryptionCompleted
All resources encrypted: secrets, configmaps
EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

Disable Encryption

Edit the apiserver

$ oc edit apiserver

Set the etcd encryption to identity:

spec:
  encryption:
    type: identity

Summary

Encryption of etcd is a critical step in fortifying your OpenShift environment at rest, and the addition of AES-GCM encryption type in OpenShift 4.13 presents a more secure way to do that. You’ve now seen how to shield your data effectively. For those seeking further assurance and expert aid in securing OpenShift clusters, Octopus is well-equipped to provide the tailored support necessary to achieve top-tier data protection.