<remote_servers> Add user and password authentication

[czhfe]

<remote_servers> Add user and password authentication

[alex-zaitsev]

You can do it now using custom configuration files. See this example: https://github.com/Altinity/clickhouse-operator/blob/master/tests/configs/test-016-settings-01.yaml

It is not very convenient though.

The general assumption is that default user is protected by hostRegexp expression that does not allow connections outside of the cluster. That make use of custom user/password for intra-cluster communication unneeded.

[czhfe]

You can do it now using custom configuration files. See this example: https://github.com/Altinity/clickhouse-operator/blob/master/tests/configs/test-016-settings-01.yaml

It is not very convenient though.

The general assumption is that default user is protected by hostRegexp expression that does not allow connections outside of the cluster. That make use of custom user/password for intra-cluster communication unneeded.

How should I change the user and password of <remote_servers>, the hostRegexp expression I also found does not allow connections outside the cluster, but that setting causes occasional host mismatch issues. I don't know if it's the DNS cache, but I set disable_internal_dns_cache to 1 and the problem is not alleviated. The problem described by https://github.com/Altinity/clickhouse-operator/issues/786 occurs

[yuzhichang]

https://github.com/Altinity/clickhouse-operator/issues/265#issuecomment-948361288 Using secret tag is better than changing the user and password of remote_servers.

[czhfe]

#265 (comment) Using secret tag is better than changing the user and password of remote_servers.

What should I do when deploying clickhouse using clickhouse-operator?

[alex-zaitsev]

#265 (comment) Using secret tag is better than changing the user and password of remote_servers.

What should I do when deploying clickhouse using clickhouse-operator?

    settings:
      remote_servers/default/secret: abcd

'default' is a cluster name in this example. We can probably generate secret randomly when CHI is created, not sure if it makes sense. @yuzhichang , what do you think?

You can also use from_env in order to store the password in environment vars. See https://github.com/Altinity/clickhouse-operator/issues/700

[yuzhichang]

@alex-zaitsev The secret value doesn't matter. The value just shall not be empty string, and shall be the same among all nodes (since Connection::ping() sends the secret value, and the other side TCPHandler::receiveQuery() validates if it match with the local config). ckman enforces non-empty password of user default, and use secret (if cluster >=v20.10.3.30+) or user and password (if cluster <v20.10.3.30).

[R-omk]

We can probably generate secret randomly when CHI is created

This would be great, but only generate a new secret if no existing one is explicitly specified.

[alex-zaitsev]

Fully implemented in https://github.com/Altinity/clickhouse-operator/releases/tag/release-0.20.0