Introducing Attested Containers
Cedric Xing and Dan Middleton
If you wanted to protect your workload with Confidential Computing, what would you prioritize? Well of course you’d want to keep your workload protected during execution. You would want to keep it isolated from anything else in the same environment. But what if your workload involves multiple processes? How do you enable the flexibility to have multiple processes while still restricting the environment to only those trusted processes? What if you were also engaged with multiple parties and/or someone else was operating the workload on your behalf? Before trusting it, you would want to know exactly what was and what wasn’t running. You would want to know its security state before sharing anything sensitive or trusting any of its outputs, e.g., sending healthcare information, sending ML training data, receiving pricing information, or receiving inference results.
These were the main questions we had in mind when creating the Attested Containers project – ACon for short – which we recently released to open source. Attestation is a big topic these days with the rapid growth of Confidential Computing. Attestation provides you with a cryptographic measurement of the security state of your environment and helps us satisfy some of the goals above. Additionally, we want to make sure that the protection provided by ACon works naturally with containerized workloads, because containers are one of the most popular ways to package software.
Typically, containers are deployed through orchestration frameworks which are huge topics unto themselves. Some recent orchestration frameworks have designed-in Confidential Computing directly, e.g., Edgeless Systems Constellation, CNCF Confidential Containers, and Azure ACI. ACon doesn’t try to reimplement orchestration. Our goal is to plug into orchestration as simply as possible. Generally speaking, existing frameworks provide you with the first degree of Confidential Computing benefits. They help you protect a Confidential Computing oblivious workload, i.e., the program and sometimes dependent systems don’t know whether or not these security features are in play. ACon moves from passive to active use of Confidential Computing. If you’re familiar with one of these frameworks think of ACon as a trusted guest with some new features. Otherwise, you can think of ACon as a security container for your container with some important utilities.
ACon lets you specify a security policy for your workload. How much do you want to delegate to a Cloud Service Provider (CSP) or another managed Kubernetes (K8s) provider? Which other programs do you trust if any? Based on this policy, ACon will assess each container you authorize to launch and store the measurement in hardware protected registers. These registers are more resilient to attack by container escapes than if we stored them in guest memory. Moreover, the registers can be remotely interrogated at any point in time using attestation. This attestation lets you know that you are working with your trusted workload AND very importantly that this is the only thing running. Let’s say your workload comprises five containers that run together. The ACon attestation will tell you whether those five containers were loaded into a virtual machine protected by Confidential Computing, and that nothing else was loaded. Those facts tell you that a system admin, for example, didn’t side load some other logging tool or replace a binary. If you are relying on someone else operating the workload, you’ll have evidence whether they are running it in the agreed upon manner.
But wait there’s more… : - D
Often, one of the goals of using Confidential Computing is removing the CSP from your trust boundary. However, if you are using a CSP, you may want services like automatically updating underlying frameworks used by serverless functions. ACon helps you reconcile these two goals to limit the risk of CSP adversaries and the benefit of the CSP providing up-to-date components. Specifically, ACon provides the flexibility to delegate dependency maintenance to the another party such as the CSP. Let’s consider the example of a Python application. Your container includes your Python module and the Python interpreter. By default, your ACon security policy defines the hash of your Python module and the hash of a concrete Python interpreter. However, ACon optionally allows you to list the CSP’s public key instead of the hash of the interpreter. As a result, your workload trusts this dependency layer if it is signed by the CSP. This allows the CSP to keep the dependency up to date, but everything else is still restricted. Delegation is an active decision and one reflected in the attestation evidence.
We hope ACon serves as a useful reference for others trying to fulfill similar requirements. The container-centric architecture and optional features like delegated trust make ACon practical to adopt. While the purpose built security components and remote attestation of hardware protected registers adds assurance for security sensitive workloads. Whether you just find some useful ideas, sections of code, or the entire architecture appealing we hope you benefit from this open source project.
About the Authors
Cedric Xing is a Cloud Software Architect in the Security Architecture and Technology group at Intel Corporation focusing on confidential computing, including both TDX and SGX based applications. He is the chief architect of Attested Containers (ACON) and a key contributor to the Intel SGX SDK and related libraries and tools. He is also a contributor to the TDX/SGX ISA and researches on innovative TDX and SGX based solutions for Cloud security. He has dozens of patents in security and attestation in ISA, BIOS, OS, VM, device I/O, and other areas.
Dan Middleton is a Principal Engineer with over 20 years at intel. He has been privileged to develop and release products in emerging areas including SaaS, Computational Imaging, Blockchain, and Confidential Computing. As an open source leader, he has represented Intel in projects including the Confidential Computing Consortium, The Open Source Security Foundation, CNCF CoCo, and Hyperledger. Dan currently leads Confidential Computing pathfinding in Intel's Security Software and Services division.
Dan Middleton is a Principal Engineer with over 20 years at intel. He has been privileged to develop and release products in emerging areas including SaaS, Computational Imaging, Blockchain, and Confidential Computing. As an open source leader, he has represented Intel in projects including the Confidential Computing Consortium, The Open Source Security Foundation, CNCF CoCo, and Hyperledger. Dan currently leads Confidential Computing pathfinding in Intel's Security Software and Services division.