Repository navigation
Review http/https and proxy settings in operator - #12021
Conversation
Co-authored-by: Dominik Guhr <dguhr@redhat.com>
| Log.info("Curl Output: " + curlOutput); | ||
|
|
||
| assertTrue(curlOutput.contains("var authServerUrl = 'https://example.com:8443';")); | ||
| assertTrue(curlOutput.contains("var authServerUrl = 'https://example.com';")); |
There was a problem hiding this comment.
Those changes are pretty much counter-intuitive since we are explicitly accessing Keycloak using the specific port:
This is caused by the fact that we are now setting proxy: edge and it means that we have to choose one of (but not the two):
- make it work through the
Ingress - make it work through straight port-forward
Here we are biased toward access through the Ingress but this has drawbacks, especially for local and developer setups.
cc. @pedroigor @DGuhr
There was a problem hiding this comment.
Could you elaborate what are the drawbacks? Don't you always access the instances through the ingress?
For me it reads just fine because now you have a ingress exposing the server using default HTTPS/HTTP ports.
There was a problem hiding this comment.
Don't you always access the instances through the ingress?
Not really, when deployed to K8s using the operator, at the moment, Keycloak can be accessed in multiple ways:
- through the
Ingress, basically using a proxy, used in production for user access mainly - through the
Service, any k8s "internal" system will access Kc this way, direct access - using a
port-forward, mostly for development/debugging purposes, re-binding remote ports to the machine's local
The expectation is that Keycloak is accessible and behaves the same through the 3 accesses unless something specific to prevent this behavior has been set.
The reality is that the access to the Admin console seems to be always not working in one of the 3 scenarios.
There was a problem hiding this comment.
I agree with this @DGuhr suggestion BTW:
But perhaps we should open up a follow-up discussion/issue.
| Log.info("Curl Output: " + curlOutput); | ||
|
|
||
| assertTrue(curlOutput.contains("var authServerUrl = 'https://foo.bar:8443';")); | ||
| assertTrue(curlOutput.contains("var authServerUrl = 'https://foo.bar';")); |
There was a problem hiding this comment.
Same comment as above ☝️
There was a problem hiding this comment.
Works as intended, although i second you on the UX issue part w.r.t. proxy/http handling
http-enabled=true
http-port=8081
proxy=edge
From setting a configuration simple as this, I would expect:
- Keycloak to be available to be accessed using http
- on http port 8081
- and able to run behind a proxy.
Atm this leads to:
- Keycloak not available to be accessed using http until setting the strict-https option.
- Keycloak not available on port 8081, but on 80/443 due to "edge"/proxy setting implicitly expecting these ports to be used.
But perhaps we should open up a follow-up discussion/issue.
| Log.info("Curl Output: " + curlOutput); | ||
|
|
||
| assertTrue(curlOutput.contains("var authServerUrl = 'https://example.com:8443';")); | ||
| assertTrue(curlOutput.contains("var authServerUrl = 'https://example.com';")); |
There was a problem hiding this comment.
Just a note. This will probably break and will need to be adjusted as soon as we switch to the new Admin Console by default. But it's ok of course, for now.
|
Is there any ETA on 18.0.1 with these fixes yet? |
Co-authored-by: Dominik Guhr dguhr@redhat.com
Resolves #11581 and #12020