microcks: Microcks Ui doesnt show APIs & Services
Hello,
It seems I have a problem with my k8s v1.20.11 installation of microcks. I´ve deployed microcks on two company clusters and local minikube instance. I have tested it with different versions locally and in the cluster. The minikube instance works fine but the cluster installations have a strange behaviour.
I can create APIs: But only get a blank page when try to list them.
The pods do not return any error messages except this warning:
Podlog
08:51:54.822 [DEBUG] io.github.microcks.web.InvocationController - Getting invocations stats for last 20 days
08:51:54.822 [DEBUG] io.github.microcks.web.InvocationController - Getting top 20 invocations stats for day 20211215
08:51:54.822 [WARN] org.keycloak.adapters.RequestAuthenticator - SSL is required to authenticate. Remote address 100.x.x.34 is secure: false, SSL required for: EXTERNAL .
The network analysis of Chrome and Firefox shows the following errors:
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 25 (14 by maintainers)
Commits related to this issue
- fix #528: setting default for forward-headers-strategy to native — committed to microcks/microcks by lbroudoux 2 years ago
- microcks/microcks#528 Documenting proxy handling options — committed to microcks/microcks.io by lbroudoux 2 years ago
Hi @lbroudoux, the settings that we typically use inside of our internal clusters don’t use
.*
for internal-proxies, but a regex that matches the cluster’s configured pod IP subnet. The.*
configuration is definitely not safe as a default if the tomcat server handles any traffic that comes from the internet.This configuration is necessary for us because due to the size and number of our clusters, we can’t use only the 3 typical private IPv4 address spaces, so we have to use a reserved IPv4 space such as
172.16.0.0/12
. Since those IPs aren’t part of the default configuration for the internal-proxies valve, we have to provide our own regex that matches it.For example, incoming HTTPS traffic gets handled by an appliance that terminates TLS and then routes it to the cluster as HTTP with proxy headers such as
X-Forwarded-Proto: https
. In the cluster an ingress pod with an IP of say 172.16.0.1 routes it to an application pod. With the default configuration, tomcat in that application container will ignore theX-Forwarded..
headers because the internal-proxies regex only matches the 3 private IPv4 (and v6) blocks. However, since we configure the remoteip valve with a regex that will match 172.16.0.1, then it will treat that as an internal proxy and properly forward the proxy headers to the application code.I think that
native
is a safe default for this microcks image since it uses spring and an embedded tomcat server. Setting it toframework
would have no benefit in this case, but it could be required if you for instance distributed microcks as a jar/war for people to deploy in some other servlet container. Theframework
option will just make Spring autoconfigure a filter to handle forwarding the proxy headers.Thank you @aroak and all for the explanations 🙌
I understand that the
internal-proxies
setting is very specific to network config and should be handled as suggested by @carolgschwend allowing usage ofextra
config file and adding anextra
profile to the list of loaded ones.Though it looks to me that the
server.forward-headers-strategy=native
is safe to add to default. Other strategies arenone
that does nothing andframework
that needs to integrate custom code in Microcks which cannot be done. What do you think am I understanding things correctly?Hi @lbroudoux, I have the same empty page when I import an API specification (OCP 4.8.27, Microcks Operator 1.5.0)
Here is the log in the my-microcks Pod application :
16:01:48.879 [WARN] org.keycloak.adapters.RequestAuthenticator - SSL is required to authenticate. Remote address xxx.xx.xx.x is secure: false, SSL required for: EXTERNAL .