Docker for data science
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.


  More details:
  
  Part1_ From application point of view


Containers are very important when does come to data science world from following points:


Minimizing conflicting library versions for different development projects(each project has own container/pod to run).
Consistency across environments and developers against specific design criteria.
Rapid Prototyping with Edge Node On Demand.
Avoiding a need to reinstall everything on new hardware after a refresh or failure.
Portability of your compute environment, develop in your machine and if you need more resources like CPU, RAM or GPU you can port your environment to cloud, powerful clusters, powerful machine, group of containers that can be orchestrated with Kubernetes or Dockerized cluster called Swarm.
Maximize collaboration clarity across groups. Consistent libraries, result sets, etc.
Extending on-premises autonomy/agility to cloud scale and reach.
Project workspaces powered by Docker containers for control over environment configuration. You can install new packages or run command-line scripts directly from the built-in terminal.
Resources used by containers are very few comparing with VM or Bare metal ... you can have multiple containers running in VM or Bare metal so this will greatly reduce license cost for OS and projects/apps will scale based on resources needed and not full resources of the host( here to note: you will run multiple apps/models in a machine when using containers comparing without containers you’ll use full machine resources for 1 single app/model and this is waste of resources. In a cluster environments you can spin up multiple pods/containers(apps/models across the cluster and with zero cost of the pod comparing with VMs you pay for OS of each host and you run all resources to that task). 
easy to have new image with new packages installed and share with everyone instead to deal with virtual environments into VMs and have conflict of packages and many more(would like to see virtual environments to be moved from traditional approach to containers, that will be a good improvement and will help a lot for Data scientists to bypass the configuration of each project individually with all conflicts and activate/deactivate then search for requirements when putting in production when with containers all you need is a config file, this is my point of view from what I see daily in Data Science world).
Infrastructure independent platform allows data scientists to run the the analytics applications on the infrastructure best optimized for the applications
Empower data scientists to build models with the tools and packages best suited for the research without worry of application and environment conflicts.
Most important Research Reproducibility: The SCALE provided by containers, you scale easily with containers and will be identical across all environments and you don’t care about the host OS, ensuring repeatability of analysis and research with immutable containers and eliminating issues with different environments
Secure Collaboration: Integrated security in the platform and lifecycle allows for collaboration without risk of tampering and data integrity(more details in Part2&amp;3.


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 &amp; 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 auditd or 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 "attack surface".
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)
https://devblogs.nvidia.com/making-data-science-teams-productive-kubernetes-rapids/
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.