I assume you are concerned about containerized applications running as root.
root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.
Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability
SYS_ADMIN that is needed for
mount. However, avoid root in container whenever possible to minimize risks.
If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option
--user UID:GID in
But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.
I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/
For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.
Apart from that, you can reduce container capabilities to improve container security. Use option
--cap-drop=xyz and drop everything your container does not need. Or even better, use
--cap-drop=ALL and add only capabilities that are really needed with e.g.
--cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
Another option to improve container security is