Tools for testing container vulnerability
Inspector
No matter whose portfolio, solutions are lining up everywhere to bundle software on customers' systems in Docker or other containers. Where applications installed directly on the system are still typical today, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), and the like will soon be no more than playback tools and comprise only a minimal system kernel and a runtime environment for containers.
One reason these enterprises frequently cite for relying on containers relates to the security benefits the containers claim to offer. At first glance, this assertion cannot be completely dismissed. An attack on an application running in a container causes fewer problems from the administrator's point of view, but planners and administrators would do well not to check the container security box too quickly. Even in this environment, security vulnerabilities remain an issue, especially considering the changes in the typical attack scenario in recent years.
In the past, the goal of an attacker was to gain control over an entire system to exploit it for their own purposes, but today data theft plays a far greater role. Whether a MySQL instance is running in a container or not, if an external attack succeeds, the data is gone. (See the "Container Complaints" box.)
Container Complaints
Administrators regularly complain about containers because they considerably increase the administrative overhead. A small experiment demonstrates this: If you want to run MySQL in a container, you first need to package it in a container, which immediately changes the rules of the admin game. With a database running directly on the server, you can typically access an SQL shell by typing mysql -u root
. In a container, this simple approach typically no longer works, or at least not out of the box. Instead, you need port forwarding and a
Buy this article as PDF
(incl. VAT)