Overview

While there are many building Kubernetes building blocks, etcd is considered the treasure chest. Etcd’s datastore will contain all information available via the API services and contains the data in an easily consume format to determine the cluster(s) states. Obtaining write privileges to etcd’s datastore or equivalent API privileges is equivalent to obtaining UID 0 privileges (root, God, Administrator, sysdba, etc…) Read privileges makes it really simple to pivot and elevate privileges across the cluster(s), workloads, and control plan components. For instance, a building block with read access to the full key space entitles this building block to operate with cluster-admin privileges. mTLS and proper network segmentation (only allow API services network connectivity to interact with etcd.). When network segmentation is lacking, I use separate etcd instances for read vs. write operations for various segments of the namespaces. Please encrypt the etcd datastore files while at rest. Preferably mount on the fly onto a RAM disk. While you are creating the RAM disk mount, might as well spin up a separate PKI service just for etcd. PKI_based authentication and parameters to use the configured x.509 certificates. One set for verifying peer connections and the other will verify apiserver to etcd connections. Run-time access protection (SELinux, AppArmor, Falco, etc..) will go a long way as there are limited, authorized workflows to handle the datastore.

Kubernetes’s secrets features are greatly lacking. Base64 is character encoding, not encryption. One will need to rely upon other secrets’ management services and architectures to bypass Kubernetes’s lacking secrets management. There are additional secrets providers that make attempts to address the none or Base64 challenges; secretbox, aesgcm, and / or cloud native providers such as KMS. There are far too many ways to mitigate this risk so the better way to think about the secrets challenge: storing the raw DEK or KEK in EncryptionConfig moderately manages secrets’ risks. Utilize an external provider, such as KMS, for additional security. Envelope encryption requires an external secret not accessible to Kubernetes. As a result, one would need to compromise where the external secret is handled, where the cryptographic operations occur, and where the cipher text resides (etcd, kubeapi-server, and kms.).

CIS Benchmark

2. ETCD

2.1 Ensure that the --cert-file and --key-file arguments are set as appropriate (Automated)

2.2 Ensure that the --client-cert-auth argument is set to true (Automated)

2.3 Ensure that the --auto-tls argument is not set to true (Automated)

2.4 Ensure that the --peer-cert-file and --peer-key-file arguments are set as appropriate (Automated)

2.5 Ensure that the --peer-client-cert-auth argument is set to true (Automated)

2.6 Ensure that the --peer-auto-tls argument is not set to true (Automated)

2.7 Ensure that a unique Certificate Authority is used for etcd (Manual)

5.4 Secrets Management

5.4.1 Prefer using secrets as files over secrets as environment variables (Manual)

5.4.2 Consider external secret storage (Manual)