Why is running a container as the root user in Kubernetes considered bad practice?.

Running containers as the root user in Kubernetes poses increased security risks:

• High privilege level: If a container is compromised, the attacker gains root rights inside the container. This can allow privilege escalation on the host system or access to other cluster resources.
• Access to the host's filesystem: Without proper restrictions, the root process inside the container can access the node's filesystem where it runs, increasing the likelihood of unauthorized changes or data leaks.
• Kernel vulnerabilities: The root user in a container can exploit Linux kernel vulnerabilities to escape the container and gain control over the host.
• Audit complexity: Tracking root user actions is more difficult, complicating the detection and investigation of security incidents.
• Privilege inheritance: If other processes are started by the root user, they will also have high privileges.

It is recommended to follow the principle of least privilege by running containers as a non-privileged user. This can be configured in the pod manifest using securityContext:

securityContext:
  runAsUser: 1000  # Use a non-privileged user with ID 1000
  runAsGroup: 3000 # Belong to a group with ID 3000 (optional)
  allowPrivilegeEscalation: false # Disallow privilege escalation
readOnlyRootFilesystem: true # Make the root filesystem of the container read-only

Additionally, you can use:

• Pod Security Policies / Pod Security Admission: To enforce security policies at the pod level.
• AppArmor / SELinux: For additional container isolation.
• Using container images with explicitly specified non-privileged users: In the Dockerfile using the USER instruction.

# Example Dockerfile specifying a user
FROM ubuntu:latest
# Create a non-privileged user
RUN useradd -ms /bin/bash myuser
# Switch to the created user
USER myuser
CMD ["/bin/bash"]