This reads clumsily and needs revising, but perhaps more to the point raises the issue of what role is being used at each step of a build, which speaks to the role of permissioning. This can be important for security, but also roles / permissions may be used to enforce particular behaviour in the environment itself to stop one part of the environment affecting other parts in ways that are unintended.
When it comes to best practice in DOckerfiles, there may also be arguments for layering the build file in terms associated with which user / role is supposed to be performing what step at each part of the build.
IMO the topic of running commans in a Dockerfile as different users might be beyond the scope of this work, BUT we should not leave readers without having heard about it.
https://github.com/nuest/ten-simple-rules-dockerfiles/blob/4a87e3e3ad43feacd98722f1521e500191bb17bb/ten-simple-rules-dockerfiles.Rmd#L290
This reads clumsily and needs revising, but perhaps more to the point raises the issue of what role is being used at each step of a build, which speaks to the role of permissioning. This can be important for security, but also roles / permissions may be used to enforce particular behaviour in the environment itself to stop one part of the environment affecting other parts in ways that are unintended.
When it comes to best practice in DOckerfiles, there may also be arguments for layering the build file in terms associated with which user / role is supposed to be performing what step at each part of the build.