Docker Hub is a cloud-based repository that allows Docker users and partners to create, test, store, and distribute container images. Docker Hub allows users to access public, open-source image repositories as well as create their own private repositories, automated build routines, webhooks, and work groups.
For example, a DevOps expert can utilise Docker Hub to get the official PostgreSQL object-relational database management system container image for usage in a containerized application. Alternatively, they may select a customised RDBMS from their organization’s private repository.
Docker Hub is a cloud-hosted alternative to the Docker Registry. If a Docker user prefers to handle the storage and distribution of Docker images rather than depending on Docker’s service, they can utiliseDocker Registry, which is a stateless, open-source, and scalable server-side application.
While Docker has become associated with containers, a slew of container tools and platforms have arisen to streamline the process of designing and operating containers. Nonetheless, many of the same Docker security considerations apply to safeguarding container-based systems created using other technologies. We combined the main Docker security best practises listed below into the most complete hands-on guide to help you construct more secure containers.
Maintain Host and Docker Updates
Patching the Docker Engine and the underlying host operating system running Docker is critical to preventing a variety of known vulnerabilities, many of which can result in container espaces.
Because the kernel is shared by the container and the host, any kernel vulnerabilities that an attacker successfully runs on a container can have a direct impact on the host. A successful kernel vulnerability, for example, can allow attackers to break out of a non-privileged container and get root access to the host.
Do Not Expose the Docker Daemon Socket
The Docker daemon socket is indeed a Unix network socket utilized to access the Docker API, which is controlled by the root user automatically. Thus, every account gaining access to the socket has the same credentials as the host’s root administrator.
Run Docker in Rootless Mode
Docker has a feature called “rootless mode,” which allows you to operate Docker daemons and containers as non-root users. This is critical for mitigating vulnerabilities in daemons and container runtimes, which can provide an attacker root access to whole nodes and clusters.
Avoid Using Privileged Containers
Docker has a privileged mode that allows containers to run as root on the local computer.
Because they allow attackers to swiftly escalate privileges if the container is hacked, privileged containers pose a substantial security risk. As a result, employing privileged containers in a production environment is not recommended. Most importantly, never, ever use them in any scenario.
Limit Container Resources
When a container is exploited, attackers may attempt to carry out malicious behaviour using the underlying host resources. Set Docker memory and CPU consumption restrictions to reduce the effect of resource-intensive container breaches.
By default, the container has access to all RAM and CPU resources on the host in Docker. Set resource quotas to limit the resources your container may use—for security reasons and to guarantee each container has enough resources and does not interfere with other services running on the host.
Segregate Container Networks
Docker containers require a network layer in order to connect with the outside world via the host’s network interfaces. The default bridge network is present on all Docker hosts; if you do not specify a different network, new containers will connect to it automatically.
Containers should only connect to each other if absolutely essential, and sensitive containers should not be connected to public-facing networks.
Improve Container Isolation
Teams in charge of operations should create a container-optimized environment. Ideally, the operating system on a container host should protect the host kernel against container escapes and avoid container mutual impact.
Containers are Linux processes that operate with isolation and resource limits on a shared operating system kernel. It is the same as safeguarding any other Linux process to protect a container.
Set Filesystem and Volumes to Read-only
Running containers with a read-only filesystem is a simple and effective security approach. This can prevent harmful behaviour such as virus deployment or configuration changes on the container.
Restrict System Calls from within Containers
You can select whether to allow or reject system calls in a container. A container does not require all system calls to function.
Keeping this in mind, you can monitor the container, acquire a list of all system calls performed, and expressly allow just those calls. Because you cannot be aware of the particular system calls utilised by your container’s components or how those calls are labelled in the underlying operating system, it is critical that you base your configuration on runtime observation of the container.
