There is little benefit to doing this, this containerized root user is not truly root. Under Docker (by default) the container still runs as (the real) root regardless of the user used within the container.

The only benefit from doing this would be to avoid this "root" user from running amok within the container itself if the application were to be compromised. But if the app was compromised to allow for remote execution switching to the root user should be trivial.

But if the app was compromised to allow for remote execution switching to the root user should be trivial.

Can you elaborate?

this containerized root user is not truly root

That's quite big misconception - that user is true root, just running with strict seccomp profile. I'd say there's a bigger chance for sandbox escape when app is run as root, compared to setting up an unprivileged user and using that.

While Docker does support user namespaces now, this feature is still not enabled by default - now that'd make this addition unnecessary.

Setting up a separate non-privileged user is low hanging fruit, so it does not hurt to do this. https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-2-set-a-user

There is little benefit to doing this, this containerized root user is not truly root. Under Docker (by default) the container still runs as (the real) root regardless of the user used within the container.

The only benefit from doing this would be to avoid this "root" user from running amok within the container itself if the application were to be compromised. But if the app was compromised to allow for remote execution switching to the root user should be trivial.

If it is a container running as root without "userns-remap" then the root inside it is the actual root user.

Thanks!