Authenticate node communications

[chancez]

Please check items PR complies to:

• [x] All commits in the PR are squashed. More info
• [x] The PR is made into dedicated next-release branch, not into master branch¹. More info
• [x] The PR is signed. More info

This is based on #938 , because I wanted to put it up for review, but didn't feel like it was necessary for it to be part of the existing PR. Let me know if you think they should be combined.

[alex-zaitsev]

Hi @chancez , we are making some changes for inter-cluster communication in scope of 0.19 release now. This PR should go after we are done with those changes.

Also, I think it makes sense to move user/password for inter-cluster communication at cluster level. It is not a part of hostTemplate.

[alex-zaitsev]

Hi @chancez , we are making some changes for inter-cluster communication in scope of 0.19 release now. This PR should go after we are done with those changes.

Also, I think it makes sense to move user/password for inter-cluster communication at cluster level. It is not a part of hostTemplate.

[chancez]

@alex-zaitsev sure, that seems reasonable. So next to the secret field I added then?

[chancez]

If we move it from the host configuration, how is this supposed to be configured for the auto-generated clusters? https://github.com/Altinity/clickhouse-operator/blob/master/pkg/model/ch_config_generator.go#L336-L398

[chancez]

@alex-zaitsev Thoughts on how to deal with configuring auto generated clusters when internode authentication is configured?

[alex-zaitsev]

@sunsingerus , there are two distinct changes here:

1. Using <secret> for inter-cluster communication.
2. Using user/pass.

I think <secret> should be default if it passes all tests

[alex-zaitsev]

@chancez , we will implement the following:

  configuration:
    clusters:
      - name: default
        secure: yes # (default off) turns on HTTPS
        secret:
          auto: yes          # (default) operator creates a secret with name {chi}-{cluster}-interserver-secret and random hash as secret
          value: abcd        # Use explicit secret value
          valueSecretKeyRef: # Use secret reference
            ... 

[chancez]

@alex-zaitsev Sounds good. I can rebase and I think this PR is pretty close to the configuration you've suggested, so hopefully this can be merged soon then.

[chancez]

@alex-zaitsev I'm looking back into this but my question from earlier is still unanswered:

Thoughts on how to deal with configuring auto generated clusters when internode authentication is configured?

Setting secure at the cluster level makes sense to me, but the auto-generated clusters don't have a cluster context. Should I just set <secure>1</secure> if the user defines any clusters with secure: true? If the user defines more than 1 cluster, one with secure, one without, then how should auto-generated clusters be configured? Secure or not? Should I just not worry about the auto generated clusters (even though they won't work?). This was one motivation I had for configuring the secure field on the hostTemplate level. Perhaps both should be supported? Same issue applies to the <secret> and <username>, etc as well.

[alex-zaitsev]

@chancez , secrets for inter-cluster communication are implemented in 0.20.0. See usage examples: https://github.com/Altinity/clickhouse-operator/blob/0.20.0/docs/chi-examples/21-secure-cluster-secret-01-auto.yaml https://github.com/Altinity/clickhouse-operator/blob/0.20.0/docs/chi-examples/21-secure-cluster-secret-02-plaintext.yaml https://github.com/Altinity/clickhouse-operator/blob/0.20.0/docs/chi-examples/21-secure-cluster-secret-03-secret-ref.yaml