Architecture

Every serverless container needs atleast one HTTP endpoint to which incoming requests are forwarded from the queue-proxy in Knative Serving. Not only the code inside the enclave has to be protected, but also all incoming and outgoing traffic of the enclave. Due to the fact that the system software is able to read all data and code during the initialization process of the enclave, all sensitive information, e.g. secrets and illnesses, enter the enclave via network traffic. Therefore it is necessary to employ only TLS endpoints to keep network communication integrity safe and confidential.

In the context of Knative a problem arises here. Currently Knative does not support TLS passthrough to the serverless container. Knative modifies the HTTP headers in incoming requests, to share metrics across achitectural components. With TLS enabled, this is impossible because of integrity and confidentiality protection of the transferred message. One option, which Knative allows is TLS termination at the gateway. This has the consequence that on the way from the gateway to the TEE the entire data traffic runs over HTTP. Thus, passive attacks, such as sniffing, or active attacks, such as manipulating data traffic, could be carried out without compromising Knatives architectural components, but enables to share metrics via HTTP headers for Knative. Another option, currently still work in progress, is to enable HTTPS for communication between Knatives architectural components. Here, the queue-proxy and activator of Knative, which are the components, that could be possibly in the request path, establish a TLS connection to each other, including with the gateway. After modifying the headers, the request is forwarded to the next component in the request path via TLS. Although this reduces the attack surface, as all traffic is transferred via TLS, an attacker is still able to read or modify the traffic, when she is in control of either the gateway, the queue-proxy or the activator. One possible solution is to implement an end-to-end encryption protocol inside every SECS, but this strictly requires code modifications to the SECS, which is not compatible with the goal of ease-of-deployment and transparency .