Architecture Comparison

Assuming that both confidential computing technologies have no vulnerabilities, both architectures have their use cases. They are not directly comparable because they provide different security features. Confidential Knative provides strong isolation capabilities by putting the KMS, queue proxy, activator, and each serverless container in its own TEE at the expense of performance. This significantly reduces the potential attack surface compared to the SEV architecture. However, an increase in security often means a decrease in performance, as shown in the benchmarks. This is due to the fact that a TEE must be created for each serverless container that is launched.

The SEV architecture, on the other hand, puts multiple serverless containers in a single TEE (cVM) and provides less security, as shown in the security analysis. The SEV architecture is very performant, with almost the same performance as if SEV were not present. If container startup time is relevant, the SEV architecture should be used. For an admin managing the entire architecture, especially the KMS, does not really need to be aware that SEV is used. Thus, management is easier.

If the Kubernetes control plane isn't trusted, as is the case with a cluster managed by the cloud provider, only confidential Knative can be used securely because the control plane is untrusted in its threat model.

In most cases, the SEV architecture provides enough security because it already excludes the cloud provider and an attacker, but it has a larger attack surface. Escaping a serverless container results in controlling multiple serverless containers, and controlling the control plane results in controlling all serverless containers. This is not the case for the confidential SGX; if a serverless container infects the guest OS by issuing a system call that exploits a vulnerability in the guest OS, for example, no other enclaves should be affected because the guest OS is distrusted in the SGX threat model.