Publish vendor neutral blog post for consuming public content

[SteveLasker]

On Monday, October 12, 2020, representatives from Azure, AWS, Google, IBM, Docker, and GitHub met to discuss how, as an industry, we believe we can address the problem. We need a short term solution for the pending November 1st changes that enable stability through the holiday lockdowns, with a longer-term plan that helps customers adapt their workflows.

To avoid customer confusion, and finger-pointing, the cloud vendors and docker have agreed to co-author a paper providing guidance to customers for how they can adapt their workflows in incremental steps. The goal is to provide stability to an ecosystem, with an opportunity to innovate in a common direction. The Open Container Initiative (OCI) was intended to provide a vendor-neutral body of governance. We would like to publish the paper under the OCI umbrella in the coming weeks.

The content will be something like:

• Public content is great to consume, but consider the risks when sourcing public content in mainline/production workflows.
• Consuming public content imposes production risks as it assumes all connections between the production host and the public source are fully available. It assumes the content is in a secure and reliable state, compared to the previously tested version. And, it assumes someone is bearing the costs to host that continually pulled, large content.
• As a best practice, import public content to a private registry, do some amount of incremental testing and utilize from your private registry
• This includes, not building FROM docker hub, rather build FROM your private registry the content you’ve imported and verified
• Automate the importing and verification, to assure you have the latest, but test the latest to assure it's safe and reliable for your environment
• As you adapt your import/verify/promote workflows, docker hub users can provide authentication to avoid throttle limits

The draft doc is located here: Consuming Public Content

We hope to complete the paper by 11/23, giving time for review and posting prior to Nov 1s. Each cloud vendor can then point their cloud specific docs on how to implement a buggered workflow, enabling local reliability and performance, without the risks of accessing public content in critical workflows. The paper will also direct customers to use Docker Authentication for pulls from Docker Hub, providing identity within multi-tenant cloud services.

[SteveLasker]

Putting the Consuming Public Content blog post up for a vote to move forward. As TOB email notifications have been going out, and our goal is to get published by the Docker TOS date on Nov 1, 2020, we're asking TOB members to vote by EOD October 26, 2020 to provide OCI Blog Post maintainers time.

Please vote here, with a corresponding LGTM or any additional comments

• [ ] Vincent Batts (@vbatts)
• [ ] Michael Crosby
• [x] Phil Estes
• [ ] Wei Fu
• [x] Jon Johnson
• [ ] Samuel Karp
• [x] Steve Lasker
• [ ] Derek McGowan
• [ ] Aleksa Sarai

[vbatts]

Hey @SteveLasker, Read over the article. All the points are things folks can understand. I think the core of it is that the call-to-action is soft or implied and seems a bit like "go to your cloud vendor". Am I missing something there?

[SteveLasker]

It’s more about consuming content directly from docker hub, or any public registry. We’re working to not make this about the changes to the Docker TOS, but rather users shouldn’t be dependent on public content for their critical workloads. So, provide your docker credentials to avoid being throttled, but use those credentials to pull the image into a private registry you manage. Thus, you get your public content, but your not at the whim of all the connections from your host to the public registry.

[estesp]

LGTM

[jonjohnsonjr]

LGTM

[SteveLasker]

Closing with the publishing of the post at: https://opencontainers.org/posts/blog/2020-10-30-consuming-public-content/ Thanks everyone