Design principals behind K8TRE

[manics]

Aim: start drafting some rough principles for how K8TRE will be designed. This focussed just on the design/implementation, this does not cover how we or the wider community work (that should be documented separately).

Where reasonable keep the specification generic enough and not tied to K8s. Hierarchy:

• SATRE specification
• Something lower-level than SATRE, but higher than K8TRE, to help people implement a SATRE compliant TRE that's not running on K8S
• K8TRE specification for how a K8S TRE should be built
• Actual K8TRE implementation

[vvcb]

We should include the general principles that apply to microservices architecture here as well - this is one of the reasons why we are building this on k8s in the first place. We can improve on the material here - https://lsc-sde.github.io/lsc-sde/Architecture.html . Not all of it is implemented yet at Lancs and this will definitely benefit from wider community input.

[gsvarovsky]

Let's use this doc as the baseline! I suggest we plop it wholesale into a k8tre/k8tre branch and open a PR?

[gsvarovsky]

Minor adjustments from me:

• SATRE specification
• Something lower-level than SATRE, but higher than K8TRE, to help people implement a SATRE compliant TRE that's not running on K8S
  • to me this means: if it is not necessary for K8TRE specification Statement to reference K8s, then it should not
  • so, these statements don't form a separate spec. Maybe useful to tag them for clarity, e.g. tech-neutral (edit per manics's suggestion)
  • e.g. "microservice request/response APIs should be specified with an OpenAPI document that is available from a service end-point"
• K8TRE specification for how a K8S TRE K8TRE-compliant TRE should be built
  • this is recursive, sure, but we're not specifying the only, or even necessarily the best, way to build a K8s TRE. Instead, we're specifying the rules that will allow an implementer (of a TRE or a component) to maximise their component's reusability in the K8TRE ecosystem.
• Actual K8TRE reference implementation

[manics]

Something lower-level than SATRE

Would calling this a "technology neutral" specification be appropriate?

[gsvarovsky]

so I'm suggesting we just make these statements in the K8TRE spec, but be wary of making a K8s-specific statement if the statement can be generic. I think it'll be easier to manage than by having a separate spec.

[martintoreilly]

@manics Where do you see the responsibility boundary between k8s and the host platform? Is the vision for K8TRE to deploy a full stack TRE onto a k8s service layer where all aspects of the TRE are handled by K8TRE within that k8s service layer, including all perimeter isolation for the TRE?

[manics]

I think it's potentially multi-layer, depending on how strong an isolation boundary you want
https://github.com/k8tre/k8tre/blob/68cf47d86b6f162068400926267ccc24717e54af/docs/img/K8TRE-high-level.png

As a general rule, K8TRE will define capabilities that must be implemented by the underlying Kubernetes platform, and will run on top of it. Given those capabilities K8TRE should provide enough isolation for projects for many TRE. We're also exploring what configuration options K8TRE could support for people who want more security e.g. we may look at alternative container runtimes like Kata or gVisor.

It should be fine to put additional layers around K8TRE e.g. K8TRE will support multiple projects in the same TRE, but K8TRE should be lightweight enough that it's trivial to run one K8TRE per project so each proejct has it's own dedicated Kubernets cluster and networking with additional firewalling.

One question is whether anything in K8TRE could conflict with those additional security requirements that TREs wish to add?