Provide overview of status of configured services

[sergei-maertens]

It would be good to be able to configure a health check endpoint for each service, and have a custom admin view that reports the health status of each service.

This can give a quick insight into if a service is down or up.

[alextreme]

Further thoughts after having done a few mTLS-connections this week for OIP.

This would be very useful for doing the initial configuration too.

Currently configuration requires (1) Config change in the admin (2) Trying the app to use the service (3) Checking the logs for SSL errors.

Having an adminview for sending a request on the root URL of the Service and outputting any exceptions/errors should make mTLS a lot easier to handle (especially if you don't know which parts of the app trigger which call, you effectively need to know the app to configure it efficiently).

Another way to make configuration easier would be when performing the above is upon an error also trying the call with verify=False. This would indicate if one-way TLS (server accepts our request with client-certificate) does work.

A third way to make configuration easier would be to (combined with the above) to have a button to automatically request and store/update the server's certificate (full chain, considering private G1 certificates) on the Service. I don't mind a bit of openssl mangling but it's not something I'd consider trivial and I'd loath to do this on a k8s setup in a container without my usual toolkit preinstalled. This would also make server certificate-switching a lot easier.

And considering maykinmedia/django-simple-certmanager#2 I think putting in a bit of effort to automate Service configuration via envvars would make initial installs (regular ones, Ansible and also our demo-k8s project) a lot simpler to complete compared to fixtures.

Lets discuss this and if you agree I'll arrange some devtime.

[sergei-maertens]

For the client TLS auth, see my comment in django-simple-certmanager. The short story is: it cannot be done in a reliable way, because the mTLS checks themselves are often performed by the application (on the server side), not on the TCP or even HTTP level. They can be done at both of those levels, but that's the exception rather than the rule.

I don't see any benefit in trying the call with verify=False - in any failure situation you will need to check (request) logs/error monitoring to figure out what exactly fails to be able to fix it. Since this ticket was created and the comment above added, most of our applications now ship with django-log-outgoing-requests which can assist in this.

[alextreme]

I don't see any benefit in trying the call with verify=False - in any failure situation you will need to check (request) logs/error monitoring to figure out what exactly fails to be able to fix it. Since this ticket was created and the comment above added, most of our applications now ship with django-log-outgoing-requests which can assist in this.

I (still) do. There can be multiple reasons why a TLS connection can't be set up, it can depend on the server, on the client, firewalls or on a gateway that sits in between. Knowing that a connection does work with verify=False means that the admin (or we) can solve the issue, if it doesn't then it depends on the client certificate or how the server checks the client certificate. More information helps in pinpointing the root cause when configuring a connection, which can be quite tricky with on-prem installs.

But I agree that with the introduction last year of django-lor configuring connections has become more manageable than back in 2022 when this wasn't an option yet. This issue and similar ones like it were the reason why I wanted lor :)

Regarding mTLS lets grab a whiteboard with Sjoerd and Laurens in due time. With Rotterdam, DH and VIPS we have a few different mTLS setups available, but if we're at our limits on what's possible without resorting to curl/netcat then we'll leave it as-is. There is a point of diminishing returns and we may have reached it