I do this for my containers. I have a completely domain-managed network, so my docker/podman host mounts an NFS share that contains all the data volumes for my services. Each one only has read permissions for the service account that runs it (and has nogroup). Each OCI container mounts their data volume(s) from their respective directory as well as a kerberos user TGT and credentials cache. Each OCI container runs as the service account, which uses the kerberized credentials to access the mounted data volumes (this is necessary), and thus I acheive separation. Even if a threat actor were to compromiee a service they would still be locked down to that service account and only able to access/modify the data of this service. This is still be very bad for services like keycloak, but for other trivial services it almost guarantees more than adequate segregation. This does fall apart a little bit with the recent copyfail and dirtyfrag exploits which allow for easy privilege escalation, but I don’t allow root squash so the data volumes on the NFS share are still service_account:nogroup even when accessing as root. Now an attacler could go through and use the KRBTGTs that are stored for each service account to access the data, but at that point I am dealing with a dedicated threat actor. Defending against someone explicitly seeking to compromise me is a different situation altogether, and still requires initial access through a vulnerable application that is sitting behind an SSL termination proxy and an NGFW with IPS capabilities.