Securing Containers in the Real World... request inputs in this discussion.
I'm at the Red Hat Summit, and one of the sessions I attended had to do with securing
=======================================================
============ Description from the Summit Description of this event below...
Secure your enterprise software supply chain with containers
Curtis Yanko - Sr Principal Architect, Sonatype
Randy Kilmon - VP of Engineering, Black Duck Software
Zohaib Khan - Practice Lead, Manager PaaS Comunity of Practice, Red Hat
Scott McCarty - Senior Principal Product Marketing Manager, Red Hat
Container images will soon underpin all of our mission critical applications. Therefore, we must ensure that we are using the highest quality containers images at every stage of the development cycle on through to production. In this session, our team of experts from Red Hat, Black Duck and Sonatype will present a foundational understanding of managing container-based software supply chains and how to make them more secure. For example, attendees will learn how to ensure that what gets packaged, delivered, and deployed is of the highest quality -- including using secure configurations and avoiding use of known vulnerabilities in open source components. We will also discuss best practices for accelerating the remediation of security defects in containers that have already been deployed. Attend this session and learn how to:
Build and secure enterprise software supply chains with containers.
Benefit from use of Red Hat and other open source technologies, including: public registry of trusted sources for container images (e.g., one hosted by Red Hat) and private registries that host certified container images (e.g., Red Hat Satellite, Nexus Repository).
How to scale and secure thousands of containers using OpenShift Enterprise by Red Hat or Red Hat Enterprise Linux Atomic Host.
Provide the ability to automatically patch and redeploy containers at runtime.
This session is designed to help architects, developers and ops professionals to securely deliver containers for serious production workloads while dealing with the operational challenges of patching and deploying them at scale in an automated manner.
================
I propose a discussion on how anyone secures containers, what process they use to make sure their containers are secure, and what has worked for them. They also brought up dealing with CVEs for containers. Any relevant security discussion regarding containers is welcome in this discussion.
Thanks,
R. Hinton
Responses
I've attended several container presentations by Red Hat and the real sticking point with me is the suggestion that the dream is to move to have the container creation completely managed by developers with ops just 'clicking a button' to deploy the finalised container. I have no issues with building containers as part of the CI/CD, but I have concerns about developers curating containers with all manner of unknowns in the container (projects built from source from random sources, processes running as root etc.). The counter argument to this is that the containers provide additional protections (SELinux, kernel capabilities, namespacing etc.) so you can (almost?) run containers of varying trust levels with some level of reassurance, but I am not convinced this is there yet... and running processes as root in the container is still a concern.
In reality, I have found 'ops' getting more involved early in the build process providing local binary and build repositories (Atrifactory, Maven etc.) to ensure that the inputs for the container CI process are from known/trusted sources. I strongly agree with the point raised by Dan Walsh in 2014 that the Docker world is like the early days of RPMs with many (most?) people not understanding the risks of just fetching random code/containers from the net and executing it... I know Red Hat are aware of the challenges and the work they are putting into signing and trusted image repositories is definitely welcome.
The other concerns I have is ISVs providing/shipping their software in containers (for similar reasons). Unless there is some level of third party validation going on, I am going to question what the ISV has done to build the image (ie. I would be asking for the Dockerfile at the same time). A parellel in the current enterprise reality is ISV provided RPMs and 'appliances' which I have commented on before. Some of the crazy stuff I have pulled out of ISV provided RPMs in the last 15+ years would make your hair stand on end and the multitude of experiences I have had with 'appliances' such as VM images and even hardware appliances has lead me to believe they are often used as an excuse to not provide patches to what is more often than not CentOS underneath.
But back to containers.. I am using them on one site to provide application deployment benefits. To address the security challenges of CVEs inside the containers, the plan is to create a tight CI/CD loop and rather than patching containers that are running, they are rebuilt using newer sources when a security issue is identified. This looks great on paper, but identifying when a compiled container has an impacted library/package to trigger the rebuild process is probably the biggest challenge in keeping the containers secure. The first step was to use trusted sources in the build (ie. locally cached in a binary repository), the next step will likely be some form of container scanning (which is the direction I believe Red Hat are moving towards) in combination with collation of notifications sent from upstream vendors.
The Atomic announcement today looks like a nice jump in features: http://rhelblog.redhat.com/2016/06/30/whats-new-in-red-hat-enterprise-linux-atomic-host-7-2-5/
Container scanning, especially with a pluggable architecture and systemd inside containers (I have hit this requirement, so thanks to Dan Walsh for sticking at it) both look like nice additions. Interested to know if the RHEL 7.3 Docker will be rebased again considering Atomic's jump in version number.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.