You selected this article probably wondering how do you use Intel® Software Guard Extensions (Intel® SGX) without code changes, and more importantly how does it secure the service mesh communication?
Doesn’t Intel SGX require a programmer to purposefully design an application in two parts, where one part is designed to run in an encrypted memory enclave? Wouldn't that be hard to do with a service mesh like Istio*? Can't you just turn on mutual Transport Layer Security (TLS) for your service mesh and secure your communication that way? Yes you can, but the privacy of your entire service mesh depends upon the secrecy of its private key that signs the certificates used in communication. If compromised, an intruder could decrypt, observe, and monitor your service mesh.
How can someone gain access to your service mesh private key? Typically, that private key is imported to the service mesh and is stored as a base64-encoded Kubernetes* secret. Anyone with kubectl admin access can read it with a simple kubectl get secret my-private-key -o json and then do a base64 decode. Kubernetes does have support for using a key management service (KMS) to manage the key, which avoids having to store it in a secret.
What if there was a way to securely store your service mesh private key inside the cluster? What if it was easier to use and didn’t require rewriting software or rebuilding your container images? This is where Intel SGX and the trusted certificate service solution (cert-manager external issuer) provide protection. This solution uses hardware-based memory encryption to store the service mesh private key. All code signing is done in this encrypted enclave. Someone with administrative access to the host system who has tools to snoop on network traffic or to read from memory only sees encrypted memory.
How It Works
The key part of the solution is the trusted certificate issuer that implements the k8s Certificate Signing Request APIs, which matured to V1 in Kubernetes release v1.19. The issuer creates an enclave, loads the key signing code, and attests the enclave is valid. Once established, the certificate authority (CA) key is created or imported in the enclave. All future certificate signing happens within the enclave, with no visibility from the outside. This is done transparently. You do not have to read an Intel SGX manual or rewrite any code. The trusted certificate issuer does all the hard work and the installation is one command: kubectl apply -f trusted-certificate-service.yaml. Istio facilitates configuring an external CA, such as cert-manager or the previous trusted certificate issuer, to handle all certificate signing. The code is open source and available at GitHub*.
This is all made possible with Intel SGX support included in a 3rd generation Intel® Xeon® platform. Your Kubernetes* cluster infrastructure provider handles back end details such as attestation and using the Intel SGX device plug-in. The plug-in controls the number of enclaves and the containers that may use them per node. Here are each of the steps in greater detail.
- Start the trusted certificate issuer pod. After it fully starts, the enclave is created. The key generation and signing code are initialized into it. The private key is then created within the enclave, which is protected by encryption.
- Configure your service mesh to use an external CA for key signing. This is done by setting the service mesh to use the trusted certificate issuer. Once started, the service mesh directs all the certificate signing requests (CSRs) to the trusted certificate issuer.
- Once Istiod is running, start a pod with auto injection set to enabled. This ensures that each pod automatically starts a side car container to serve as proxy, which could be Envoy* or any other Istio proxy. The proxy generates its own key pair and then requests Istiod to sign the certificate with the service mesh private key.
- The previous certificate signing request that istiod initiated is then passed to the trusted certificate service operator issuer to sign, which holds the signing key inside its enclave, never exposing it at any time. The signed certificate is then returned through Istiod to the proxy, enabling it to start communicating securely on the service mesh.
Figure 1. Setup for a trusted certificate issuer with a certificate signing flow
All pods (regardless of language) go through the same process to sign their self-generated certificates. The service mesh uses the private key stored in the encrypted enclave for signing all certificates, making your service mesh more secure.
Figure 2. Service mesh with the trusted certificate issuer
The trusted certificate issuer is just the beginning. Later in the year, Intel is making the attestation controller open source, which includes remote Intel SGX attestation and key management capabilities. Used together, these two components create an easier to use, end-to-end, and secure CA private key management solution: a trusted certificate service for Kubernetes.
The trusted certificate issuer supports confidential compute, encrypting the service mesh private key while in use and at rest, and makes your service mesh communications more secure.
Forward-Looking Statements. Statements in this material that refer to business outlook, plans, and expectations are forward-looking statements that involve risks and uncertainties. Words such as "anticipate," "expect," "intend," "goal," "plans," "believe," "seek," "estimate," "continue," "committed," "on-track," "positioned," "ramp," "momentum," "roadmap," "path," "pipeline," "progress," "schedule," "forecast," "likely," "guide," "potential," "next gen," "future," "may," "will," "would," "should," "could," and variations of such words and similar expressions are intended to identify such forward-looking statements. Statements that refer to or are based on estimates, forecasts, projections, uncertain events or assumptions, including statements relating to Intel’s strategy and its anticipated benefits; business plans; financial projections and expectations; total addressable market (TAM) and market opportunity; manufacturing expansion and investment plans; future manufacturing capacity; future products, technology, and services, and the expected availability and benefits of such products, technology, and services, including product and manufacturing plans, goals, timelines, ramps, progress, and future product and process leadership and performance; future economic conditions; future impacts of the COVID-19 pandemic; plans and goals related to Intel’s foundry business; future legislation; future capital offsets; pending or future transactions; the proposed Mobileye IPO; supply expectations including regarding industry shortages; future external foundry usage; future use of EUV and other manufacturing technologies; expectations regarding customers, including designs, wins, orders, and partnerships; projections regarding competitors; ESG goals; and anticipated trends in our businesses or the markets relevant to them, including future demand, market share, industry growth, and technology trends, also identify forward-looking statements. Such statements involve many risks and uncertainties that could cause actual results to differ materially from those expressed or implied in these forward-looking statements. Important factors that could cause actual results to differ materially are set forth in Intel's earnings release dated January 26, 2022, which is included as an exhibit to Intel's Form 8-K furnished to the SEC on such date, and in Intel's SEC filings, including the company's most recent reports on Forms 10-K and 10-Q. Copies of Intel's SEC filings may be obtained by visiting our Investor Relations website at www.intc.com or the SEC's website at www.sec.gov. All information in this presentation reflects management's views as of February 17, 2022, unless an earlier date is indicated. Intel does not undertake, and expressly disclaims any duty, to update any statement made in this presentation, whether as a result of new information, new developments or otherwise, except to the extent that disclosure may be required by law.
Intel technologies may require enabled hardware, software or service activation. No product or component can be absolutely secure. Your costs and results may vary. Product and process performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex and www.Intel.com/ProcessInnovation. Future product and process performance and other metrics are projections and are inherently uncertain.
© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.