highmed / highmed-dsf

HiGHmed Data Sharing Framework funded by the German Federal Ministry of Education and Research (BMBF, grant ids: 01ZZ1802E and 01ZZ1802A)
Apache License 2.0
32 stars 20 forks source link

Endpoint /status can not be probed without client certificate #362

Open bauerjs1 opened 2 years ago

bauerjs1 commented 2 years ago

Hello again,

I'd like to make our Prometheus monitoring watch the availability of the DSF. Since 0.6.0 or 0.7.0 I noticed, there is a new /status endpoint, for which – as the DSF logs claim – no specific authentication is required. Unfortunately, if i curl the endpoint without a client cert, I still get a certificate error:

curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

Could it be that the DSF would not require authentication, but the fhir_proxy Apache reverse proxy is not yet configured for that and so rejects the request before it even reaches the DSF?

Cheers, Johannes

hhund commented 2 years ago

Hi Johannes,

the /status URL is only provided on an http connector listening on 127.0.0.1:10001 for the DSF FHIR server or127.0.0.1:10002 for the DSF BPE server. Which of course means, that it is only accessible from within the docker container. And since it is hard-coded you would need to fork the DSF in order to change this. I was debating to either make this accessible from outside the container by default or make it configurable, but I deemed the risk to high, that due to coding errors other resource may get accessible without authentication as well.

Since the docker daemon should know (via health-check) if the DSF containers are healthy you may want to monitor the docker daemon via Prometheus.

bauerjs1 commented 2 years ago

I see the point that it might still be visible through the dockerd metrics. However, it would be much more efficient to be able to monitor the application the same way as we do with our other 100+ domains, plus, http probes are the common way to achieve this. They also provide additional info, such as certificate expiry etc.

Are there any chances this might be made accessible in a future release? Would it be a reasonable compromise to remove the 127.0.0.1 restriction from the http connector, but without exposing the port outside the container by default?

As a side note, the endpoint accessibility could still be restricted by the fhir_proxy.

hhund commented 2 years ago

I do not want to add any endpoint that circumvents our authentication/authorization layer and is accessible from outside the docker container.

But I think we should add the status URL to the regular HTTP port (80) after we have added authentication for local users using OAuth2/OpenID Connect. The status URL could than be accessible to users with a specific "status monitoring" role.

I will reopen this issue and reclassify it as low priority (for now) enhancement.