For many development tools I find it useful to install them in a container and do builds and testing inside that. With a bit of wrapper script to assemble the rapidly growing command-line it is not too hard to run even GUI (X-windows) applications like an IDE in them.
However, giving the user access to the system docker daemon instance effectively gives them root permissions, because they can run a container as root and mount any part of the host filesystem in it. On developer machines that's generally not a problem as the principal user has full sudo permissions already anyway, but on some shared machines it might be.
Now runc, the tool under docker that actually creates the containers, is capable of running a non-root, using a userns and subusers. However that does not provide anything for downloading the images from repositories and managing them. And the Docker daemon can be configured to run as specific user, but not to start containers as the user requesting them.
So is there any way in which any user on a system could run containers as themselves with subusers, but still had access to registries?
I've seen tools to build containers under these conditions, e.g. img, that does run runc under the hood with subusers, but unless I missed something it does not have a convenient way to also run and manage the built containers. Presumably the assumption is they will contain system services, but I want to use containers as canned environments for specific user tasks instead.
You could use podman instead of docker, it is able to be run by ordinary users without escalated privileges. The only thing you may need to set up (as root) before using it is subuid/subgid mapping (see installation notes). CLI of this tool is similar to Docker's one (podman pull, podman run, etc.), and it is able to consume Docker registries as well.
There are some limitations for rootless containers, but in most cases, this is perfectly enough.