Skippr Docs

Appearance

How to Manage ClickHouse Source Credentials in Skippr ​

July 2026

Keep ClickHouse source credentials safe by leaving non-secret connector fields in config, interpolating the password from CLICKHOUSE_PASSWORD, and granting only the read access the source needs.

Short Answer ​

Manage ClickHouse source credentials in Skippr by treating the endpoint details as normal config and the password as a secret. The connector docs show url, database, and user in skippr.yaml, but the password should be referenced as ${CLICKHOUSE_PASSWORD} so the secret stays outside the file.

That matches the documented auth model for the ClickHouse HTTP API. A production setup usually keeps a dedicated read user for the selected database and exports the password in the shell before skippr run, while a local setup can stay simple if the default user is intentional and not exposed beyond development.

Why Teams Struggle with This ​

Teams usually make ClickHouse credential handling harder than it is because they hide every field as if it were sensitive, then still leave the actual password in the repo. The useful boundary is simpler: the URL and database describe where Skippr should read, and only the password needs secret storage.

  • Putting a literal password in skippr.yaml creates the exact leak the docs warn against.
  • Using one broad admin account for extraction makes routine table reads depend on a credential that can also change schema or users.
  • Confusing tables and query changes the read contract and often leads to grants that are wider than necessary.
  • If the runner cannot reach the ClickHouse HTTP endpoint, rotating the password will not fix the real problem.

How Skippr Handles It ​

Skippr keeps the ClickHouse source surface narrow. You configure the HTTP URL, database, user, and either tables or query, then let the password come from an environment variable reference. That is specific enough for operations and still keeps the secret out of source control.

This also makes review easier. Another engineer can see which ClickHouse database and namespace are being ingested without ever seeing the credential that unlocks them.

  • Uses password: ${CLICKHOUSE_PASSWORD} for the secret-bearing field.
  • Leaves url, database, user, and table selection visible and reviewable in config.
  • Fits a least-privilege read user with access only to the selected database and tables.
  • Matches the documented ClickHouse HTTP authentication flow instead of inventing a second secret format.

What the First Useful Version Looks Like ​

The first useful version is one ClickHouse HTTP endpoint, one read-only user, one database, and one table such as events or one approved query. That is enough to prove the connector and the credential boundary at the same time.

If you already know the query should override table selection, document that choice early so the credential can stay scoped to the exact objects Skippr will read.