Securing your Containerised Models and Workloads

Containerisation is now the de facto means of deploying many applications, with Docker being the forefront software driving its adoption. With its popularity also comes the increased risk of attacks [1]. Hence it will serve us well to secure our docker applications. The most fundamental means of doing this is to ensure that we set the user within our containers as a non-root user. <pre> CONTENTS ======== Why use non-root? What you can & cannot do as a default non-root user The Four Scenarios 1) Serve a model from host (Read Only) 2) Run data processing pipelines (Write within Container) 3) Libraries automatically writing files (Write within Container) 4) Save trained models (Write to Host) Summary</pre> <h1>Why use Non-Root?</h1> Or rather, why not use the root user? Let’s take an example of a dummy architecture like the one below. <img alt="" src="https://miro.medium.com/v2/resize:fit:700/1*-_NtF1E-xDmO50Owj-cUkQ.png" style="height:425px; width:700px" /> A hacker entering a container with root access. Image by author Security is often viewed in a multi-layered approach. If an attacker manages to enter a container, the permissions it has as a user will be the first layer of defence. If the container user is assigned to have root access, the attacker can have free control of everything within the container. With such broad access, it can also exploit any potential vulnerabilities present and using that, potentially escape out to the host, and gain full access access to all connecting systems. The consequences are severe, including the following: <a href="https://towardsdatascience.com/securing-your-containerised-models-and-workloads-3bff4d90a07b">Read More</a>