Proposal
Add a detector for ClickHouse credentials. ClickHouse hosts data and has a paid cloud tier, so it looks like a fit for the sourcing guidelines in hack/docs/Adding_Detectors_external.md.
There is no ClickHouse detector today, and I couldn't find a prior issue or PR proposing one. pkg/sources/elasticsearch shows the project already treats analytical stores as worth covering as scan targets; this is the credential side for ClickHouse.
What it would match
Two forms, both of which carry the host alongside the credential, so they can be verified the way the existing postgres, mongodb and redis detectors are:
- Native connection strings —
clickhouse://user:pass@host:9000/db, and clickhouses:// for TLS. This is the form the Go, Python and JDBC clients all accept.
- ClickHouse Cloud, which speaks HTTPS rather than the native protocol, so its credentials appear as ordinary basic-auth URLs. Pinning these to the
clickhouse.cloud domain keeps it high-signal — a bare https://user:pass@host URL is not a ClickHouse finding.
Verification
Over ClickHouse's HTTP interface with SELECT 1, authenticating with the X-ClickHouse-User and X-ClickHouse-Key headers. That keeps it to net/http with no database driver added, and works for both self-hosted and Cloud.
I checked the response codes against ClickHouse 26.8: 200 for a working credential, and 403 for both a wrong password and an unknown user. So those are determinate and anything else returns an error.
The one design question
Connection strings normally carry a native port (9000, or 9440 for TLS) while the HTTP interface listens on 8123/8443, so verification has to map between them. I've mapped the known native ports onto their HTTP equivalents and left anything else alone, since some deployments publish the HTTP interface on a different port. Where the HTTP interface isn't reachable the request simply fails, which surfaces as indeterminate rather than as a claim that the credential is invalid.
The alternative is speaking the native protocol, which would mean taking on a ClickHouse driver dependency. That seemed worse than a port mapping given the guidance to favour net/http, but happy to switch if you'd rather.
Happy to take feedback on any of the above. A PR is ready.
Proposal
Add a detector for ClickHouse credentials. ClickHouse hosts data and has a paid cloud tier, so it looks like a fit for the sourcing guidelines in
hack/docs/Adding_Detectors_external.md.There is no ClickHouse detector today, and I couldn't find a prior issue or PR proposing one.
pkg/sources/elasticsearchshows the project already treats analytical stores as worth covering as scan targets; this is the credential side for ClickHouse.What it would match
Two forms, both of which carry the host alongside the credential, so they can be verified the way the existing
postgres,mongodbandredisdetectors are:clickhouse://user:pass@host:9000/db, andclickhouses://for TLS. This is the form the Go, Python and JDBC clients all accept.clickhouse.clouddomain keeps it high-signal — a barehttps://user:pass@hostURL is not a ClickHouse finding.Verification
Over ClickHouse's HTTP interface with
SELECT 1, authenticating with theX-ClickHouse-UserandX-ClickHouse-Keyheaders. That keeps it tonet/httpwith no database driver added, and works for both self-hosted and Cloud.I checked the response codes against ClickHouse 26.8:
200for a working credential, and403for both a wrong password and an unknown user. So those are determinate and anything else returns an error.The one design question
Connection strings normally carry a native port (9000, or 9440 for TLS) while the HTTP interface listens on 8123/8443, so verification has to map between them. I've mapped the known native ports onto their HTTP equivalents and left anything else alone, since some deployments publish the HTTP interface on a different port. Where the HTTP interface isn't reachable the request simply fails, which surfaces as indeterminate rather than as a claim that the credential is invalid.
The alternative is speaking the native protocol, which would mean taking on a ClickHouse driver dependency. That seemed worse than a port mapping given the guidance to favour
net/http, but happy to switch if you'd rather.Happy to take feedback on any of the above. A PR is ready.