Best Practices for Switching to Non-root Users in Docker Images

Problem Background Analysis

In Docker container environments, user privilege management is crucial for secure deployment. Many developers encounter issues when using the su command to switch users, where the operation appears ineffective even though the target user exists in the /etc/passwd file. The whoami command continues to return root, which stems from insufficient understanding of Docker's build mechanisms.

Isolation Characteristics of Docker Build Process

Each RUN instruction in a Dockerfile executes in a new container layer. Consider the following example code:

RUN whoami
RUN su tomcat7
RUN whoami

Both whoami commands in this code will output root. This occurs because each RUN instruction runs in an isolated container environment, and the user switch state from previous instructions does not persist to subsequent ones.

Proper Usage of USER Instruction

Docker provides the dedicated USER instruction to set the runtime user identity. This instruction affects the execution identity of all subsequent RUN, CMD, and ENTRYPOINT instructions.

The following example demonstrates correct usage:

FROM debian:wheezy

# Install necessary software
RUN apt-get update && apt-get install -y openjdk-7-jdk tomcat7

# Create and configure tomcat7 user directory
RUN mkdir -p /usr/share/tomcat7/.hudson
RUN chown -R tomcat7:tomcat7 /usr/share/tomcat7/

# Switch to tomcat7 user
USER tomcat7

# Subsequent instructions execute as tomcat7
RUN whoami
# Output: tomcat7

Through the USER tomcat7 instruction, all subsequent operations execute under tomcat7 user privileges, resolving SSH certificate permission issues.

Complete Best Practice Example

Improved version based on the original Dockerfile:

FROM debian:wheezy

# Base software installation
RUN apt-get update && apt-get install -y \
    openjdk-7-jdk \
    tomcat7 \
    maven \
    git \
    subversion

# Clean webapps directory
RUN rm -rf /var/lib/tomcat7/webapps/*

# Add application files
ADD ./ROOT.tar.gz /var/lib/tomcat7/webapps/

# Configure Hudson directory
RUN mkdir -p /usr/share/tomcat7/.hudson
ADD ./dothudson.tar.gz /usr/share/tomcat7/
RUN chown -R tomcat7:tomcat7 /usr/share/tomcat7/

# Set up SSH certificates (for tomcat7 user)
USER tomcat7
RUN mkdir -p /usr/share/tomcat7/.ssh
ADD ssh.tar.gz /usr/share/tomcat7/.ssh/

# Port exposure and startup script
EXPOSE 8080
ADD run.sh /home/tomcat7/run.sh
RUN chmod +x /home/tomcat7/run.sh

CMD ["/home/tomcat7/run.sh"]

This improved version ensures SSH certificates are correctly placed in the tomcat7 user's home directory, resolving permission verification issues during Git operations.

Alternative Approach Comparison

Besides using the USER instruction in Dockerfile, the --user parameter of docker exec can be used during container runtime:

docker exec -it --user tomcat7 container_name bash

This method is suitable for temporary debugging or specific command execution but is not appropriate as a build-time solution.

Security Considerations

Running container applications with non-root users is a key component of Docker security best practices. This can:

• Reduce potential security risks
• Adhere to the principle of least privilege
• Prevent container escape attacks
• Comply with production environment security standards

Conclusion

Correctly understanding Docker's build mechanisms and user management is essential for resolving permission issues. The USER instruction provides an officially supported solution, while runtime parameters offer flexible alternatives. Developers should choose appropriate methods based on specific requirements to ensure the security and stability of containerized applications.