A container may include many different components and images. And the more components there are, the more possible...
vulnerabilities that an attacker may find to exploit. Take these steps to keep your container vulnerabilities to a minimum.
Reduce attack surfaces in container images
Consider removing local debugging tools from container images. These tools are typically highly privileged, and attackers often seek to exploit the weak security and other container vulnerabilities that may persist in such tools.
It's also a good practice to include vulnerability scanning as a regular part of the container creation and staging processes in the container registry. Container registry platforms often include a vulnerability scanning capability that can identify potential vulnerabilities in the container image when it is uploaded to the container registry. It even rescans the image once the vulnerability database is updated.
Avoid using public container images
It's not unordinary to use a public image, such as a Debian, Alpine, CentOS or other Linux OS, as a base image and then create the added software that builds the final container image. However, there are some potential problems with publicly shared container images.
For example, organizations have no control over the content or vulnerabilities of an image obtained from a public source. Also, publicly shared images may use different base OSes that can cause kernel compatibility issues. There's also no control over the updating or availability of the shared images as users must depend on the provider of the shared image to do so. As such, it's safer to just avoid public images.
Limit container privileges
Containers share the common OS. This distinct difference brings forth the possibility that an attacker could discover container vulnerabilities and access the host machine. For example, this can prevent an attacker from modifying root files in a package manager, like apk, within the image.
One way to improve the security posture of a container environment is to prevent running processes inside containers as root. In a platform such as Kubernetes, for example, it is possible to specify the Linux user responsible for the container process. Alternately, it's possible to construct the container so that it runs as an unknown, nonprivileged user. Another tactic that can improve container security is to launch containers in read-only mode so that no user can overwrite the container's contents.