Docker Hub is home to the world’s largest library of container images. Millions of individual developers rely on Docker Hub for official and certified container images provided by independent software vendors (ISV) and the countless contributions shared by community developers and open source projects. Large enterprises can benefit from the curated content in Docker Hub by building on top of previous innovations, but these organizations often require greater control over what images are used and where they ultimately live (typically behind a firewall in a data center or cloud-based infrastructure). For these companies, building a secure content engine between Docker Hub and Docker Trusted Registry (DTR) provides the best of both worlds – an automated way to access and “download” fresh, approved content to a trusted registry that they control.
Ultimately, the Hub-to-DTR workflow gives developers a fresh source of validated and secure content to support a diverse set of application stacks and infrastructures; all while staying compliant with corporate standards. Here is an example of how this is executed in Docker Enterprise 3.0:
Image Mirroring
DTR allows customers to set up a mirror to grab content from a Hub repository by constantly polling it and pulling new image tags as they are pushed. This ensures that fresh images are replicated across any number of registries in multiple clusters, putting the latest content right where it’s needed while avoiding network bottlenecks.
Access Controls
Advanced access controls let organizations to set permissions in DTR at a very granular level – down to the API. Images from Docker Hub can be mirrored into a restricted repository in DTR with access given only to qualified content administrators. The role of the content administrator is to ensure that the images meet the company’s policies.
Image Scanning
Once in the restricted repository, content administrators can set up automated vulnerability scanning which gives organization fine-grained visibility and control over the software and libraries that are being used. These binary-level scans compare the images and applications against the NIST CVE database to identify exposure to known security threats, providing organizations a chance to review and approve images before making them available to developers.
Policy-Based Image Promotion:
With DTR, content administrators can set up rules-based image promotion pipelines that automate the flow approved images to developer repository. (E.g. “Promote Image to Target if Vulnerability Scan shows Zero Major Vulnerabilities”.) This streamlines the development and delivery pipeline while enforcing security controls that automatically gate images, ensuring only approved content gets used by developers.
Image Signing
Digital signatures are used to verify both the contents and publisher of images, ensuring their integrity. Customers can also take this a step further by requiring signatures from specific users before images are deployed, providing an additional layer of trust. This allows content administrators to validate that they have approved images in the developer repositories. Developers and CI tools can apply signatures as well.
End-to-End Automation
The entire workflow outlined above can be automated within Docker Enterprise 3.0 – from image mirroring, to vulnerability scans that are triggered based on new content, to promotion policies and even the CI workflows that add digital signatures. This end-to-end automation enables enterprise developers to innovate on top of the vast content available in Docker Hub, while adhering to secure corporate standards and practices.
Learn how to combine @Docker Hub and Docker Trusted Registry with #Docker Enterprise 3.0 for a secure content workflowClick To Tweet
To learn more about Docker Enterprise 3.0:
Register for the Upcoming Docker Enterprise 3.0 Virtual Event
Try Docker Enterprise for yourself trial.docker.com
Learn more about Docker Trusted Registry
The post A Secure Content Workflow from Docker Hub to DTR appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/
Published by