Instead of focusing on the technology term, will provide generalized answer and use the term “containers”.
Containers run only what it supposed to run, assuming anything unknown is untrusted so what only reside in container only for the life of container, so modification of a code in database to test will be same approach in VMs(sandboxing) or containers(docker) and biggest difference is kn resource consumption and time for provisioning VMs vs spinning up containers/pods in couple seconds for application.
Part1_ From application point of view
Containers are very important when does come to data science world from following points:
Here comes in play Cloudera with Cloudera Data Science Workbench and Anaconda with Anaconda Enterprise both does use containers so can bring quick results for the business and deploy easy the models from dev to QA and ultimately to production.
Why is important last statement? is to have portability from dev to prod without any changes to environments and without cost DevOps part to operationalize.
Part2_ From security point of view
One notorious security advantage is that the host OS security is separate from the container, meaning that is patched separated, patching host OS wouldn’t impact your containerized application(how many times we have the issue when we do patch the OS and does affect the app and service in that OS(paths, ports, services etc)?
- For example: if you have a malicious
library on your app/code than that malware will reside only on that container for the time of container being live, containers does run as endpoint all the time and didn’t saw a case that will spread the malware into network.
- monitoring a container node is robust and you can put add-on or service to monitor behaviors of application or node, and will only replicate new node/container only and only based on config file.
Comparing VMs vs containers: With containers is a different story, you take care of OS separate from containers(containers is separate task when security is in place).
Docker security does provide detailed information of major security points.
Docker standards and compliances provides a full list of security compliances and standards available for containers.
"Docker container with a well crafted seccomp profile (which blocks unexpected system calls) provides roughly equivalent security to a hypervisor."
Folder sharing. With containers, you can share a folder by setting up a shared mount, and since the Docker/kernel enforces file permissions that is used by containers, the guest system can't bypass that restrictions. This is very important for Data Science applications and users because in corporate is used most of the time sensitive/restricted data and multiple layers of security or restrictions are in place, one approach to solve this security problem is using VDI or VMs that with AD group in place to restrict/share data access and does become problematic and costly to maintain and allocate resources.
When does come to debugging applications or OS with all services and logs generated I think containers are winning and evolving now to NLP approach: An experimental natural language processing (NLP) utility is also included, for proofreading security narratives.
Here I will quote Jianing Guo from Google: A properly secured and
updated VM provides process level isolation that applies to both
regular applications as well as container workloads, and customers can
use Linux security modules to further restrict a container’s attack
surface. For example, Kubernetes, an open source production-grade
container orchestration system, supports native integration with
AppArmor, Seccomp and SELinux to impose restrictions on syscalls that
are exposed to containers. Kubernetes also provides additional tooling
to further support container isolation. PodSecurityPolicy allows
customers to impose restriction on what a workload can do or access at
the Node level. For particularly sensitive workloads that require VM
level isolation, customers can use taint and toleration to help ensure
only workloads that trust each other are scheduled on the same VM.
On top of all, kubernetes cluster has following additional security features:
- Use Transport Layer Security (TLS) for all API traffic
- API Authentication
- API Authorization
- Easy remediation of security flaws and minim impact on application/environment compared with VMs or dedicated Bare metal.
Part3_CIS benchmarks for hardening containers:
Docker & Kubernetes.
First step making containers more secure is to prepare the host machine that is planed to use for executing containweized workloads. By securing containers host and following infrastructure security best practices would build a solid and secure foundation for executing containerized workloads.
Stay up to date on Docker updates, vulnerabilities in the software.
Have a specific dedicated directory for Docker related files and allocate just enough space to see for containers to run(default path is
/var/lib/docker but change to other mounting point and monitor at OS level using
aide services for any changes or size/unwanted workload run, keep the logs and configure according to the needs.
Note: The best part about
step 2 is that with VMs you need to monitor way more locations for your data science project(libraries in different location, multiple versions of packages, locations/path for even python, run
cron jobs or systemd to ensure some process does run, log all logs etc but with containers is single point for all this jobs to run and monitor only a path instead of multiple ones).
Verify all the time the users into
docker group so you prevent
unauthorized elevated access into the system(Docker allows the share of directory between the Docker host and a guest container without limiting the access rights of the container) so remove any untrusted users from the
docker group and do not creat a mapping of sensitive directories frim the host to container volumes. Here I would say to use a separate user for the installation and specific container tasks "NEVER use
root for containers run dedicate a
PID only for this task(will have elevated access but will be task based, I use gravitational for the cluster and when installing I NEVER use root).
Audit all Docker daemon activities(be aware that does take space the logs in containerized "world" so prepare separate partition with decent space to hold the logs and required configuration(rotation and period to store the logs).
Audit all Docker files and docker.service , in etc, var and what else is aplicable.
Restrict all inter-container communication, Link specific containers together that are require communication(best will be to create a custom network and only join containers that need to communicate to that custom network). This hardening approach will prevent unintended and unwanted disclosure of information to other containers.
All applications in containerized infrastructure should be configured or at least to have th eoption to
Encryp All Sensitive Information(this is very importan for Data Scientist because most of the time we do login to platforms to get data, including
sensitive data for the company.
Have option to have Encrypted All Sensitive Infomration in Transit.
Uses only specific approved
Ports, Protocols and Services, VMs has more open surface when does come to run an app/project, with containers you specify only what will be used and not wondering for all other ports listening, protocls and services that does run at OS level to protect or monitor, this does minimize the
Sensitive information stored on systems is encrypted at rest and does require secondary authentification mechaninsm , not integrated into operating system, in order to access the information.
Does allow to be enabled
Operating System Anti-Exploitation Features/Deploy Anti-Exploit Technologies: such as
Data Execution Prevention(DEP) or
Address Space Layout Randomization (ASLR).
The best simple security difference between VMs and Containers is: when updating or running a project you don't need elevated access to do it over entire VM or network, you just run as a defined user and if is elevated access then does exist only for the time of the container and not shared across of the host(here does come Data Science libraries install, update, executing projects code etc).
Part4_ More resources(on top of links incorporated in Part1-3) related to containers for Data Science:
- Data Science on docker
- Conda, Docker, and Kubernetes: The cloud-native future of data science (sponsored by Anaconda)
- Why Data Scientists Love Kubernetes
- A very good book to understand docker usage for Data Science: Docker for Data Science: Building Scalable and Extensible Data Infrastructure Around the Jupyter Notebook Server.