PeerPods Secure Comms

[davidhadas]

Peer Pods introduce a greater attack surface on TEEs. When a TEE runs in a remote VM controlled by a CSP, new attack surface emerge as compared to running the TEE on a bare metal for example. An attacker in control of the CSP may be able to use such control to compromise the TEE confidentiality.

In an CoCo use cases that involve attestation, TEE images should include no secrets. Under such use cases, securing the communication channel between the Worker Node (WN) and the TEE, can be achieved using the following process:

1. Attestation
2. Exchanging Secrets using the KBS based on the proof provided by the attestation token from step 1.
3. Establishing a secured communication channel relying on the secrets obtained in step 2.

Once such a secured communication channel is established, it is safe to allow other sensitive communication between the WN and TEE or vice versa. In particular, the communication between the runtime and the Kata Agent can be initiated via the established secured communication channel.

It is proposed to use SSH technology and combine it with KBS based key exchange to protect communications between a Cluster and its connected Peer Pods (PP). The proposed enhancement is optional. CoCo users may still use the existing TLS based mechanism. When using mTLS, users are encouraged to consider mechanisms to ensure that WNs will not share any sensitive data with fake unattested TEEs and that PPs will not accept instructions from a fake WN.

The suggested change:

1. Use a single connection between the WN and PP to carry all required communications between WN and a PP
2. The connection is initiated from a WN client to a PP service. WN need not expose any service.
3. Simplify PP configuration by routing all communication from PP to WN to use local PP ports (which are then tunneled via the SSH channel)
4. Secure CoCo support services (E.g. Trusty, AS, KMS, ...) running in the K8s cluster or outside the cluster - avoid exposing such services outside of the K8s cluster. Instead, access such services from the WNs while serving PP clients via SSH tunnels
5. Use an initial Attestation Phase SSH connection to deliver Keys from Trusty to the PP
6. Use a second secured Kubernetes Phase SSH connection to deliver all other communications to/from the PP
7. Deliver Runtime requests to the Kata Agent via a tunnel during the secured Kubernetes Phase

Main advantages of the proposed solution:

• Enable serving PPs from a Cluster via firewall without exposing any required Cluster Services
• Enable securing any required communication between the Cluster and each PP using the SSH protocol
  • Resulting in a single channel between the Cluster and the PP
  • Any required tcp/udp communication is than handled using an SSH Tunnel
  • SSH Keys are secured through attestation
• Simplify PP configuration and provisioning  - services use pre-fixed configuration
• Simplify Cluster configuration and provisioning - services use pre-fixed configuration

PP Secure Comms.pdf

[davidhadas]

/assign @davidhadas