Streamlining Docker Access for ec2-user on AWS EC2

Repeatedly invoking sudo for Docker commands on EC2 wastes time and increases risk—mistyped escalations, broken scripts, and avoidable friction in automation. The safer approach: assign your login user (commonly ec2-user on Amazon Linux) to the docker group. This grants permission to interact with the Docker daemon directly, minimizing the attack surface of root usage and aligning with security best practices.

Typical Scenario

You’ve just provisioned a fresh EC2 instance (Amazon Linux 2, kernel 4.14+). Docker is installed, but attempts to run:

docker ps

yield:

Got permission denied while trying to connect to the Docker daemon socket...

This error originates from Docker’s reliance on /var/run/docker.sock—owned by root:docker and typically mode 0660. Only members of the docker group can access the daemon socket.

Minimal Steps

1. SSH into your instance.

ssh -i /path/to/key.pem ec2-user@10.10.10.10

2. Confirm Docker runtime and group.

docker --version            # Should output Docker version 20.10.x or newer
getent group docker         # Confirms 'docker' group exists

If absent, re-install Docker:

sudo yum update -y
sudo amazon-linux-extras install docker -y
sudo systemctl enable --now docker

3. Add ec2-user to Docker group.

sudo usermod -aG docker ec2-user

• The -aG flag appends the group, retaining existing memberships.
• No need to stop the Docker daemon.

4. Refresh group membership.

• Log out of the shell (exit).
• SSH back in. Alternatively, use newgrp docker, though full logout is preferred to ensure all shells refresh memberships.

5. Validate access.

docker run --rm hello-world

• On success, the image executes and prints a confirmation message.
• If you see another permissions error, verify with groups:

  groups
  

  Output must include docker.

Non-Obvious Pitfall

Adding a user to the group does not affect already-open SSH sessions due to the way group memberships are cached at login. If your CI/CD job still fails after usermod, double-check the shell context.

Security Footnote

Membership in the docker group is effectively root access (anyone who can control the socket can mount host filesystems, etc). Audit user group assignments regularly. For production workloads, consider tighter RBAC around Docker socket or adopt rootless Docker (see Docker documentation).

Known Issue: Restarting Docker on Busy EC2

If you restart the Docker daemon via sudo systemctl restart docker under significant container load, active non-root containers may be interrupted. Plan restarts for maintenance windows.

Summary Table

Diagram: Docker Group Access

             +----------------------+
SSH/Login -> |    ec2-user shell    |
             +----------------------+
                      |
              part of 'docker' group
                      |
             +----------------------+
             | Docker daemon socket |
             | /var/run/docker.sock |
             +----------------------+

Not perfect—membership in the docker group exposes broad privileges. For tighter security, review who has this access. For developer velocity on ephemeral EC2, however, it’s practical.

Side Note: Some distributions (e.g., Ubuntu 22.04) use different default usernames (often ubuntu). Adjust the commands accordingly.

Practical example:

Automating this in your bootstrap script:

# In cloud-init or user-data
yum install -y docker
usermod -aG docker ec2-user
systemctl enable --now docker

This ensures any EC2 instance provisioned from your custom AMI is ready for user-level Docker commands without further manual intervention.

Questions on operational boundaries or group permissions? Refer to Docker’s official security documentation.

End of guide.