clever-dog-94775
06/10/2023, 5:50 AMingress:
annotations:
<http://nginx.ingress.kubernetes.io/auth-url|nginx.ingress.kubernetes.io/auth-url>: <http://oathkeeper.internal.domain:4456/decisions$request_uri>
<http://nginx.ingress.kubernetes.io/auth-signin|nginx.ingress.kubernetes.io/auth-signin>: <http://kratos.public.domain/self-service/login/browser?return_to=$scheme://$host$escaped_request_uri>
<http://nginx.ingress.kubernetes.io/auth-snippet|nginx.ingress.kubernetes.io/auth-snippet>: |
proxy_set_header Content-Length "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Method $request_method;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Scheme $scheme;
proxy_set_header X-Forwarded-URI $request_uri;
proxy_set_header X-Original-URL $request_uri;
oathkeeper configuration:
config:
authenticators:
cookie_session:
enabled: true
config:
check_session_url: <http://kratos-public.internal.domain/sessions/whoami>
extra_from: "@this"
subject_from: identity.id
only: [ ory_kratos_session ]
forward_http_headers: [ ...all from below config ]
The trouble is that with this scheme, after successful authorization, kratos does not work as expected. Logs in dev mode for all are insufficient and I don't understand whats happening but kratos from /sessions/whoami on its own goes to some service request uri but on yourself and expectedly respond 404 and returns it to ingress and it in turn 500 and redirect to login again
That is, there is an endless redirect. I take it that it's because the ingress is fidding with the header X-Forwarded-Host
But it's does not reproduce locally with nginx on localhost:XXXX (all cycle with same domain)
I've been trying to overcome for two weeks now and I'm discouraged
But google says it's just me and that guy https://github.com/ory/oathkeeper/discussions/1043 who has the problem, and every one else is fine? What does everyone else do in production? 🤔icy-manchester-83109
06/11/2023, 10:52 PM<http://nginx.ingress.kubernetes.io/auth-signin|nginx.ingress.kubernetes.io/auth-signin>: <http://kratos.public.domain/self-service/login/browser?return_to=$scheme://$host$escaped_request_uri>
cannot work. Since oathkeeper does not manage the Authorization Code Grant Flow, you cannot use it to manage it as well, if that was your intention.
Usage of proxy_set_header X-Original-URL $request_uri;
has no effect, as X-Original-URL
is not used according to my knowledgeicy-manchester-83109
06/11/2023, 11:00 PM<http://nginx.ingress.kubernetes.io/auth-snippet|nginx.ingress.kubernetes.io/auth-snippet>
is required, as oathkeeper can cope with the default nginx ingress config (see also https://github.com/kubernetes/ingress-nginx/blob/3c8817f700a4ab1713e3369fc6e5f500b008d989/rootfs/etc/nginx/template/nginx.tmpl#L966)
The only two annotations, which are required are:
<http://nginx.ingress.kubernetes.io/auth-url|nginx.ingress.kubernetes.io/auth-url>: <http://oathkeeper.internal.domain:4456/decisions$request_uri>
and <http://nginx.ingress.kubernetes.io/auth-response-headers|nginx.ingress.kubernetes.io/auth-response-headers>: Authorization
. Depending on your rules, you may want to use other header, or add more to <http://nginx.ingress.kubernetes.io/auth-response-headers|nginx.ingress.kubernetes.io/auth-response-headers>