New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combination of http and passthrough routes bound to the same host confuses ha-proxy #5946

Closed
jpechane opened this Issue Nov 18, 2015 · 18 comments

Comments

Projects
None yet
@jpechane

jpechane commented Nov 18, 2015

Use route configuration

apiVersion: v1
items:
- apiVersion: v1
  kind: Route
  metadata:
    name: ws-test-route
  spec:
    host: ws.jpechane.cloudapps.example.com
    to:
      kind: Service
      name: ws-test-service
- apiVersion: v1
  kind: Route
  metadata:
    name: ws-test-route-secure
  spec:
    host: ws.jpechane.cloudapps.example.com
    tls:
      termination: passthrough
    to:
      kind: Service
      name: ws-test-secure-service
kind: List
metadata: {}

Haproxy creates record in os_sni_passthrough.map and os_tcp_be.map instead of http and passthrough

@danmcp danmcp changed the title from Combination of hettp and passthrough routes bound to the same host confuses ha-proxy to Combination of http and passthrough routes bound to the same host confuses ha-proxy Nov 19, 2015

@ramr

This comment has been minimized.

Contributor

ramr commented Nov 20, 2015

@jpechane that looks correct because both the routes have the same hostname ws.jpechane.cloudapps.example.com

and the algorithm for multiple routes w/ the same name causes the oldest route to win and in this case the route for the passthrough termination wins and really is the equivalent of this config:

apiVersion: v1  
items:  
- apiVersion: v1  
  kind: Route   
  metadata:  
    name: ws-test-route-secure  
  spec:  
    host: ws.jpechane.cloudapps.example.com  
    tls:  
      termination: passthrough  
    to:  
      kind: Service  
      name: ws-test-secure-service  
kind: List  
metadata: {}  
@ramr

This comment has been minimized.

Contributor

ramr commented Nov 20, 2015

Do you want to add an secure (passthrough) + unsecure route? The only way to currently do that is have a secure edge terminated route and use an insecure edge termination policy on that route that allows traffic on the insecure scheme (aka http).
See: https://docs.openshift.org/latest/architecture/core_concepts/routes.html#secured-routes for more details - example 7 and 8 in particular.

Doesn't support passthrough routes as of now, so would be interested in hearing your use case. Thx

@ramr

This comment has been minimized.

Contributor

ramr commented Nov 20, 2015

@danmcp I can't update the labels on this issue - this one needs an enhancement tag. Thx

@jpechane

This comment has been minimized.

jpechane commented Nov 23, 2015

Hi, this worked on 3.0.x. A use case can be web service deployed on EAP that is accessible via https but it wants to publish its WSDL over http.

@ramr

This comment has been minimized.

Contributor

ramr commented Nov 23, 2015

@jpechane , k I can understand needing both http and https but what I was asking was could the secure connection be terminated at the edge? In any case, working on a PR to support this with passthrough termination. Thx

@jpechane

This comment has been minimized.

jpechane commented Nov 24, 2015

What if I want to have certificates managed by the application users/admins? In that case it would be quite difficult to achieve this with edge termination - this I consider to be the main use case.

@liggitt

This comment has been minimized.

Contributor

liggitt commented Nov 24, 2015

In that case it would be quite difficult to achieve this with edge termination

Are you expecting the application admin to not have API access to this route in the namespace?

@jpechane

This comment has been minimized.

jpechane commented Nov 27, 2015

The application admin can be an application-level role - separated pro OS project admin

@liggitt

This comment has been minimized.

Contributor

liggitt commented Nov 30, 2015

I think application-managed certs being surfaced through the route would only be doable with the passthrough TLS type.

@mchudgins

This comment has been minimized.

mchudgins commented Mar 9, 2016

One use case: TLS encryption is desired all the way to the application. Rather than have two sets of certs (one for the router, one for the app) and use"reencrypt", it may be more convenient/desirable to use "passthrough". However, in this case the route api does not allow either a "redirect" (can only be used with edge termination) nor does it allow a second http route to the application (which can in turn send a redirect).

@git001

This comment has been minimized.

git001 commented Mar 24, 2016

How comes that such a common use case like http => https is so difficult to be handled in Openshift?
How can we higher prioritize this issue to be able to make this case simple to use?

@smarterclayton

This comment has been minimized.

Member

smarterclayton commented Mar 31, 2016

I would agree that the termination policy should be more sophisticated - redirect should be possible on passthrough, and all settings should be present on reencrypt.

@smarterclayton

This comment has been minimized.

Member

smarterclayton commented May 5, 2016

@ramr can you comment on current status here?

@ramr

This comment has been minimized.

Contributor

ramr commented May 6, 2016

@smarterclayton I haven't looked at this in a while - we initially had decided to only do it for edge terminated routes and do it for others as we got requests for it. So looks like it has a fair bit of interest now. Will schedule some time to work this in. Thx

@aikebah

This comment has been minimized.

aikebah commented Oct 1, 2016

Any progress on getting at the least a redirect to https in for passthrough https? Found this issue after running into the unability to configure an http route to an https passthrough routed app+website.
The website (providing the commercial talk promoting the app) would be fine with plain http, but the app hosted side-by-side with this descriptive site should only be accessible via TLS, terminated at the application level.
Having the site only truly accessible with TLS would be fine, as long as the http-access attempts for the domain would get routed to the TLS version (instead of showing an Application is not available page as the hostname is not routed for http)

@mrGrab

This comment has been minimized.

mrGrab commented Mar 13, 2017

one more complaints - need redirect (or pass) http to https with passthrough route with termination type.
Or possibility to have one hostname to few ports.. Any idea how to implement it?

@pweil-

This comment has been minimized.

Member

pweil- commented Jun 26, 2017

@knobunc

This comment has been minimized.

Contributor

knobunc commented Jun 26, 2017

@aikebah @mrGrab This was changed in #11953 "Implement insecureEdgeTermination options for reencrypt and pasthrough routes"

@knobunc knobunc closed this Jun 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment