Last month, Stone Door Group teamed up with Mirantis to deliver a free, 4-part series of one-hour workshops on various DevOps topics to sharpen your Docker and Kubernetes skills. Our first webinar focused on how to get Docker Enterprise running in 1 hour. Our second webinar provided Docker Tips for Better Productivity.
Our third webinar in this series “Docker Tips for Better Security” demonstrates ways administrators can leverage the full features of Docker Enterprise Edition for corporate compliance and regulatory requirements. Topics include in depth review of content sourcing and scanning, best practices on securing registries, and implementing appropriate authorization for container runtimes.
There is still one last chance to join us in May, and we’d love to see you! The final topic in our four-part series is “Kubernetes Tips for Better Productivity”
Register here: https://www.stonedoor.io/docker-webinar
Links to Recordings
Session #1 - Getting Docker Enterprise Edition Running in 1 Hour
Session #2 - Docker Tips for Better Productivity
Session #3 - Docker Tips for Better Security
About the Presenter
Amber Ernst is a Docker Certified Associate and Docker Accredited Instructor for Stone Door Group, a Professional Docker Value Added Reseller. Amber is a Docker and Kubernetes expert who currently teaches all courses in Docker’s official training catalogue and is based in San Antonio, TX.
About Stone Door Group Docker CE to EE Accelerator
Our Docker CE-to-EE Accelerator℠ transforms your development instance of Docker CE into a compliant, enterprise container platform. We understand your developers’ passion for momentum, and your security team’s need for regulatory compliance. Our engagements increase the velocity of feature releases, while implementing operational, security, and regulatory requirements. For more information, drop us a line at letsdothis@stonedoorgroup.com.
The following is a curated list of questions from the Q&A during our webinar that contain information about Docker security
What tools are available to perform security scans on containers for Docker?
Docker Trusted Registry has a security scanner built-in, there is no need to need to bring your own tools.
It hashes binaries found in image layers and compares those hashes to databases of known vulnerabilities.
https://docs.docker.com/ee/dtr/user/manage-images/scan-images-for-vulnerabilities/
Is it possible to retag an image directly in the registry?
Absolutely, we refer to it as image promotion in the Docker Trusted Registry. To perform this inside of the DTR, you can click into Repositories > Promotions - this will take you into a section to specify the criteria and variables related to promoting your image.
This will take your image and effectively re-tag it as another image. You have the ability to do this manually, or follow the path mentioned above and set this to be done automatically, based on criteria you set.
https://docs.docker.com/engine/reference/commandline/tag/
Suppose I have a DTR set up in Cluster A, but due to some infrastructure issues I want to stop using this cluster and create a new cluster on a cloud, would I be able to migrate it to a new cluster?
Disaster recovery scenarios like that are best supported by IaC (infrastructure as code) solutions. Ideally, your entire Docker Trusted Registry (DTR) configurations should ideally be captured as a set of API calls that you can re-play in disaster recovery.
https://success.docker.com/article/dr-failover-strategy
Is it possible to integrate Docker Content Trust in a CI/CD environment?
Yes, and you absolutely should! Security scanning should be part of your testing pipeline, and content trust signing should be performed at the end of the pipeline before deploying to production.
https://success.docker.com/article/dev-pipeline
Is there any recommendation on whether the “latest” should be used when requiring signing and immutability? We have had trouble using the “latest” tag with DTR. Once signed, DTR doesn't let us easily replace the "latest".
I strongly recommend avoiding the use of the tag ‘latest’ in all cases. It is better to specify concrete semantic versioning tags for clarity and stability.