Let me paint a very simple example. You have a wordpress containerized app (or any app that uses a database). Typically, you will need a volume mount (a container volume mapped to the underlying host). This container volume has full rwx (read write execute) access to the underlying filesystem.
If you can introduce malware onto the wordpress drive (this can be through regular Layer 7 OWASP techniques), you introduce it to the underlying host. Remember, the container responds to all http requests (if it is hosting a webserver) – and anything you can introduce into a normal website via http, you can introduce into the containerized website.
As simple as that.
Now, if you want to be extra cautious:
- a) Do not use volume mounts (or use a secure version – that takes some setting up)
- b) Run your container in a special ‘memory isolated’ mode.
In addition,
•To make your container platform resilient, use network namespaces to sequester applications and environments
•Attach storage via secure mounts.
•Use gMSA to accomplish integrated windows authentication. This will prevent unauthorized access from any computer that does not have the gMSA credentials.
Summary
It is entirely possible to break out of a container boundary and introduce harmful software on the underlying host filesystem. However, simple precautions can mitigate this risk.