Running Containers as a Non-Root User

1. The Risk of Running as Root

Before we fix the problem, let's see it in action. A container running as root can do anything inside its namespace—install packages, modify files, and more. This gives an attacker who finds a vulnerability in your application a powerful foothold.

This ability to modify the container environment at runtime is precisely what we want to prevent.

2. The Solution: Create and Use a Non-Root User

The solution involves two main steps within your Dockerfile:

1. Create a user and group: Use a RUN instruction with standard Linux commands like useradd or adduser.
2. Switch to the new user: Use the USER instruction to specify that all subsequent instructions (and the final running container) should execute as this new user.

To get a comprehensive overview of the best practices for this, we'll turn to the official Docker blog.

Now, let's see a practical demonstration of this fix and its effect.

This before-and-after clearly illustrates the security benefit. Here is a simple visual summary of what this looks like in a Dockerfile.

3. Best Practices for User Management

As highlighted in the Docker blog post, simply adding a user is just the start. For production-grade files, consider these practices:

• Specify User by UID/GID: Instead of USER myuser, prefer using the numeric ID, like USER 1001:1001. Usernames can sometimes conflict or be inconsistent across different base images, but UIDs and GIDs are more reliable.
• Manage File Permissions: When you switch to a new user, that user must have permission to read/write to the necessary directories (like your application's working directory). You often need to pair user creation with chown. For example:

  # Create app directory
  RUN mkdir /app
  
  # Create a non-root user and group
  RUN addgroup -S appgroup && adduser -S appuser -G appgroup
  
  # Give the new user ownership of the app directory
  RUN chown -R appuser:appgroup /app
  
  # Switch to the new user
  USER appuser
  
  # Set working directory
  WORKDIR /app
  
  COPY . .
  
  CMD [ "node", "server.js" ]
  

• Temporary Root for Privileged Operations: It's a common and valid pattern to perform administrative tasks as root before switching to your application user.

  # Start as root
  FROM ubuntu:22.04
  
  # Perform privileged operations
  RUN apt-get update && apt-get install -y curl
  
  # Now, create and switch to the non-root user
  RUN useradd -m myapp
  USER myapp
  
  # Subsequent instructions run as myapp
  CMD ["/bin/bash"]
  

4. An Advanced Pattern: Handling File Permissions in Development

Here's a scenario every DevOps engineer encounters: a developer is using a bind mount to sync code from their host machine into a running container. If the container process (running as UID 1001) creates a file in that volume, the file on the host machine is now owned by user 1001. If the developer's host user is UID 1000, they'll get permission errors trying to edit that file.

We can solve this elegantly by combining the USER instruction with the ARG instruction you learned about in a previous lesson.

This pattern makes your Docker setup much more portable and developer-friendly by allowing each user to build the image with their own UID/GID, ensuring seamless file ownership across the container-host boundary.

# Define build arguments with defaults
ARG APP_UID=1001
ARG APP_GID=1001

# Create a group and user with the specified IDs. 
# The -D flag means 'don't assign a password'.
# The -S flag means 'create a system user'.
RUN addgroup -S -g ${APP_GID} appgroup && \
    adduser -S -u ${APP_UID} -G appgroup appuser

# Switch to the created user
USER appuser

Conclusion

You've now mastered a critical security practice for containerization. By moving away from the default root user, you apply the principle of least privilege to significantly harden your Docker images against potential exploits.

Key Takeaways:

• Running containers as root is a major security risk. Always create and use a dedicated non-root user.
• The process is a two-step: RUN useradd/adduser to create the user, then USER to switch to it.
• Remember to manage file permissions with chown so your application user can access its files and directories.
• For advanced use cases, especially in development, parameterize the UID and GID using ARG to solve file ownership issues with volumes.

In our next lesson, we will address another subtle but important aspect of production containers: signal handling and the role of an init system. Now that we have a secure process running as the right user, we need to ensure it can start and, more importantly, stop gracefully.