Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

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

Open
bauerjs1 opened this issue Jun 28, 2022 · 3 comments
Open

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

bauerjs1 opened this issue Jun 28, 2022 · 3 comments
Labels
enhancement New feature or request priority low This issue has low priority

Comments

@bauerjs1
Copy link

bauerjs1 commented Jun 28, 2022

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 hhund added the question Further information is requested label Jun 29, 2022
@hhund
Copy link
Member

hhund commented Jun 29, 2022

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.

@hhund hhund closed this as completed Jun 29, 2022
@bauerjs1
Copy link
Author

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
Copy link
Member

hhund commented Jun 30, 2022

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.

@hhund hhund reopened this Jun 30, 2022
@hhund hhund added enhancement New feature or request priority low This issue has low priority and removed question Further information is requested labels Jun 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request priority low This issue has low priority
Projects
None yet
Development

No branches or pull requests

2 participants