[Feature Request] Support multiple authentication methods for infrastructure monitors

[eralpozcan]

Is your feature request related to a problem? Please describe.

Infrastructure monitors currently provide a single Authorization secret field. When configured, Checkmate always sends this value as a Bearer token:

Authorization: Bearer <secret>

This limits infrastructure monitoring to endpoints that accept Bearer authentication. Capture-compatible endpoints may be deployed behind reverse proxies, gateways, or other security layers that use authentication methods such as HTTP Basic Authentication or API keys.

Users currently need to change their existing security configuration or introduce an additional proxy that translates authentication headers.

Describe the solution you'd like

Add an Authentication method selector to the Create/Edit Infrastructure Monitor form with the following options:

• Bearer Token — the current behavior and default option
• Basic Auth — displays username and password fields
• API Key — displays configurable header name and value fields

Checkmate should construct the outgoing request according to the selected method:

• Bearer Token: Authorization: Bearer <token>
• Basic Auth: Authorization: Basic <base64(username:password)>
• API Key: <configured-header-name>: <configured-value>

Existing infrastructure monitors that already contain an authorization secret should continue to use Bearer authentication without requiring migration or manual reconfiguration.

Authentication credentials should be treated as sensitive values and must not be exposed in logs or error messages.

Describe alternatives you've considered

Configuring a separate reverse proxy to translate authentication headers is possible, but it adds deployment complexity and requires users to maintain additional infrastructure.

Embedding credentials in the endpoint URL was also considered, but explicit authentication fields are clearer and avoid placing credentials directly in URLs.

Additional context

Checkmate already constructs Bearer and Basic Authentication headers for the ntfy notification provider. If this request is accepted, the existing header construction logic could be moved into a small shared HTTP authentication helper and reused by both the ntfy and infrastructure request paths, avoiding duplicate implementations.

The existing Bearer authentication behavior should remain the default for backward compatibility.

If this feature request is accepted, I would be happy to work on the implementation.

I would appreciate @gorkem-bwl's input on the product direction and @ajhollid's feedback on how this would best fit the existing implementation.

[kunalGonge]

Hi @eralpozcan , I’m interested in contributing to this feature.
I understand the request is to add selectable authentication methods for infrastructure monitors Bearer Token as the backward-compatible default, Basic Auth, and configurable API key headers while keeping credentials out of logs and errors. Before I begin, could the maintainers please confirm whether this feature is approved and suitable for contribution? If so, I’d be happy to review the existing ntfy authentication logic and the infrastructure-monitor request flow, then propose a focused implementation plan.Thank you!

[gorkem-bwl]

@eralpozcan is there a reason and a use-case for this to add? What is your current setup?

[eralpozcan]

Hi @gorkem-bwl,

Yes, I have a concrete use case for this in my self-hosted infrastructure.

I already collect host and container metrics through node_exporter, cAdvisor, Prometheus, and a metrics gateway. Grafana uses the data stored in Prometheus, and these services are protected using HTTP Basic Authentication as part of my existing security setup.

Instead of deploying Capture as an additional agent that collects largely overlapping data, I plan to expose a /api/v1/metrics route from my existing metrics service. This route will transform the metrics already being collected into the Capture-compatible JSON response expected by Checkmate. I understand that Checkmate cannot consume Prometheus exposition data directly; the integration endpoint will satisfy the Capture response contract.

The current limitation is that Checkmate always sends the infrastructure secret as Authorization: Bearer <token>. Supporting selectable authentication would keep the Capture-compatible payload contract separate from the authentication mechanism used to access it. In my case, Basic Authentication would let me reuse the existing metrics pipeline without running another collector, duplicating metrics collection, or introducing a separate Bearer authentication layer. Other self-hosted environments may use Bearer tokens or API-key headers instead.

My immediate requirement is Basic Authentication. The existing Bearer behavior should remain the default so current Capture installations continue to work without any migration or configuration changes.

As a complementary option, allowing infrastructure monitors to use Checkmate's existing Proxies feature would help reach private Capture-compatible endpoints without exposing them publicly. Authentication selection would determine how Checkmate authenticates to the endpoint, while proxy selection would determine how Checkmate reaches it.

[ajhollid]

Hey @eralpozcan,

Before we set the design down here, do you want the option to consume Prometheus data directly rather than transforming it to satisfy Capture's api contract?

Clearly it is much simpler for us to simply add different authorization to options to the existing infrastructure monitors, but I want to make sure we're not jamming a square peg into a round hole.

[eralpozcan]

Hey @ajhollid,

That is a fair concern. I initially approached this from the perspective of keeping the Checkmate-side change small by adapting my existing metrics gateway to the Capture API contract.

My reason for preferring the authentication extension was mainly scope and regression risk. The existing infrastructure-monitoring flow is built around Capture, while native Prometheus support appears likely to affect several areas, including provider logic, metric and label mapping, configuration, validation, UI, and tests. I did not want to suggest a broad change to an established integration when a small, backward-compatible authentication extension could support my setup.

However, consuming Prometheus data directly would actually fit my use case better. Prometheus already contains the host and container metrics collected by node_exporter and cAdvisor, so native Prometheus support would remove the need to maintain an additional transformation endpoint or deploy Capture alongside the existing stack.

In that design, authentication would become part of the Prometheus data-source configuration rather than an extension of the existing Capture monitor. My Prometheus endpoint uses Basic Authentication, while other deployments may use Bearer tokens or API-key headers.

I assume direct support would require Checkmate to define how its CPU, memory, disk, and network fields map to Prometheus queries and labels, so it is a larger scope than adding authentication options to the current infrastructure monitor. Still, it seems like the cleaner abstraction and avoids the square-peg problem you mentioned.