[jazzyjackson]

I don't have personal experience but from a quick google it looks like default setup is to accept connections on localhost only [0], and there's a default user without capability to run SQL statements. They would have had to open remote connections and enable SQL capability for the default user (it looks like this is the first step to creating other users, the 3rd step is, removing SQL capability for default user.) [1]:

  1. Enable SQL-driven access control and account management for the default user.
  2. Log in to the default user account and create all the required users. Don’t forget to create an administrator account (GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION).
  3. Restrict permissions for the default user and disable SQL-driven access control and account management for it.

[0] https://chistadata.com/knowledge-base/allow-clickhouse-to-ac...

[1] https://clickhouse.com/docs/en/operations/access-rights

[btown]

From https://clickhouse.com/docs/en/operations/access-rights#acce...

> By default, the ClickHouse server provides the default user account which is not allowed using SQL-driven access control and account management but has all the rights and permissions. The default user account is used in any cases when the username is not defined, for example, at login from client or in distributed queries

This seems... very antiquated as a default? Clickhouse is relatively modern, first released in 2016, long after people were finding unauthenticated MongoDB servers left and right. Why not design it that starting a server requires at least a user-provided password in a config file? And then, even if that password was shared amongst all DeepSeek devs, at least it wouldn't be publicly accessible.

[pedrovhb]

I imagine it wouldn't necessarily require their opening of remote connections, just a misconfigured reverse proxy.

[slt2021]

when deployed to kubernetes you will have to open up to remote conns (thats how they were using it)