edgelesssys / contrast

Deploy and manage confidential containers on Kubernetes
https://docs.edgeless.systems/contrast
GNU Affero General Public License v3.0
161 stars 6 forks source link

coordinator: don't share CA instance with gRPC servers #520

Closed burgerdev closed 3 weeks ago

burgerdev commented 4 weeks ago

At a high-level, this PR

The idea is that the methods called by the gRPC servers on the CA instance are always coupled to the current active manifest, thus getting the manifest from meshAuthority and the certificates from CA is inherently racy (think of concurrent calls to SetManifest and NewMeshCert, for example). This is a first step towards tighter coupling of the two, by handing out CA objects when required and removing the permanent members.

In the meshAPI server, I'm moving all certificate operations to the ValidateCallback, and all certificate operations happen on the same CA instance. This does not make a practical difference now, but allows to swap out the permanent CA object with one per manifest generation.

In the userAPI server, I'm adding the CA as a return to the manifest retrieval operation, also in preparation to swap it out in the future.

The API of the Authority should be considered transitory while we're working on the persistence. I could imagine it returning a struct with manifest and CA combined.

The race conditions are still present (see associated TODOs), but it should be easier to mitigate them going forward.