[Feature Request] Add a TLS configuration based on the URL format

[r-mol]

Is your feature request related to a problem? Please describe.

Currently if TLS is enabled OR Nginx is used for the TLS termination towards the Frontend tctl does not know if it should activate the TLS unless one of the relevant flags is toggled

This feature request is taken from issue in the temporalio/tctl about activating TLS only by relevant flag such as --tls_server_name. And currently there is the same inconvenience in the temporalio/cli -

cli/client/factory.go

Line 210 in 92a78d8

func (b *clientFactory) createTLSConfig(c *cli.Context) (*tls.Config, error) {

Currently enabling TLS requires a user to specify hostname twice — first in --address and then in --tls_server_name — which is not very convenient.

Describe the solution you'd like

The solution proposal is exactly the same as in the issue attached above:
"Instead of activating TLS via flags, format of the temporal address can be like this grpc://<IP or DNS>:<port> for plain connection and grpcs://<IP or DNS>:<port> for the TLS. If preffix is not specified then connection can still revert to the non-TLS OR TLS based on one of the flags added. Adding this feature would help with making the Temporal protocol communication intent between the client and the frontend clean."

Additional context

With TLS Activation:

Current method:

temporal --address public-frontend.superhost.com:443 --tls_server_name public-frontend.superhost.com  ...

Proposed method:

temporal --address grpcs://public-frontend.superhost.com:443  ...

Without TLS Activation:

Current method:

temporal --address public-frontend.superhost.com:443 ...

Proposed method:

temporal --address grpc://public-frontend.superhost.com:443  ...

temporal --address public-frontend.superhost.com:443 ...

[cretz]

Some thoughts (I am not a maintainer on this repo):

Currently enabling TLS requires a user to specify hostname twice — first in --address and then in --tls_server_name — which is not very convenient.

Using a custom scheme is not the best, but I would support --tls with no options if you just want to enable TLS with no TLS options (e.g. you are running your own server without mTLS and your server cert is trusted). Then all --tls-X just imply --tls.

Alternatives:

• Use grpcs:// - custom scheme is too specific to us. Also implies URL support (e.g. grpcs://myuser:mypass@myhost).
• Use https:// - this can work, but implies normal HTTP API which it is not, it is a gRPC endpoint. Also, implies URL support like the above.
• Assume TLS by default - Too many users are accustomed to non-tls dev servers and accustomed to the CLI behavior as is
• Try both on non-TLS connection failure - TLS handshake failure is not always the easiest to detect, and blindly trying connections twice on each CLI call for invalid host may be a bit much. And we have to figure out which error to return (probably the non-TLS one). But this is a viable option.

[aromanovich]

A few random thoughts on this (I'm not a maintainer as well):

gRPC has a notion of target. When passed to resolvers, it gets parsed into an actual URL: https://pkg.go.dev/google.golang.org/grpc/resolver#Target

Treating --address as a gRPC target would be both backward- and forward-compatible.
It won't break any current use cases, but, for example, would allow developers who use temporalio/cli as a library to implement and plug in custom resolvers. E.g, one can implement the ability to use --address mycompany://my-cluster-id to connect to their company's clusters (if there are many).

The question with this line of thinking is whether using a custom scheme to choose between TLS and non-TLS is a right thing to do.
On the one hand, gRPC resolvers seem to be mostly about resolving where to connect, not about how.
On the other, having a self-contained address string (that we can use both in --address and TEMPORAL_CLI_ADDRESS env var) might be worth slightly abusing gRPC targets by introducing grpc(s):// schemes.

[bergundy]

I agree with @cretz's suggestion, which also matches the SDK APIs.
In (some) SDKs, if you set tls to an empty object or true it will enable "plain" TLS.

[cretz]

gRPC has

I don't think we need to expose these gRPC client options though. Yes you can write manual resolvers (or use one of the built-in ones like dns:///) but I am intentionally discouraging this from --address in CLI. We support them in SDK alone with other gRPC options though. But that's not how we have people configure TLS in SDK or gRPC.

[r-mol]

I agree with @cretz's suggestion, which also matches the SDK APIs.
In (some) SDKs, if you set tls to an empty object or true it will enable "plain" TLS.

Great, this option suits me and solves the problem.

Then I have a question, will you agree to accept a pull requests (in tctl and cli repos) in which the --tls flag will be implemented?

[bergundy]

Sure, contributions are more than welcome