Today, security is one the biggest topics within the enterprise world and tops the list of enterprise IT initiatives. As companies have begun to adopt containers within their environments, they have realized the security benefits that come with them as well. Enterprises can now use containers as a means of actually reducing risk within their organization. Containers are isolated from one another, using the same kernel, but are completely unaware that each other exists. This isolation acts a natural security mechanism, making it difficult for hackers to break into environments and gain control of enterprise applications.
In last week’s webinar, Dr. Diogo Monica, Security Lead at Docker, gave an introduction to Docker security, and explained how Docker solutions can help your organization build, ship and run applications, while also remaining secure and compliant. You can watch the webinar here.
Below is some Q&A on Docker Security:
Is there a major difference between open source registry and Docker Trusted Registry when it comes to security?
Yes. Trusted Registry comes with RBAC controls out of the box (support for repositories, organizations, AD/LDAP integration, etc), allows you to easily manage your registry settings from a centralized place (certificates, admins, etc) and also supports Docker Content Trust, which means you can easily integrate code signing into your Docker deployment process.
Q: Are there any size restrictions to files that can be signed in the Docker Content Trust?
No. Docker Content Trust works by giving you digital signatures over a map between tags and cryptographic hashes. These tags are then used by Docker as the digest for the pull-by-digest mechanism, which uses the content addressability nature of the Docker registry to ensure the content you download is the content you actually wanted. We currently do not support image encryption either in DTR or Docker Hub.
Q: For AAA, are you leveraging Linux Pluggable Authentication Modules?
Right now, you can do arbitrary plugins which means that you can actually develop anything that you want. We expect 3rd party plugins to show up and provide some advanced integration into whatever you would like, including Linux Pluggable Authentication Modules.
Q: We do not have the expertise to build docker images but if we take it from your hub, how much do you support and feel responsible for the security compliance in your images?
We are responsible for the quality and security of our official images. If you are basing your images on the official repositories you know that we’ve scanned and collaborated with the image publishers to ensure they are up-to-date and vulnerability free. Depending on official images for your applications means that your process for updating is essentially rebuilding your container, getting all the updates and patches that Docker has applied to the upstream image, and re-deploy. You will still be responsible for the vulnerabilities in your applications, but as long as you rebuild them based on our official images and you update the upstream source, you will always have the latest and greatest.
Q: Do you have something on the roadmap for secrets management? What are some best practices.
Secrets management is something that I’m very passionate about. Key management is something that we are addressing in the short-term. We are adding some capabilities to our products around digital signing, but we will also be adding capabilities to our commercial products for secrets management. The idea is that if you buy a commercial product like Docker Universal Control Plane, you will have secrets management already built into the solution and vertically integrated into Docker. From a community perspective we have recommendations of what you should use and how you should use it. We are not sure at this point how the open source component will be integrated, but we believe that it will be something around in-memory volumes mounted into the containers, allowing your applications to have access to secrets. One of the things that I am against is putting secrets inside of the layers of Docker images, or environment variables, so do not do that.
Q: Where can we find a list of what nautilus scans for?
Right now Nautilus is only being used to scan the official images in the background, so it’s not public yet. Would urge you to wait until Q1 when we will be releasing more information about it. We will provide more insight into actually what’s happening under the hood.
Do your plan to open source Project Nautilus so people can use it on their own private deployments or will it only be able within your infrastructure?
We know that we will provide the scanning of all official images for free. One of our big goals is to have the Docker hub be the safest place folks can go for content. And it is because we are working tirelessly to make sure that those images are scanned and are not vulnerable. We are also exploring the commercial opportunities of this solution as well. So if you are looking at using our on-prem registry you will probably get it as an add-on. But as of right now there are no plans to open source the scanning techniques, because not all of them are ours. We augment with some 3rd party providers combined with our own techniques to make sure they are as complete as possible. If you have been pulling from the official images within Docker Hub then you have already been protected by these scans, but it’s not 100% clear on how we will make it available to others as well.
Q: What if YubiKey is lost?
Hardware signing means that Yubikey has the responsibility of having your root key inside of it. The way that we designed the system is so that you can import keys into the Yubikey. This means that you can have a Yubikey with the root key and also have it encrypted within a USB key and place it inside of a safe somewhere. In the case the the Yubikey gets lost, you simply take the USB key from the safe and you load it into a brand new Yubikey.
Q: Good to see RBAC, but how does Docker handle ABAC
Docker currently will allow RBAC and already does for our commercial products. This is something that we wanted to have as an added value feature, so you can deploy commercial products and already have the RBAC built into the product. In terms of the Docker engine itself, what we did was to create a generic authorization mechanism. This will allow you to write arbitrary plugins to do what you want, whether they are Role or Attribute based.
Q: With respect to Notary repository keys and automation. Is a CI “just considered another developer machine” or what other care/procedures should one have in mind?
As of right now the CI is considered to be another developer machine. Which means you can take keys from under the CI. Which is actually a really powerful way of doing things. We are about to merge delegations into Notary very soon. Delegations will allow us to have more complexity around the responsibility of specific repositories of who signs what, and the ability to have for example threshold signatures. But yes, as of now CI is just another developer machine.
Security is something that we at Docker are extremely excited about. The ability to enable enterprises to not only build, ship and run their applications. But to do it in a way that gives them security and control over their environment. The resources below provide more information that you might find helpful. As always, you can reach out to us with any questions that you have.
- Sign up for a free 30-day trial of Docker Subscription to get the essential software, support and security you need
- Watch the webinar replay
- Watch the Content Trust demo
- Sign up for the Beta of Docker Universal Control Plane
Learn More about Docker