Consul Health Check: security-spiffe-token-provider 400 Bad Request

[bnevis-i]

🐞 Bug Report

Affected Services [REQUIRED]

security-spiffe-token-provider

Is this a regression?

No

Description and Minimal Reproduction [REQUIRED]

Health check for security-spiffe-token-provider is failing because in order to do SPIFFE authentication, the web service must use HTTPS. Should find an alternative way to implement the health check so that it doesn't erroneously fail, or omit it altogether. It will likely not be possible to make Consul into a SPIFFE client.

🔥 Exception or Error

HTTP GET http://edgex-security-spiffe-token-provider:59841/api/v3/ping: 400 Bad Request Output: Client sent an HTTP request to an HTTPS server.

🌍 Your Environment

Deployment Environment: Docker

EdgeX Version [REQUIRED]: minnesota dev (likely present in earlier releases as well)

Anything else relevant?

[lenny-goodell]

We previously removed Protocol from the Service configuration.

We could put it back and default to HTTP (if not set) by bootstrap when registering with Consul if not set. This service could set it to HTTPS and used by bootstrap when it registers the service with Consul.

[bnevis-i]

We previously removed Protocol from the Service configuration.

We could put it back and default to HTTP (if not set) by bootstrap when registering with Consul if not set. This service could set it to HTTPS and used by bootstrap when it registers the service with Consul.

It still won't be able to work even if HTTPS was available because it won't pass the authentication check. A TCP port check is probably the best we can do, as HTTPS requires a spiffe client certificate.

[lenny-goodell]

It still won't be able to work even if HTTPS was available because it won't pass the authentication check.

I thought that you disabled authentication check for the ping endpoints.

[bnevis-i]

It still won't be able to work even if HTTPS was available because it won't pass the authentication check.

I thought that you disabled authentication check for the ping endpoints.

I did, but it is blocked at the TLS level :-(

One possible workaround is to run two HTTP servers -- one to serve the healthcheck, the other that is the actual TLS service.