Information Disclosure
Learn about information disclosure in Kubernetes.
We'll cover the following
Information disclosure is when sensitive data is leaked. Common examples include hacked data stores and APIs that unintentionally expose sensitive data.
Protecting cluster data
The entire configuration of a Kubernetes cluster is stored in the cluster store (usually etcd). This includes network and storage configuration, passwords, the cluster CA, and more. This makes the cluster store a prime target for information disclosure attacks.
As a minimum, we should limit and audit access to the nodes hosting the cluster store. As we’ll see in the next paragraph, gaining access to a cluster node can allow the logged-on user to bypass some security layers.
Kubernetes v1.7 introduced encryption of Secrets but doesn’t enable it by default. Even when this becomes the default, the data encryption key (DEK) is stored on the same node as the Secret! This means gaining access to a node lets us to bypass encryption. This is especially worrying on nodes that host the cluster store (etcd nodes).
Fortunately, Kubernetes 1.11 enabled a beta feature that lets us store key encryption keys (KEK) outside our Kubernetes cluster. These types of keys are used to encrypt and decrypt data encryption keys and should be safely guarded. We should seriously consider Hardware Security Modules (HSM) or cloud-based Key Management Stores (KMS) for storing our key encryption keys.
Keep an eye on upcoming versions of Kubernetes for further improvements to encryption of Secrets.
Protecting data in Pods
As previously mentioned, Kubernetes has an API resource called a Secret that is the preferred way to store and share sensitive data such as passwords. For example, a front-end container accessing an encrypted back-end database can have the key to decrypt the database mounted as a Secret. This is far better than storing the decryption key in a plain-text file or environment variable.
It is also common to store data and configuration information outside of Pods and containers in Persistent Volumes and ConfigMaps. If the data on these is encrypted, we should store the keys for decrypting them in Secrets.
Despite all of this, we must consider the caveats outlined in the previous section relative to Secrets and how their encryption keys are stored. We don’t want to do the hard work of locking the house but leaving the keys in the door.
Get hands-on with 1400+ tech skills courses.