Running containers as non-root in Docker - Step-by-Step Execution

Process Flow - Running containers as non-root

Start Dockerfile

↓

Set USER to non-root

↓

Build Image

↓

Run Container

↓

Container runs as non-root

↓

Verify user inside container

↓

Exit

This flow shows how to set a non-root user in a Dockerfile, build the image, run the container, and verify the user inside.

Execution Sample

Docker

FROM ubuntu:latest
RUN useradd -m appuser
USER appuser
CMD ["whoami"]

This Dockerfile creates a user 'appuser', switches to it, and runs 'whoami' to show the current user.

Process Table

Step	Action	Command/Instruction	Result/Output
1	Start from base image	FROM ubuntu:latest	Base image ubuntu:latest pulled
2	Create new user	RUN useradd -m appuser	User 'appuser' created
3	Set user for container	USER appuser	Default user set to 'appuser'
4	Set default command	CMD ["whoami"]	Command to run 'whoami' set
5	Build image	docker build -t test-nonroot .	Image 'test-nonroot' built successfully
6	Run container	docker run --rm test-nonroot	Output: appuser
7	Verify user	Output of 'whoami'	appuser
8	Exit	Container stops after command	Container exited
9	End	No more steps	Execution complete

💡 Container runs command as 'appuser' and exits, confirming non-root execution

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	Final
USER	root	root	appuser	appuser	appuser
Container State	Not built	Image built	Image built	Running as appuser	Exited

Key Moments - 3 Insights

Why do we need to add a new user instead of just switching USER to a non-root name?

Because the user must exist inside the container. Step 2 creates 'appuser', so step 3 can switch to it. Without creation, USER would fail.

What happens if we don't set USER in the Dockerfile?

The container runs as root by default (see Step 1 and Step 6). Setting USER changes the default user for running commands.

Why does the container exit after running 'whoami'?

Because CMD runs a single command and then stops. The container lifecycle ends after the command completes (Step 8).

Visual Quiz - 3 Questions

Look at the execution table, what user is the container running as at Step 6?

A appuser

B nobody

C root

D docker

💡 Hint

Check the 'Result/Output' column at Step 6 showing 'Output: appuser'

At which step is the new user 'appuser' created inside the image?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Action' and 'Command/Instruction' columns; useradd runs at Step 2

If we remove the USER instruction, what will be the output at Step 6?

A appuser

B root

C nobody

D Error

💡 Hint

Without USER set, container runs as root by default (see Step 1 and Step 6)

Concept Snapshot

Docker containers run as root by default.
To run as non-root, create a user inside the image with 'useradd'.
Use 'USER username' in Dockerfile to switch user.
Run container; commands execute as that user.
Verify with 'whoami' inside container.
This improves security by limiting privileges.

Full Transcript

This visual execution shows how to run Docker containers as non-root users. First, the Dockerfile starts from a base image. Then it creates a new user named 'appuser' using 'useradd'. Next, it sets the default user to 'appuser' with the USER instruction. The CMD runs 'whoami' to print the current user. When building and running the container, the output confirms the container runs as 'appuser' instead of root. The container exits after running the command. Key points include the need to create the user before switching, the default root user if USER is not set, and that containers stop after the CMD finishes. This method improves container security by avoiding running as root.

Practice

1. Why is it recommended to run Docker containers as a non-root user?

easy

A. To enable root access inside the container

B. To make containers run faster

C. To improve security by limiting container permissions

D. To allow containers to access all host files

Solution

1. Step 1: Understand container user privileges

   Running containers as root gives full permissions inside the container, which can be risky if the container is compromised.

2. Step 2: Recognize security benefits of non-root users

   Using a non-root user limits what the container can do, reducing potential damage from attacks.

3. Final Answer:

   To improve security by limiting container permissions -> Option C

4. Quick Check:

   Security = D [OK]

Hint: Non-root users limit permissions, improving security [OK]

Common Mistakes:

• Thinking non-root users make containers faster
• Believing root is needed for all container tasks
• Confusing root access with better security

2. Which Dockerfile instruction sets the user to run the container as non-root?

easy

A. RUN

B. CMD

C. ENTRYPOINT

D. USER

Solution

1. Step 1: Identify Dockerfile instructions for user control

   The USER instruction sets the user and group for running commands inside the container.

2. Step 2: Differentiate from other instructions

   RUN executes commands during build, CMD and ENTRYPOINT define container start commands but do not set user.

3. Final Answer:

   USER -> Option D

4. Quick Check:

   Set user = USER [OK]

Hint: USER sets container run user in Dockerfile [OK]

Common Mistakes:

• Using RUN to set user (it runs commands)
• Confusing CMD or ENTRYPOINT with user setting
• Omitting USER instruction for non-root

3. What is the effect of running this command?

docker run --user 1001 alpine id

medium

A. Shows the user ID 1001 inside the container

B. Runs the container as root user

C. Fails because user 1001 does not exist

D. Shows the container's hostname

Solution

1. Step 1: Understand the --user flag

   The --user 1001 option runs the container process as user ID 1001 instead of root.

2. Step 2: Analyze the command output

   The id command inside the container prints the current user info, so it will show UID=1001.

3. Final Answer:

   Shows the user ID 1001 inside the container -> Option A

4. Quick Check:

   --user 1001 + id = UID 1001 [OK]

Hint: --user sets UID; id shows current user info [OK]

Common Mistakes:

• Assuming container runs as root despite --user
• Thinking id shows hostname
• Believing command fails if user not in /etc/passwd

4. You wrote this Dockerfile snippet:

FROM alpine
USER appuser
CMD ["sh"]

But when running the container, you get a permission denied error. What is the likely cause?

medium

A. The CMD syntax is incorrect

B. The user 'appuser' does not exist in the image

C. The base image alpine does not support USER

D. The container needs root to run sh

Solution

1. Step 1: Check if user exists in image

   The USER appuser requires that 'appuser' is created in the image, otherwise permission errors occur.

2. Step 2: Verify other options

   CMD syntax is correct, alpine supports USER, and sh can run as non-root if permissions allow.

3. Final Answer:

   The user 'appuser' does not exist in the image -> Option B

4. Quick Check:

   User must exist = B [OK]

Hint: Create user before USER instruction to avoid permission errors [OK]

Common Mistakes:

• Assuming USER works without creating user
• Blaming CMD syntax for permission issues
• Thinking alpine disallows USER instruction

5. You want to run a container as a non-root user with UID 2000 and GID 3000, but the image has no such user. Which is the best way to do this securely?

hard

A. Add a user with UID 2000 and GID 3000 in the Dockerfile, then use USER

B. Run the container as root and change permissions inside

C. Use --user 2000:3000 without creating the user in the image

D. Modify the host system to add user 2000

Solution

1. Step 1: Understand user creation in Dockerfile

   To run as a specific non-root user, create that user and group inside the image with matching UID and GID.

2. Step 2: Use USER instruction to switch user

   After creating the user, use the USER instruction to run container processes as that user securely.

3. Step 3: Evaluate other options

   Running as root is insecure, using --user without user in image may cause permission issues, and modifying host users is unrelated.

4. Final Answer:

   Add a user with UID 2000 and GID 3000 in the Dockerfile, then use USER -> Option A

5. Quick Check:

   Create user + USER = secure non-root run [OK]

Hint: Create user in Dockerfile before USER for secure non-root run [OK]

Common Mistakes:

• Running as root to avoid user setup
• Using --user without user in image causing errors
• Changing host users instead of container users