Skip to content

Authenticate node communications#944

Closed
chancez wants to merge 2 commits intoAltinity:0.20.0from
chancez:authenticate_node_communications
Closed

Authenticate node communications#944
chancez wants to merge 2 commits intoAltinity:0.20.0from
chancez:authenticate_node_communications

Conversation

@chancez
Copy link
Copy Markdown
Contributor

@chancez chancez commented May 27, 2022

Please check items PR complies to:

  • All commits in the PR are squashed. More info
  • The PR is made into dedicated next-release branch, not into master branch1. More info
  • 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.

@chancez chancez marked this pull request as draft May 27, 2022 22:11
- Add cluster secret to clusters configuration
- Support supplying username/password in host configuration
- Support supplying internode communication password via k8s secret
- Sets the password in the env-vars of the pod, and configures the
  password to source it from the env-var.
- Update TLS test to configure authentication between nodes

Signed-off-by: Chance Zibolski <[email protected]>
@chancez chancez force-pushed the authenticate_node_communications branch from 9abd234 to b57e6fc Compare May 27, 2022 22:17
@chancez chancez marked this pull request as ready for review May 27, 2022 22:22
@alex-zaitsev
Copy link
Copy Markdown
Member

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.

1 similar comment
@alex-zaitsev
Copy link
Copy Markdown
Member

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
Copy link
Copy Markdown
Contributor Author

chancez commented May 31, 2022

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

@chancez
Copy link
Copy Markdown
Contributor Author

chancez commented May 31, 2022

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
Copy link
Copy Markdown
Contributor Author

chancez commented Jun 6, 2022

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

@sunsingerus sunsingerus changed the base branch from 0.19.0 to 0.20.0 July 15, 2022 09:04
@alex-zaitsev
Copy link
Copy Markdown
Member

@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
Copy link
Copy Markdown
Member

@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
Copy link
Copy Markdown
Contributor Author

chancez commented Jul 27, 2022

@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
Copy link
Copy Markdown
Contributor Author

chancez commented Aug 2, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants