Router TLS configuration

[olix0r]

Once #21 is merged, we'll need a way to configure clientside TLS on the router. I can think of at least 2 or 3 different configurations we'll want to support, so this should be modular (and perhaps pluggable, so that users may implement their own crazy policies).

Static validation

routers:
- protocol: http
  tls:
    kind: static
    name: buoyant.io

Per-service validation

routers:
- protocol: http
  baseDtab: /http/1.1/GET => /io.l5d.k8s/default/http
  tls:
    kind: boundPath
    certPath: /path/to/ca.pem
    matches:
    - prefix: /io.l5d.k8s
      name: ${3}.buoyant.io

The matchers should:

• extract the Name.Bound.id (we may want to explicitly put this on the stack rather than relying on BindingFactory.Dest).
• Path.read(Name.Bound.id)
• If a prefix matches:
  • strip the prefix
  • compute offsets in name against the path post-prefix-stripping. If the offset is out of range, the match should not apply
• if any of these steps fail or a match is not found, TLS should not be applied
• multiple matches should be able to specify overlapping prefixes

Parsing the name values may be slightly tricky, but we can probably write a parser-generator to do this.

No validation

routers:
- protocol: http
  baseDtab: /http/1.1/GET => /io.l5d.k8s/default/http
  tls:
    kind: noValidationYoloSwag

(And, yes, i think that's what that option should be called.)

Per-host validation

We can probably punt this down the road, but, we can use the IP or Hostname of the individual destination address as the peer's name.

[olix0r]

I've split out per-service validation into #64 so that establishing base functionality (no validation + static name validation) can be done independently of figuring out all of the matcher stuff.

[olix0r]

It occurs to me that we don't need a special static tls client configuration, as this is just a special case of per-service validation:

- kind: dstRewrite
  matches:
  - prefix: /
    dst: linkerd.io

(i still haven't found a great name for this module)

See #65 for more details, but this should be effectively the same as a static configuration. I'm not sure if it makes sense to provide 2 modules for this or not...

[adleong]

I'm going to do Static and No Validation in this ticket. I've filed #64 for per-service and we can delete the Static module then if it's just a special case of that.

[klingerf]

Quick question about the config file format for TLS. I notice that all of your example configs look something like:

routers:
- kind: http
  tls:
    kind: boundPath

But in master right now, we use protocol for each router, not kind, in which case the config ends up looking like:

routers:
- protocol: http
  tls:
    kind: boundPath

Since TLS is itself part of the protocol, how would you feel about nesting all of the tls options under the protocol section? Having a protocol and a separate tls section feels confusing to me.

[adleong]

Are you suggesting:

routers:
- protocol:
    name: http
    tls:
      kind: boundPath
  servers:
  - port: 0

That seems pretty reasonable to me.

[klingerf]

Yep, or we could keep the "kind" field, like:

routers:
- protocol:
    kind: http
    tls:
      kind: boundPath
  servers:
  - port: 0

[olix0r]

kind on the protocol was just an oversight. It should be protocol. I don't think we should change it. I think the TLS field should be called kind or module or something