AFAIK, Opensource Elasticsearch does not offer any form of authentication upon installation for many years but ClickHouse does and in fact I'm often surprised at how many authentication mechanisms were introduced over the years and can be easily configured:

- Password authentication (bcrypt, sha256 hashes) - Certificate authentication (Fantastic for server to server communication) - SSH key authentication (Personally, this is my favourite - every database should have this authentication mechanism to make it easy for Dev to work with)

Not very popular but LDAP and Http Authentication Server are also great options.

I also wonder how DeepSeek engineers deployed their ClickHouse instance. When I deployed using yum/apt install, the installation step literally ask you to input a default password.

And if you were to set it up manually with ClickHouse binary, the out-of-the-box config seal the instance from external network access and the default user is only exposed to localhost as explained by Alex here - https://news.ycombinator.com/item?id=42871371#42873446.

shame they paywalled JWT authn behind their expensive PaaS offering :(

forced us to use an alternative, and paywalling security features in an "open source" product didn't make us feel comfortable for a long-term investment like a db

https://github.com/ClickHouse/ClickHouse/pull/68634#issuecom...

Which was originally the open exposed mongo server, then mysql/phpmyadmin, then exposed ftp, and then exposed telnet.

We move on and upwards, but never really stop making the same mistakes do we.

Shows how old I am. Thought we were still in the "exposed ElasticSearch" era.

I was sure this was Elastic, you are not alone.

open exposed S3 bucket is this decade's open exposed S3 bucket so common in the past