How to Change the Root Password in a Docker Image

Docker

YOUR COSMETIC CARE STARTS HERE

Find the Best Cosmetic Hospitals

Trusted • Curated • Easy

Looking for the right place for a cosmetic procedure? Explore top cosmetic hospitals in one place and choose with confidence.

“Small steps lead to big changes — today is a perfect day to begin.”

Explore Cosmetic Hospitals Compare hospitals, services & options quickly.

✓ Shortlist providers • ✓ Review options • ✓ Take the next step with confidence

If you regularly deploy containers based on official Docker Hub images, you may have noticed that many base images ship without a root password set at all. While containers are generally designed to be ephemeral and access-controlled at the orchestration layer, there are scenarios — particularly in on-premises or development environments — where setting an explicit root password on the base image adds a meaningful layer of defence.

This guide walks you through the process of setting a root password inside a running container and then committing that change to a new image you can reuse. The example uses the official CentOS image from Docker Hub, but the same steps apply to any official Linux distribution image (Ubuntu, Debian, Alpine with a shell, etc.). It assumes Docker is already installed and running on your system.

Why Base Images Often Have No Root Password

Official base images are intentionally minimal. Because containers are typically accessed via docker exec, SSH is rarely installed, and the container runtime itself controls access. As a result, maintainers often leave the root account with no password — or with a locked account — to reduce image size and attack surface. This is fine for many workloads, but if you are building developer tooling, running interactive shells, or enabling SSH inside a container for any reason, a blank root password is a real risk.

Step 1 — Deploy and Inspect the Base Container

Pull and start the official CentOS image in interactive mode:

docker run -it centos

Docker will pull the image if it is not already cached locally, then drop you into a root shell inside the container. Verify the current state of the root account in the shadow password file:

cat /etc/shadow | grep root

In the output you will see the root entry. The second colon-delimited field is the password hash. On a freshly pulled base image this field is typically empty or contains a single !!, confirming that no password is set.

Step 2 — Set a New Root Password

Still inside the container shell, run the standard passwd command:

passwd

You will be prompted to enter and confirm the new password. Use a strong password — at least 12 characters combining letters, numbers, and symbols. Once the command completes successfully, verify the change:

cat /etc/shadow | grep root

The second field should now contain a long hashed string, confirming that the password has been set. Type exit to leave the container and return to your host shell.

Step 3 — Find the Container ID

Before you can commit the change, you need the ID of the container you just exited. List all containers, including stopped ones:

docker ps -a

Identify the container that ran the CentOS image. The full container ID is shown in the first column; you only need the first four or more characters to make it unique.

Step 4 — Commit the Change to a New Image

Use docker commit to save the current container filesystem — including the updated /etc/shadow — as a new image:

docker commit <CONTAINER_ID> <NEW_IMAGE_NAME>Code language: HTML, XML (xml)

Replace <CONTAINER_ID> with the ID from the previous step and <NEW_IMAGE_NAME> with a meaningful name, for example:

docker commit a3f9 centos-secured

Docker will output the SHA256 digest of the new image once the commit succeeds.

Step 5 — Verify the New Image

Spin up a fresh container from the new image and confirm the password is persisted:

docker run -it centos-secured

Inside the new container, check the shadow file again:

cat /etc/shadow | grep root

You should see the hashed password in the second field, confirming the change is baked into the image. Every container you now launch from centos-secured will have the root password set.

Alternative: Use a Dockerfile

The docker commit approach is quick but is not reproducible or auditable. A better practice for production or team environments is to encode the password change in a Dockerfile. The RUN instruction can call passwd non-interactively using chpasswd:

FROM centos
RUN echo 'root:YourStrongPassword' | chpasswdCode language: PHP (php)

Build the image in the usual way:

docker build -t centos-secured .

Be aware that hardcoding a plaintext password in a Dockerfile that is committed to source control is itself a security risk. Prefer injecting secrets at runtime using Docker secrets, environment variables read from a secrets manager, or build arguments that are not baked into the image history.

Important Caveats

  • Not all images support this. Some purpose-built images rely on the root account being locked or set to a specific value. Changing the password in those images may break the application running inside the container.
  • The hashed password lives in the image layer. Anyone with read access to the image can extract /etc/shadow and attempt to crack the hash offline. Use a strong, unique password and restrict who can pull or inspect the image.
  • docker commit is not a substitute for proper secrets management. For production workloads, manage credentials with a dedicated secrets management system rather than baking them into images.
  • Root access inside a container is still constrained by the container runtime. Unless the container is granted additional Linux capabilities or runs in privileged mode, the root user inside a container cannot escalate privileges on the host.

Summary

Setting a root password on a Docker base image is a straightforward two-step process: change the password inside a running container, then commit the container to a new image. For repeatable builds, the Dockerfile + chpasswd approach is preferable. Either way, treat the resulting image with the same care you would apply to any artefact that contains a credential.

Original article sourced from TechRepublic.

0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x