You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the ClickHouse data source plugin couples the Authentication method to the Transport Protocol (HTTP vs HTTPS) in a way that prevents the use of authentication proxies or gateways in secure environments.
When configuring the data source:
Case 1 (HTTP / Insecure): When the protocol is HTTP, the plugin sends credentials using the standard Authorization: Basic header.
Case 2 (HTTPS / Secure): When the protocol is HTTPS, the plugin automatically switches behavior and sends credentials via ClickHouse-specific headers (X-ClickHouse-User and X-ClickHouse-Key), omitting the standard Authorization header.
The problem
When running a ClickHouse cluster behind a secure reverse proxy/gateway (acting as an authentication middleware for multi-tenancy). This gateway expects a standard Authorization header to authenticate the request before forwarding it to ClickHouse.
Because the plugin forces X-ClickHouse-User headers when HTTPS is enabled, the gateway rejects the request with a 401 Unauthorized ("authentication error: no credentials provided") because it cannot find the standard Authorization header it expects.
Reproduction:
Set up a ClickHouse instance behind an Nginx/Gateway proxy that enforces Basic Auth.
Configure the Grafana ClickHouse Datasource to connect to this proxy via HTTPS.
Connection fails.
Logs show the plugin sending X-ClickHouse- headers, while the proxy awaits Authorization.
Proposal
We propose adding a configuration option (e.g., a checkbox labeled "Use Basic Auth" or "Force Standard Authorization Header") in the Data Source settings.
When enabled, this option should force the plugin to send the Authorization header even when Secure (HTTPS) mode is active, overriding the default behavior of sending X-ClickHouse-User/Key.
Alternatives considered
Downgrading to HTTP: The connection works as expected over plain HTTP (since the plugin uses the Authorization header), but this is not a viable solution for production environments requiring TLS.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
Currently, the ClickHouse data source plugin couples the Authentication method to the Transport Protocol (HTTP vs HTTPS) in a way that prevents the use of authentication proxies or gateways in secure environments.
When configuring the data source:
The problem
When running a ClickHouse cluster behind a secure reverse proxy/gateway (acting as an authentication middleware for multi-tenancy). This gateway expects a standard Authorization header to authenticate the request before forwarding it to ClickHouse.
Because the plugin forces X-ClickHouse-User headers when HTTPS is enabled, the gateway rejects the request with a 401 Unauthorized ("authentication error: no credentials provided") because it cannot find the standard Authorization header it expects.
Reproduction:
Set up a ClickHouse instance behind an Nginx/Gateway proxy that enforces Basic Auth.
Configure the Grafana ClickHouse Datasource to connect to this proxy via HTTPS.
Connection fails.
Logs show the plugin sending X-ClickHouse- headers, while the proxy awaits Authorization.
Proposal
We propose adding a configuration option (e.g., a checkbox labeled "Use Basic Auth" or "Force Standard Authorization Header") in the Data Source settings.
When enabled, this option should force the plugin to send the Authorization header even when Secure (HTTPS) mode is active, overriding the default behavior of sending X-ClickHouse-User/Key.
Alternatives considered
Downgrading to HTTP: The connection works as expected over plain HTTP (since the plugin uses the Authorization header), but this is not a viable solution for production environments requiring TLS.
Beta Was this translation helpful? Give feedback.
All reactions