Uhm, a container is nothing else then a fenced process on the host kernel, limited by Namespaces (isolated process areas) , Capabllities (permissions) and CGroups (ressource).
Thus said, #1 will require a bunch of extra capabilities if you didn’t implement the encyption directly in your application. This will weaken the isolation and have an impact regarding when the user manges to escape the container.A simpler approach to protect data amongst users is to rely on UID:GID of your customer applications and the volumes they use for persisted data. Pick distinct IDS per customer and you should be good… Unless they managed to exploit the non privileged user and become root…
When it commes to #2: this is not going to be that easy. Docker ce is not capable to do so, unless you implement your own wrapper that verifies permissions before it delegates the actual calls to the docker socket/port.
Just an Idea:
In Kubernetes user management is intended to be handled outside the cluster (people usual cheat by using service accounts instead), for instance with oidc providers. You could create namespaces per customer and define required role mappings or audience tokens in your oidc token to grant permissions to perform actions on the namespace. Though, never had the situation to have “sub-admins” that add/delete role mappings for oidc users inside a single realm (which your kubernetes cluster would be a client in). You should give it a thought to move to kubernetes.