If you’ve ever jumped up in bed, worrying that your private keys may be disclosed or deepened your frown lines over hackers gaining access to your sensitive data and apps, you know how scary container security can be. There must be a better way to secure your Transport Layer Security (TLS) keys than using Kubernetes* Secrets.
Ferdinand Zilcher, Presales Engineer, SUSE* and Sakari Poussa, Cloud Software Engineer, Intel might have a solution to bring you ease of mind with the deployment of Kubernetes device plug-ins for Intel® Software Guard Extensions (SGX) and Intel® QuickAssist Technology (QAT), packaged and installable from Rancher by SUSE.
Kubernetes clusters consist of control planes and nodes. Communication between the administrator, the control plane and the nodes, within the pods and from external pods, all use TLS encryption. TLS requires certificates and these certificates require private keys.
The guidance for storing keys is to use the Kubernetes Secrets mechanism. However, by default, Secrets only encodes keys, it doesn’t encrypt them. They can be trivially read using base64 decoding, by anyone with API access or access to etcd*, or anyone authorized to create a pod in a namespace can use that access to read any Secret in that namespace.
Poussa describes Intel® Software Guard Extensions (Intel® SGX) as “a technology that reduces the attack surface via enclaves. The app is built with the untrusted and trusted parts and defines the API to the enclave and application. When it starts, it creates the enclave. And only the app can call the Enclave API, nobody else.” In the traditional model, the attack surface is relatively large. There’s the operating system, virtualization and the hardware. All of those can provide hackers access to app data. In the SGX model, only the app can access the enclaves that it owns.
It’s not a banal problem to solve: You need to keep the private keys hidden, require all the apps that need the keys to have access to them, do it without requiring modification for all the apps, and, finally, offer a way to hide the keys.
Intel SGX can help, Poussa says. “In our case it's an Istio* service mesh asking certificates from certificate authority that's storing its signing keys inside the SGX enclave. There's no modification to Istio itself. The certificate authority is an Intel open source project called Trusted Certificate Service. This is a Kubernetes certificate signing service where private keys are stored and used inside the Intel Software Guard Extensions enclave. It works as a cert manager, external issuer, or a standalone service. It also has plug-in mechanisms for external system integration. It comes with an Apache* 2.0 license and requires a third-generation Intel® Xeon® processor or later.
Next step: deploy a Kubernetes cluster on Azure* using Rancher by SUSE. You simply select and install several components through the charts interface, generate certificate key pairs, store them in the SGX enclave and update the Istio configuration. Finally, you can check to see that the secret isn’t visible to outside eyes.
Check out how it works in this 10-minute demo or let us show you at booth P13, KubeCon EU 2023.