search

rkt / rkt

[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.
Apache License 2.0
8.82k stars 883 forks source link

rkt: clarifications on auth config #742

Open jonboulle opened 9 years ago

jonboulle commented 9 years ago

364 landed the first cut at configuration and HTTP authentication for retrieving ACIs from remote sources. However there are a couple of outstanding questions to address around the configuration:

krnowak commented 9 years ago

Ok, I'll comment on it now, so I won't forget about it. I didn't notice the v0.7.0 milestone before. Sorry for the wall of text.

So, if we are going to add wildcards here then there are three things to consider, where each item has an effect on next one - wildcards behavior, order of domain evaluation and override semantics.

I can see three wildcards behaviors:

  1. Regexp-like - wildcard behaves like .*. foo.b*e would match foo.be, foo.bar.de and so on.
  2. Glob-like - wildcard behaves like * in shell, but it terminates against a dot or colon instead of slash. foo.b*e would match foo.ble, foo.be, but not foo.bar.de.
  3. Limited glob-like - like 2, but each part of domain can be either a wildcard of a full name. foo.b*e would be simply invalid. foo.* would match foo.be, foo.de, foo.com and so on.

By "order of domain evaluation" I mean that we have a list of wildcarded domains and that list has to be somehow ordered. (Don't take the "list" word too literally, as a data structure or anything like that - it is just about traversing it. In implementation that would be probably a tree.) While evaluating the domain we would go through the list and stop on first match. Best effort would be an order from most specific wildcard domain to most general. That way we have a chance of matching against some specific domain before some "catch-all" wildcarded domain (like *.* or something).

I feel that the first option is basically opening a can of worms with regards to order of evaluation - I'm sure that we could specify two such wildcarded domains for which we couldn't say which is more specific, that is - against which of those two a domain should be matched first. For example: wildcarded-domains: *.c*m and *.d*m, domains to check - foo.data.com and foo.cata.dom. An option for specifying order of evaluation would be specifying the order of parsing configuration files (leading to filenames like 01-parse-this-first.json or 99-catch-all.json) and taking "domains" field as is. In short - ordering would be in hands of people writing the configuration.

The second and third option give us a possiblity to create some well-defined, unambiguous ordering of wildcarded-domains from most specific to most general automagically, without resorting to some filesystem-related gimmicks. I'd opt for the limited variant for the simplicity of implementation. The relaxed variant could be implemented later as I think it would be backward-compatible with limited variant.

By using second or third option we wouldn't have to worry overmuch about override semantics. Those would be not much different from what we have now, that is (bold is the difference) - if given wildcarded-domain was already specified, then replace credentials associated to it with something else. Otherwise, put the wildcarded-domain into the list preserving the order. By using first option we would need to specify a way to override not only credentials, but also ordering. I haven't pondered on override semantics for first option so far.

My take would be - if we want wildcard domains, subdomains or whatever then implement the third option. As a feature in future we could implement second option.