new http-ping-only flag for 'timestamp-server serve'

[dmitris]

Summary

The change adds a new command-line flag for the timestamp-server serve command to address the following need:

• must serve timestamp requests only via the https server with mTLS
• need to provide the ability to do ping-like checks over http server (for the load balancers that don't have access to the mTLS credentials)

The solution is to add the --http-ping-only boolean flag (default false) that when given, restricts the http server to serve only the (existing) /ping entrypoint - for others, the http server responds with '400 Forbidden' and a short message.

Since I could find no other alternative (despite asking in different forums/channels) in the swagger generation framework, I resorted to created a boolean global variable IsHTTPPingOnly in the new pkg/internal/cmdparams subpackage to pass the flag values to the server implementation in pkg/generated/restapi/configure_timestamp_server.go. If you can suggest a more elegant way to achieve the same goal, please let me know.

Related to #420.

Release Note

• New features and improvements, including behavioural changes, UI changes and CLI changes
  added the optional --http-ping-only boolean flag to restrict the http server to the /ping entrypoint.

Documentation

option is documented in the output of timestamp-server serve --help:

$ timestamp-server serve --help
Starts a http server and serves the configured api

Usage:
  timestamp-server serve [flags]
[...]
      --http-ping-only                  serve only /ping in the http server

[codecov]

Codecov Report

Merging #474 (42b38a4) into main (fa83a9b) will not change coverage.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #474   +/-   ##
=======================================
  Coverage   53.38%   53.38%           
=======================================
  Files          20       20           
  Lines        1195     1195           
=======================================
  Hits          638      638           
  Misses        496      496           
  Partials       61       61           

Files	Coverage Δ
pkg/ntpmonitor/config.go	37.50% <ø> (ø)
pkg/tests/server.go	76.92% <100.00%> (ø)

[bobcallaway]

shouldn't you return a 404 for any other path other than /ping? I'd argue that would be more expected behavior from an endpoint.

[dmitris]

shouldn't you return a 404 for any other path other than /ping? I'd argue that would be more expected behavior from an endpoint.

Probably both would work. My thinking: 404 would be good for URL where you for example had a typo. Here are resources actually "exist" - you haven't made a mistake specifying them - but with the given configuration, they are "off-limit" - not allowed to be accessed through the HTTP server. The ltext message further reinforces this point and explains the reason for the failure. I have changed the return code from 400 "Bad Request" to 403 "Unauthorized" now.

https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.4 says:

The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).

The RFC9110 does say in the next paragraph:

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

but I think in the case of timestamp-server it would be preferably (for the system operators) not to hide the disallowed entrypoints but instead highlight in the response why they are not accessible.

[bobcallaway]

shouldn't you return a 404 for any other path other than /ping? I'd argue that would be more expected behavior from an endpoint.

Probably both would work. My thinking: 404 would be good for URL where you for example had a typo. Here are resources actually "exist" - you haven't made a mistake specifying them - but with the given configuration, they are "off-limit" - not allowed to be accessed through the HTTP server. The ltext message further reinforces this point and explains the reason for the failure. I have changed the return code from 400 "Bad Request" to 403 "Unauthorized" now.

https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.4 says:

The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).

The RFC9110 does say in the next paragraph:

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

but I think in the case of timestamp-server it would be preferably (for the system operators) not to hide the disallowed entrypoints but instead highlight in the response why they are not accessible.

404 should be used for any path other than /ping. 403 conveys to me that the resource does exist, but the user agent has not presented sufficient credentials to be considered authorized to access the resource. That isn't the case here (we're not authenticating users of the health check).

[dmitris]

404 should be used for any path other than /ping.

OK, changed to return 404.

[bobcallaway]

lgtm, minus two nits

[loosebazooka]

minor stuff