ClickHouse
ClickHousedatabase5 credentials1 default credential
Default User with Blank Password
clickhouse / default-user-blank-password
ClickHouse packages include a default user. Many default/example configurations allow the default user with no password, especially for local or development deployments, until operators configure users.xml/users.d secrets.
Default credentials
defaultLocation
ClickHouse native TCP, HTTP interface, clickhouse-client, JDBC/ODBC, and web integrationsusers.xml, config.xmlClickHouse user configuration; user include directories are instance-specific and kept in notes
Kubernetes Secrets, ClickHouse Keeper/ZooKeeper stores, and password vaults
query_log, text_log, server logs, and authentication failures
CLICKHOUSE_USER, CLICKHOUSE_PASSWORDOfficial container bootstrap user/password variables for ClickHouse deployments
Notes
Treat this as a default/no-password configuration risk: the default user name exists and the password is absent, so `default.password` is null rather than an empty-string credential. Hardened production deployments should set a password or external authentication.
ClickHouse User Password / Hash
clickhouse / user-password-hash
ClickHouse users can be configured with plaintext passwords, SHA256/double-SHA1 hashes, LDAP/Kerberos, or SQL-managed access control.
Looks like
pattern<password(_sha256_hex|_double_sha1_hex)?>[^<]*</password(_sha256_hex|_double_sha1_hex)?>IDENTIFIED\s+WITH\s+\w+\s+BYLocation
users.xml, config.xmlClickHouse local users, LDAP/Kerberos auth, interserver credentials, and profiles
SQL access-control storage and system tables for users/roles where enabled
native TCP, HTTP API, SQL clients, and cluster interserver endpointsKubernetes Secrets, cloud secret managers, and password vaults
deployment manifests, application configs, and test fixtures
CLICKHOUSE_USER, CLICKHOUSE_PASSWORDOfficial container bootstrap user/password variables when setting non-default credentials
Interserver / Replication / Keeper Secret
clickhouse / interserver-replication-secret
ClickHouse clusters use interserver HTTP credentials, distributed DDL/Keeper/ZooKeeper credentials, macros, TLS keys, and replication secrets for node-to-node operations.
Location
config.xml, keeper_config.xmlClickHouse interserver HTTP credentials, remote_servers secrets, Keeper/ZooKeeper auth, and cluster config
Kubernetes Secrets, Keeper/ZooKeeper ACL stores, and deployment vaults
replication, distributed DDL, Keeper, and interserver logs
TLS Private Key
clickhouse / tls-private-key
ClickHouse can use TLS certificates/private keys for native, HTTPS, interserver, and Keeper communication.
Looks like
pattern-----BEGIN (RSA |EC |OPENSSH |ENCRYPTED )?PRIVATE KEY-----Location
config.xmlopenSSL server/client key files and TLS settings. Additional non-path context from previous path: certs/.
Kubernetes Secrets, certificate stores, and vaults
cluster backups and diagnostics bundles
ClickHouse Cloud API Key / Secret Key
clickhouse / cloud-api-key
ClickHouse Cloud API access uses a key id and secret key pair for cloud API operations. Public scanner rules identify a ClickHouse Cloud secret-key value prefix.
Looks like
example4b1dXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXLocation
AuthorizationBasic authentication using key id and secret key for ClickHouse Cloud API
CI/CD variables, cloud secret managers, and automation vaults
Terraform/API automation and deployment scripts
HTTP traces and cloud API client debug output
Notes
Keep key-id context with the secret for validation; key id alone is not the secret.
Scope
Authorized use
LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.