Kubernetes didn’t always have RBAC (Role-Based Access Control), or any access control beyond simple authentication. Long ago, every user on a cluster was trusted completely and had perfect visibility into everything that the cluster was doing. As we began to add RBAC to Kubernetes, I remember thinking that it marked a significant moment in Kubernetes’ transition to running “real” workloads. While the addition of RBAC added security to the resources represented in the Kubernetes API, it didn’t do anything to protect the workloads themselves. Starting today and looking to the future of Kubernetes, the integration of confidential computing technologies with Kubernetes will enable security for customer workloads, just as the addition of RBAC secured access to the cluster itself.
Users around the world are increasingly using Kubernetes for their cloud native development and digital transformation — the Cloud Native Computing Foundation’s 2019 survey found 78% of respondents are using Kubernetes in production, a huge jump from 58% in 2018. All of these different users have various needs that drive their tech intensity forward and motivate their digital transformation. But nearly every user needs different teams, systems, and organizations to collaborate and build data-driven, secure solutions.
Confidential computing is an industry-changing technology that is a cornerstone for data security and privacy. Organizations have long struggled to access the digital market at scale because of regulations such as GDPR, potential trade secrets leakage, and concerns around data loss. These concerns introduce complex and lengthy contracts, legal concerns, and root of trust connected to people managing the IT systems when migrating to the cloud.
Protecting and securing the data is especially important when the data or application leaves the organization, whether moving to the cloud or a partner location. When running in a multi-application environment like analytics data processing or modern microservice architectures and Kubernetes, the issues of data protection and privileged data access are especially important.
Enter Confidential Computing
Confidential computing provides data-in-use protection assurances using a hardware-based Trusted Execution Environments (TEE) to increase security guarantees for the executing code and the data in memory, which has not been available until now. It removes the layers you need to trust and protects the application and data from unauthorized access or modifications from system admins, service providers, or infrastructure providers.
With this TEE environment the application and the owner of the data is in full control of who can see, execute, and compute on the data. Having a defense-in-depth strategy for protecting the applications and data through confidential computing enables new possibilities such as rich data collaboration between multiple parties, secure key management, in-memory databases, and fast and secure blockchains, to name a few.
To enable trusted collaboration between organizations or internal teams, one must redact or anonymize the data which often minimizes insights. The data preparation process is often costly due to time spent, people errors, and stripping down data to a bare minimum, all leading to low impact insights.
With confidential computing, organizations can now bring rich data and code to the cloud for processing at scale. In order to protect the code and data through execution, confidential computing uses attestation of hardware and software-based components, and data decryption keys are released only to the trusted applications after footprint validation.
Traditional methods cannot achieve this level of privacy and code protection.
Cloud Native Computing and Containers
In the cloud native and containers space, we often see organizations build machine learning (ML) models or data processing models that are proprietary. The proprietary software packaged as containers needs to be protected for any misuse, especially while they are stored in the registry or when mounted to a host. This is especially true when we consider the importance of the responsible use of AI and ensuring that our models are used safely and fairly. In Azure, we have enabled this trusted multiparty rich data simulation through “confidential containers.” Let’s take a look at how they work.
With confidential computing, “you no longer have to trust the administrators or operators of a cluster in order to securely run high intellectual property data, like machine learning models, within a Kubernetes cluster.”
Confidential computing reduces the attack surface for applications and protects against vulnerabilities in the guest operating system, hypervisor or host operating system layers. This means that a container using confidential computing can run on the same host as a compromised container and protect its data.
In the context of Kubernetes, this means that you no longer have to trust the administrators or operators of a cluster in order to securely run high intellectual property data, like machine learning models, within a Kubernetes cluster.
When an application’s code runs within a secure enclave, the memory used in the enclave and the executing code itself cannot be accessed by anyone other than the application itself. This provides three important properties to help secure your containers.
First, it provides hardware isolation between containers running on the same host. No matter how malicious, different containers running on the same virtual machine cannot access data secured by a TEE. Even if a container uses a kernel-level exploit to take over the guest operating system within the hypervisor, data inside the TEE enclave is secure.
Second, the enclave can provide code integrity via container encryption, signing and attestation which ensures that only trusted code is running inside the enclave itself. This protects against malicious attacks that attempt to modify the running code within the container via stack smashing or other exploits.
And third, confidential computing provides secure key release for data decryption trust attached to hardware and initiation parameters. Using this data protection you can ship models or other proprietary data to code running in an untrusted customer environment and have strong assurances that the data can only be accessed within the context of a secure trusted execution environment. This could be especially useful for scenarios that require multiple untrusted parties to collaborate with each other.
Putting these capabilities together means that businesses can develop strong trust that their code and data are secure, even while building dynamic, microservice-based applications. Cloud native computing is all about developing scalable microservices for agility and packing those services onto shared clusters for maximal efficiency. But these optimizations cannot come at the price of security and fortunately, with the addition of confidential computing to the world of cloud native computing, they don’t have to.
Confidential Computing and the Open Source Community
Of course, another critical component of cloud native development is open source. Through the development of the Kubernetes project we have seen the power of community and the value of coming together as an industry to advance the state of the art. The same open efforts are underway in confidential computing.
I’m pleased that Microsoft, along with IBM, Red Hat, Alibaba, Google, Intel and others were founding members of the Confidential Computing Consortium (CCC). There are now seven open projects within the CCC, including OpenEnclave SDK, a hardware abstraction layer that makes it possible to develop for confidential containers without binding tightly to a particular hardware implementation.
Broadly speaking, the CCC is interested in solving problems that will help advance the state of the art in confidential and cloud native application development. The first is the development of tools and SDKs that make it easier for developers to take advantage of confidential computing as they are building new applications.
As you can imagine, the details of running within a trusted execution environment can be complex, and for a developer a daunting barrier to securing their code and data. The tools and SDKs that are being developed in the CCC aim to reduce this barrier to entry and enable a broad set of developers to be able to use confidential computing within their applications. Security should never be something that is only available to developers willing to suffer complexity. If we are truly going to build applications that respect privacy and responsible data use, we have to make security, like trusted execution environments, available to all developers.
Of course, being able to easily develop with secure enclaves is great if you are building a new application. However, for legacy applications, adopting confidential computing technologies can be an almost impossible task. It may not be possible to refactor the code to take advantage of trusted execution environments, or the application may not even be one that is under current development.
To facilitate these use cases, members of the CCC are also focused on “lift and shift” tools that will enable developers and operators to deploy their containers, completely unchanged, into a secure container execution environment. Rather than requiring that applications be enlightened to understand enclaves, the entire container from image pull through execution will run within a trusted execution environment. Tools like ONNX and Graphene will truly democratize the security that confidential containers can bring to the broadest parts of the cloud native ecosystem.
This focus on both new developers and migrating existing applications has stirred a great deal of interest in the cloud native community and we’ve been thrilled with the engagement we’ve seen with partners, vendors and open source projects developing into concrete solutions for our customers. We’re very much looking forward to furthering this collaboration and making confidential containers as automatic a part of Kubernetes as RBAC has become. It’s not confidential that I’m looking forward to where this takes us!
The Cloud Native Computing Foundation is a sponsor of The New Stack.
Feature image via Pixabay.
The post Brendan Burns: Everything You Need to Know About Confidential Computing and Containers appeared first on The New Stack.
