Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[client-v2] mTLS & HTTPs support #1715

Closed
chernser opened this issue Jul 1, 2024 · 0 comments · Fixed by #1753
Closed

[client-v2] mTLS & HTTPs support #1715

chernser opened this issue Jul 1, 2024 · 0 comments · Fixed by #1753

Comments

@chernser
Copy link
Contributor

chernser commented Jul 1, 2024

HTTPs Support

This is an essential feature. All traffic should go thru TLS Strictly speaking (even while testing or development). TLS and mTLS is used nowadays mostly everywhere and private cloud is not an exception. Client in this way should
act accordingly and have all needed tools. JDK and 3rdpart clients have built-in support for TLS. However there is a problem with self-signed certificates that often used in tests and private cloud envs.

Here is a list of major use cases that should be verified:

  • Connection to a host over HTTPs when host has valid certificate
  • Connection to a host over HTTPs when host has self-signed certificate
  • Connection to a host that requires client certificate to identify a client

Settings

Next settings should be deprecated:

  • com.clickhouse.client.config.ClickHouseClientOption#SSL "Whether to enable SSL/TLS for the connection." - SSL connections should be enabled by default. It means that no additional configuration needed to connect to host with valid not self-signed certificate.
  • com.clickhouse.client.config.ClickHouseClientOption#SSL_MODE "verify or not certificate: none (don't verify), strict (verify)" - this should be renamed to something more clear. But in general verification MUST be always one. There is a trust store that should be used instead.
  • com.clickhouse.client.config.ClickHouseClientOption#SSL_ROOT_CERTIFICATE "SSL/TLS root certificates." - Currently it means trusted root certificate and it should be named accordingly.
  • SSL_CERTIFICATE "SSL/TLS certificate." - Currently it means client certificate and it should be named accordingly.
  • SSL_KEY - "RSA key in PKCS#8 format." - Currently it means client private key and it should be named accordingly
  • KEY_STORE_TYPE "Specifies the type or format of the keystore/truststore file used for SSL/TLS configuration, such as "JKS" (Java KeyStore) or "PKCS12."" - should be derived from keystore/truststore configuration
  • TRUST_STORE "Path to the truststore file" - Currently is SSL trust store for http connection and it should be named accordingly
  • KEY_STORE_PASSWORD "Password needed to access the keystore file specified in the keystore config" - Currently it is a keystore password for SSL connections

Summary:

  • There is a trust store that can be defined by single file with correct extension corresponding to its type
    • trust store can be protected by a password
  • There is a key store that can be defined by a single file
    • key store can be protected by a password
  • Client would have one certificate/key to access password
    • Key rotation would require client to be restarted. (TBD: Need to discuss)
  • There are may be a keystore for DB authentication
    • one certificate/key to use for mTLS
    • one certificate/key to authenticate with DB

Note 1: mTLS https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/

Note 2: certificate authentication with DB https://clickhouse.com/docs/en/guides/sre/ssl-user-auth

Metrics

Not yet

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

Successfully merging a pull request may close this issue.

1 participant