- Since essentially no container platform was designed for hard multi-tenancy, use automation to stand up separate copies of a platform at scale, using a platform with low overhead in controller to worker nodes.

Consider what would be the “simplest thing that could possibly work” e.g. offering tenants an AWS autoscale group (with appropriate IAM account, user, role, security group perms) behind an AWS PrivateLink endpoint:

https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-se...

I say that, because most of these platforms weren’t intended for and are not marketed for hard multi-tenancy, until their engineers started getting asked the question by enterprises attempting it for regulatory/compliance/security reasons.

> Cloud Foundry. Multitenancy was designed in from the start...

This comment gives me pause, as CloudFoundry’s security model, approach, and engineering lacked hardness as of 3 - 4 years ago. We explored the multi-tenancy design, and found no guarantees, or even strong assurances, were brought by the platform.

The larger issue was we found CF’s security engineering assertions rather overconfident (flavor of the comment above). Warranted relative to other solutions without security features, but not relative to being hardened enough to trust in the face of bad actors, particularly malicious insiders.

My opinion is also “biased”, in the sense that unless a platform is doing work outside of “the server”, I don’t believe it can offer hard multi-tenancy.

Here’s an example of work outside the server:

https://perspectives.mvdirona.com/2019/02/aws-nitro-system/