Name Delegation Design Discussion

[philips]

DNS delegation is the idea that I can own the domain example.com but delegate hosting of my container images to container.hosting. Think MX records, where I have a DNS name that tells me where to send email for a domain without the dedicated special DNS record.

Today, AppC supports a method for doing this type of delegation that uses HTTPS, and HTML meta tags. This type of delegation is inspired by the method used by the go get package management system as well.

One critique of this method is that there is an RFC for this sort of meta information called 'well-known URIs'. I believe that using this type of well-known scheme is a better choice today and will stay out of people's way better; in fact we prototyped this in a project called abd.

FAQ
Why not DNS: If we used DNS it would make it hard to bootstrap trust of this source based on the existing well understood TLS infrastructure on the internet today. With systems like Let's Encrypt in place today I think it would be smart to rely on this existing trust root. We do this in rkt today and it works nicely.

But I have this way better way of doing delegation: We can add additional methods, but having some method to start for delegation is super helpful.

I don't want to allow outbound traffic to the internet: Container engines can allow for this feature to be turned off or configure that certain domains are statically delegated to internal mirrors. This is all about having a default UX.

[wking]

On Wed, Apr 06, 2016 at 05:15:43PM -0700, Brandon Philips wrote:

I believe that using this type of well-known scheme is a better
choice today and will stay out of people's way better…

I think blob delegation should be outside the scope of the image
format, since blobs that are content-addressed based on a
cryptographic hash can be fetched from any content-addressable storage
(CAS)—although registries probably want to include hints about hosts
providing blobs required by a given image 1. Baking CAS repository
information into the image manifests requires folks to make
distribution-time decisions at image-creation time (and image authors
and distributors need not be the same people).

 Subject: DNS-based delegation (was: Proposal for a new project: OCI Image Format Spec)
 Date: Sat, 12 Mar 2016 15:34:11 -0800
 Message-ID: <20160312233411.GB10073@odin.tremily.us>

[philips]

@wking This isn't about blob delegation. This is about delegation of naming for images. Which is explicitly in scope (see the README).

[wking]

On Thu, Apr 07, 2016 at 06:47:35AM -0700, Brandon Philips wrote:

@wking This isn't about blob delegation. This is about delegation of
naming for images. Which is explicitly in scope (see the README).

Ah, it's just about discovering manifest hashes. Developing and
versioning the separate image/naming/signing components 1 in a
single repository sounds complicated to me (do you make a major bump
when you adjust the naming spec, even though you haven't touched the
image spec?). But discovering manifest hashes using an approach like
this sounds like one of several reasonable registry approaches to me.

[stevvooe]

@philips Let's make a note here to consider cases such as notary for naming delegation.

Have we decomposed naming delegation to particular set operations?

[philips]

@stevvooe I don't see how notary relates to name delegation. Do you have a doc?

[philips]

@stevvooe Ping.

[stevvooe]

@philips You can read here. The link is fairly straightforward. Let me know if you have more questions.

Perhaps, I am misunderstanding naming delegation. We may need a clear definition and identification specific use cases it solves for the individual user. Part of the crux with naming delegation is that it is great for ISVs and service providers but I'd like to better understand where the user gains benefit. We struggled with our efforts from this angle when we looked into this. If I were, say, a data scientist, why should I have to setup DNS and a web service to deploy software in my local infrastructure?

I do find such strategies as go get or well-known urls to be elegant but getting them reliably deployed can be a nightmare in some organizations (well-known being the clear winner here, perhaps).

We also may want to value offline use cases slightly higher. In typical deployments, there may only be a few organizational mirrors. In the abd examples and some of the proposals we had in this area, it focuses on mirrors in the Internet at large but it seems more likely to have a local mirror, rather than spreading requests across the internet.

[ibuildthecloud]

Every enterprise I work with wants a trusted repository of data. This is a model they are very familiar with. Think rpm/deb repo or Java's maven repos. How does this name delegation model work for this model? For example imagine nginx comes from nginx.com. But in the "enterprise" they want to mirror the images from nginx.com to their local servers such that when a user pulls "nginx" it goes to the on prem repo and not the internet.

[philips]

Configuration to declare where the mirror is for nginx.com or more likely
'*'. It is just namespaces that has some default useful semantics.

On Thu, Apr 21, 2016, 7:49 PM Darren Shepherd notifications@github.com
wrote:

Every enterprise I work with wants a trusted repository of data. This is a
model they are very familiar with. Think rpm/deb repo or Java's maven
repos. How does this name delegation model work for this model? For example
imagine nginx comes from nginx.com. But in the "enterprise" they want to
mirror the images from nginx.com to their local servers such that when a
user pulls "nginx" it goes to the on prem repo and not the internet.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#11 (comment)