Ingress controller: TLS support

[zcahana]

Ingress resource specification allows to secure an ingress by specifying TLS configuration which is used for TLS termination.

This probably needs to be resolved as part of the larger story of TLS support within the Istio proxy (see #52).

[kyessenov]

Istio Auth alpha design omits ingress entirely. We should do an ad-hoc solution using secrets/configmaps following kubernetes practices and revisit this once the in-cluster auth is past alpha.

[rshriram]

I think Isaiah is starting to take a crack on that.

On Tue, Mar 14, 2017 at 12:39 AM Kuat ***@***.***> wrote: Istio Auth alpha design omits ingress entirely. We should do an ad-hoc solution using secrets/configmaps following kubernetes practices and revisit this once the in-cluster auth is past alpha. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd_80G4GHZIymBiAOMwgt-Hv_icidks5rlhnygaJpZM4MNE54> .

-- ~shriram

[ijsnellf]

#352 provides basic TLS support for ingress.

[ijsnellf]

Does anything else need to be done for this issue for alpha?

[zcahana]

I don't know about alpha vs. future prioritization, but I think we should at least support reading TLS secret name from ingress resource, as specified here. That should probably be satisfactory TLS support to start with.

[zcahana]

The main obstacle for implementing this is that it's still unclear how to represent the ingress TLS configuration in the model.

One option that @Kuat raised in #151 was to create a different model object for ingress (e.g., IngressRule) and use that instead of RouteRule.

Another option is to extend the model with some more specific object (e.g. a TLSContext associating a port/vhost to a secret) and also extend the RouteRule.Match so that we can indicate that a RouteRule (derived from an ingress) is for HTTPS traffic.

Thoughts?

[rshriram]

I think we have worked out a solution to that for the interim. Waiting on Isaiah to finish his PR for this.

On Tue, Apr 4, 2017 at 9:11 AM Zvi Cahana ***@***.***> wrote: The main obstacle for implementing this is that it's still unclear how to represent the ingress TLS configuration in the model. One option that @Kuat <https://github.com/kuat> raised in #151 <#151> was to create a different model object for ingress (e.g., IngressRule) and use that instead of RouteRule. Another option is to extend the model with some more specific object (e.g. a TLSContext associating a port/vhost to a secret) and also extend the RouteRule.Match so that we can indicate that a RouteRule (derived from an ingress) is for HTTPS traffic. Thoughts? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd-MHvbUdVTEJpZRqJvz3GV9jBvbiks5rskGSgaJpZM4MNE54> .

-- ~shriram

[zcahana]

@rshriram are you referring to the TLS secret name passed with a flag to the manager?

[rshriram]

Yep. Trying to model the ingress specifically for kubernetes seems odd. Ideally it should be part of auth but that's a different conversation. Besides, all route rules deal with a destination service (from perspective of caller). We do not have configuration constructs that deals with a service from perspective of a service provider or server. Today they are baked into k8s. What kinds of certs does the service have, what kinds of policies does it want to expose, etc. a slightly similar argument applies for egress to external services, where mutual tls auth may not apply. I think these are part of service configurations and they have to be made as first class entities and dealt with in proper manner.

On Tue, Apr 4, 2017 at 9:27 AM Zvi Cahana ***@***.***> wrote: @rshriram <https://github.com/rshriram> are you referring to the TLS secret name passed with a flag to the manager? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd3z7wdPiFC37ENXyAlunqW9LTMuyks5rskVFgaJpZM4MNE54> .

-- ~shriram

[kyessenov]

I was thinking how ingress differs from the regular route rule. If you think of ingress proxy as a special service, then the main difference is that the destination weight field refers to a different service than the ingress. E.g.

destination: ingress-service
match:
  httpHeaders:
    uri:
      prefix: /a
route:
- destination: a.default.svc.cluster.local

This poses two questions:

• do we apply route rules towards the destination service, that is do we unroll the target destination into a bunch of route rules? if we allow any route rule to refer to a distinct destination in the route than its destination, then how do we prevent multiple unrolls, e.g. if "a.default" is actually routing to "b.default", do we also apply rules of "b.default"?
• should TLS context be a property of the route? I think @rshriram is proposing to use "authority" header to uniquely identify the TLS certs but then nothing in our model prevents from using multiple route rules that use the same "authority".

[rshriram]

You are right that we can use route.destination for ingress. However, the top level destination cannot just be targeting istio-ingress. Users could define custom hosts like foo.bar.com and route it to a.default. So we can capture these by allowing users to use foo.bar.com as the top level destination field. While generating configs for ingress envoys, we should accept rules with destinations that do not match any internal service. destination: foo.bar.com route: - destination: a.default.svc.cluster.local tags: version=v1.. weight: 50 When generating Envoy configuration, we need to have foo.bar.com in the virtual host domain match, and the rest of istio-ingress in wildcard match. With regard to unrolling multiple times, it's something we will have to do eventually, imo. But we could cross the bridge when we get there. Typical ingress specs don't unroll. And our typical routing examples do not unroll either (yet). Now with respect to tls certs, we can model it internally but do we have to capture it in the route rule? Because these can be specified via the ingress resource (internal tls is handled by auth already).

On Wed, Apr 26, 2017 at 12:06 AM Kuat ***@***.***> wrote: I was thinking how ingress differs from the regular route rule. If you think of ingress proxy as a special service, then the main difference is that the destination weight field refers to a different service than the ingress. E.g. destination: ingress-service match: httpHeaders: uri: prefix: /a route: - destination: a.default.svc.cluster.local This poses two questions: - do we apply route rules towards the destination service, that is do we unroll the target destination into a bunch of route rules? if we allow any route rule to refer to a distinct destination in the route than its destination, then how do we prevent multiple unrolls, e.g. if "a.default" is actually routing to "b.default", do we also apply rules of "b.default"? - should TLS context be a property of the route? I think @rshriram <https://github.com/rshriram> is proposing to use "authority" header to uniquely identify the TLS certs but then nothing in our model prevents from using multiple route rules that use the same "authority". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd0NQku0vxXcYUFoClwNtmsW32sYPks5rzsLfgaJpZM4MNE54> .

-- ~shriram

[kyessenov]

• I'm not so sure whether we want to allow external service names as destinations. Destination after all is inside the cluster. One idea could be to mark a route rule as "external" and that will expose the rule outside the cluster. The ingress service will be an implementation detail. In the example above:

destination: a.default.svc.cluster.local
external: true
match:
  httpHeaders:
    authority: 
      exact: my.domain.com
    uri:
      prefix: /a

Using authority as a destination has some drawbacks: how do we handle the wildcards (*.my.domain.com)? I find it confusing to have two destinations "my.domain.com" and "a.default.svc.cluster.local" for the same route...

• TLS is a property of route as defined by Ingress spec. You can have TLS and non-TLS paths for the same domain which is a reasonable use case.

[rshriram]

support exists as of istio 0.1.6

[kyessenov]

TLS is rather half-baked. No SNI and poor security with secret transfer. Leave it open until it's beta-quality.

[rshriram]

Just SNI left. Secret transfer sorted out.

[rshriram]

#484 is tracking SNI support..