# Docker Security #docker ## Main Components - Docker host - Docker daemon - Docker image - Runtime ### Docker Host - Avoid mixing containerized applications with host-based applications. - Fewer components reduce vulnerabilities. - Keep the OS up to date. - Use unified configuration and deployment automation. - Limit the number of accounts. - Log system access attempts at the host level. ## Secure Docker Daemon Configuration - Do not expose Docker daemon socket. Docker client, including Docker CLI, communicates with the Docker Daemon via the socket `var/run/docker.sock`. **Key Point**: Anyone with access to the socket can send commands to Docker Daemon, gaining full control over it, containers, and related resources. Since the daemon runs as root, it can execute any program or create containers easily. Access to the Docker socket is equivalent to having root-level access to the host. To list all containers directly via the socket: ```bash curl -s --unix-socket /var/run/docker.sock http://localhost/containers/json | jq . ``` ## CI/CD Risks and Docker Daemon A good CI/CD practice, especially in enterprise environments, is to avoid using Docker. One of Docker’s critical security issues is that it combines two distinct functions: image building and container runtime management. This setup allows broad access to both build and runtime capabilities, making CI/CD runners vulnerable. An attacker could build, run, and perform other actions if they gain access to these runners. To mitigate risks, use alternative tools for building container images without Docker Daemon, such as BuildKit, Kaniko, and Buildah, which don't rely on root privileges. This approach is preferred over Docker in CI/CD pipelines. As of Docker version 23.0, BuildKit is integrated as the default builder. BuildKit uses a low-level build definition format (LLB), an intermediate binary format that allows developers to extend BuildKit's functionality. ## Limit Privilege Escalation Risks Docker Daemon runs containers as root by default because it needs sufficient privileges to create namespaces. However, users in the `docker` group can also start containers, giving them access to control Docker via the daemon socket. Any member of this group can launch containers, and by running: ```bash docker run -v /:/host <image> ``` they could mount the root directory of the host and gain complete access to the host's file system. Docker runs containers as root by default unless specified otherwise. This combination gives nearly unrestricted access to the host. The best way to prevent privilege escalation attacks from containers is to run containers as unprivileged users. Remember, containerization is based on Linux namespaces, which isolate and partition system resources for processes. Each namespace acts as an independent layer, limiting the visibility and access to system resources for the processes within it, effectively protecting the host from potentially harmful applications running inside containers.