-
Notifications
You must be signed in to change notification settings - Fork 359
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
Oathkeeper behind ssl terminating balancer #153
Comments
Does the forwarded request include |
Yes, I have Or must I specify |
No, in that case it would make sense to have |
This is my nginx config:
In this case Edit 1: Ive set my nginx config to EDIT 2:
And when i make a request to https://gateway.***/status
|
In the log i see the following message (it is clear it is passing http)
|
@Entrio did you manage to fix this? I'm having similar issues with oathkeeper api failing to match the url to the rule. |
No, I've had to settle down to using http in rules as it doesn't take into account |
I would like to know whether there is any update on this, we managed to set up our Istio environment so that the header This is, in my opinion, a massive security issue as the solution proposed by @Entrio:
is a very big security hole and something I would never ever recommend in a production environment. Let's take as an example a payment API where requests get routed via oathkeeper, if the header We can, of course, enforce HTTPS via e.g. Load Balancers, Istio rules, etc., but I believe this is beyond the point. This issue is promoting really bad and potentially harmful practices such as whitelisting and allowing everything regardless of the protocol in use. |
@christian-roggia completely agree. I can understand ory.sh position somewhat, they assume and recommend that oathkeeper is running in a secure environment but still... I have deployed ory stack on multiple projects now since I initially brought this up to attention (it has been 2 years!) and I've had no issue with using http as matching proto. Maybe that now more and more people are raising this issue, maybe @aeneasr can look into it? :) |
In our case mTLS is managed by Istio and therefore all communication intra-cluster happens via TLS, while our ingress exposes only HTTPS (we completely disallow connections via HTTP). The fact that oathkeeper is not honoring the header is even more disruptive for us as users get wrongly redirected to the http (instead of https) address where they will be met with an error message (we are waiting for Unfortunately, I have a lot on my plate right now, otherwise I would've taken over this task myself. |
#638 Doesn't solve the issue for me. Tested with ORY Oathkeeper v0.38.9-beta.1.pre.2 I have the same setup as described in #153 (comment) And I am still getting
|
Have you tried to use the latest |
@christian-roggia I tried with v0.38.9-beta.1.pre.2, which already contains the change from #638. As you have mentioned in #638 the change "affect only the decision API". However, in my case and I assume in @Entrio's case, we use oathkeeper as a reverse proxy. The mechanism doesn't invoke The request's scheme is filled in Trace:
|
I have deployed ory os on various systems and I always run into the same issue when dealing with oathkeeper. In my case there is an nginx server that terminates all https requests and forwards the traffic to an oathkeeper upstream server.
Due to the nature of this setup, I always have to specify my match rules as http protocol as that is what nginx passes to oathkeeper.
Can someone point me in the right direction on solving this issue? I could not find anything in the documentation.
Thanks
The text was updated successfully, but these errors were encountered: