Introduction

As described in Serverless (FaaS) a serverless architecture has many benefits, such as autoscaling and better utilization of resources. Because the core idea of serverless is to not have to worry about any infrastructure, which includes managing virtual machines, and focus only on writing code, the infrastructure has to be managed by a third party, normally a cloud provider. However, the cloud provider has the complete control over the network and all systems, where the serverless functions or containers are deployed on. Thus, the same problems and threats mentioned in Threat Model arise. By combining serverless with confidential computing, the benefits of serverless can be leveraged without having to trust the cloud provider, while protecting the workload from a potential adversary.

But not only the customer benefits from confidential serverless containers, the cloud provider does also. Customers could possibly have malicious intends and want to infiltrate the cloud providers infrastructure. Therefore a strong isolation of customers code is a requirement. It is well-known that isolation provided by containers alone, is often not enough to stop an adversary. This is evidenced by the following blog post, which describes the discovery of two vulnerabilities in Azure Functions, Azure's serverless framework, that lead to the escape of the Docker container containing the function and, if exploited, allow remote code execution.

Here, features of confidential computing come in handy as the code is completely isolated from the rest of the system. This provides isolation that is enforced by hardware. As opposed to isolation by software, as is the case with containerization, using only features of the kernel, hardware isolation is less prone to bugs. Software isolations must take into account many more factors and often result in very complex software. With increasing complexity, this gives more space for bugs. In contrast, isolation by hardware can be granted more easily. In addition, hardware features providing the isolation can be made completely inaccessible for running software and only an attacker with access to the actual hardware could do harm here. Software isolation functionality must reside in RAM, and since any software on the system can access and attack data in the RAM, malicious software has the ability to attack the isolation. The core strength of a TEE is that higher-privileged software cannot break into the TEE, rather than the code not being allowed to break out. However, a cloud provider can also protect his software with confidential computing achieving strong isolation.

The goal of Morphisms is to make it easy to deploy, so that potential developers don't have to worry about using confidential serverless containers.