You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Yunze Xu <yz...@streamnative.io.INVALID> on 2022/04/18 07:16:51 UTC
Re: [Discuss] Generate cert and key files automatically
I have another concern that since we have to use `AuthenticationTls` for TLS
transport encryption, how can we perform a non-TLS authentication? It looks
like there’s no way to do that.
Thanks,
Yunze
> 2022年3月23日 11:24，Zixuan Liu <no...@gmail.com> 写道：
>
>> I think the priority of `AuthenticationTls` must be higher. Then it
> should be encouraged to use `AuthenticationTls` when TLS authentication is
> enabled at broker side. Otherwise, these two options should be encouraged
> to use.
>
> You are right, if we are set up the `AuthenticationTls` and TLS transport,
> we should use the `AuthenticationTls` data to set up, `AuthenticationTls`
> must be higher. When the user set up two config, we need to throw an
> expectation that only use the `AuthenticationTls`, or `tlsCertFilePath` and
> `tlsKeyFilePath`.
>
>
> Yunze Xu <yz...@streamnative.io.invalid> 于2022年3月23日周三 01:57写道：
>
>> If `tlsCertFilePath` and `tlsKeyFilePath` were added to the client builder
>> options, I think they can also be used for TLS authentication as well.
>>
>> I prefer this solution now just because it looks like generating
>> certificats
>> automatically is not good, from what Enrico said.
>>
>> The problem is that what if we configured both `AuthenticationTls` and
>> those
>> two options? Because the underlying mechanisms are the same that a
>> `SslContext`
>> is created from the cert and key files and then the `SslContext` object
>> will be
>> used in the TCP or HTTP transport.
>>
>> I think the priority of `AuthenticationTls` must be higher. Then it should
>> be
>> encouraged to use `AuthenticationTls` when TLS authentication is enabled at
>> broker side. Otherwise, these two options should be encouraged to use.
>>
>> Thanks,
>> Yunze
>>
>>
>>
>>
>>> 2022年3月22日 上午11:03，Zixuan Liu <no...@gmail.com> 写道：
>>>
>>> Hi Yunze,
>>>
>>> The current implementation is confusing, we should split the transport
>> and
>>> auth for TLS.
>>>
>>> For transport, the code can be so like:
>>> ```
>>> PulsarClient client = PulsarClient.builder()
>>> .enableTls(true)
>>> .tlsTrustCertsFilePath("ca.pem")
>>> .tlsCertFilePath("client-ca.pem")
>>> .tlsKeyFilePath("client-key.pem")
>>> .build();
>>> ```
>>>
>>> For auth, the code can be so like:
>>> ```
>>> Map<String, String> authParams = new HashMap<>();
>>> authParams.put("tlsCertFile", "client-ca.pem");
>>> authParams.put("tlsKeyFile", "client-key.pem");
>>> PulsarClient client = PulsarClient.builder()
>>> .enableTls(true)
>>> .tlsTrustCertsFilePath("ca.pem")
>>> .authentication(AuthenticationTls.class.getName(),
>>> authParams)
>>> .build();
>>> ```
>>>
>>> When using the TLS auth, we don't need to set
>>> tlsCertFilePath("client-ca.pem") and tlsKeyFilePath("client-key.pem"),
>> the
>>> authentication instead of this.
>>>
>>> There have an important thing that if we are using the authentication
>> with
>>> the token, we cannot setup the TLS transport.
>>>
>>>
>>> Enrico Olivelli <eo...@gmail.com> 于2022年3月22日周二 00:40写道：
>>>
>>>> Il giorno lun 21 mar 2022 alle ore 16:31 Yunze Xu
>>>> <yz...@streamnative.io.invalid> ha scritto:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Recently I found a document error when configuring Pulsar client for
>> TLS
>>>>> encryption. See https://github.com/apache/pulsar/issues/14762.
>> However,
>>>> the code
>>>>> example in the official documents is more intuitive.
>>>>>
>>>>> See
>>>> https://pulsar.apache.org/docs/en/security-tls-transport/#java-client,
>> the
>>>>> example code doesn't configure `AuthenticationTls`, but it is required
>>>> once TLS
>>>>> encryption is enabled, even if TLS authentication is not enabled.
>>>> Because the
>>>>> client side can only send a SSL handshake via `AuthenticationTls`. It
>>>> would be
>>>>> confused.
>>>>>
>>>>> Since the cert file and the key file are generated using a CA, whose
>>>> path is
>>>>> specified by `tlsTrustCertsFilePath` method, I think it would be
>>>> possible to
>>>>> generate a cert and a key file automatically. We only need to specify a
>>>> common
>>>>> name, which represents the role when authentication is enabled.
>>>>
>>>> Usually a service cannot generate a "valid" certificate automatically,
>>>> it MUST be signed by a CA.
>>>>
>>>> We may add an option to automatically generate a certificate (and a
>>>> CA) but that will work only for
>>>> DEV environments.
>>>>
>>>> Enrico
>>>>
>>>>
>>>>>
>>>>> My initial design is, when client configures the
>> `tlsTrustCertsFilePath`:
>>>>> - If no authentication plugin is enabled, generate the cert and key
>> files
>>>>> automatically using a default common name.
>>>>> - Otherwise, use the cert and key files specified in
>> `AuthenticationTls`.
>>>>>
>>>>> The benefit is, when you want to pass the TLS authentication, you must
>>>> configure
>>>>> `AuthenticationTls` at client side, while you only needs to configure
>>>>> `tlsTrustCertsFilePath` if broker side only enables TLS encryption.
>>>>>
>>>>> What do you think? Is there a better solution?
>>>>>
>>>>> Thanks,
>>>>> Yunze
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: [Discuss] Generate cert and key files automatically
Posted by Zixuan Liu <no...@gmail.com>.
You are right, we need to spilt this point.
Yunze Xu <yz...@streamnative.io.invalid> 于2022年4月18日周一 15:17写道：
> I have another concern that since we have to use `AuthenticationTls` for
> TLS
> transport encryption, how can we perform a non-TLS authentication? It looks
> like there’s no way to do that.
>
> Thanks,
> Yunze
>
>
>
>
> > 2022年3月23日 11:24，Zixuan Liu <no...@gmail.com> 写道：
> >
> >> I think the priority of `AuthenticationTls` must be higher. Then it
> > should be encouraged to use `AuthenticationTls` when TLS authentication
> is
> > enabled at broker side. Otherwise, these two options should be encouraged
> > to use.
> >
> > You are right, if we are set up the `AuthenticationTls` and TLS
> transport,
> > we should use the `AuthenticationTls` data to set up, `AuthenticationTls`
> > must be higher. When the user set up two config, we need to throw an
> > expectation that only use the `AuthenticationTls`, or `tlsCertFilePath`
> and
> > `tlsKeyFilePath`.
> >
> >
> > Yunze Xu <yz...@streamnative.io.invalid> 于2022年3月23日周三 01:57写道：
> >
> >> If `tlsCertFilePath` and `tlsKeyFilePath` were added to the client
> builder
> >> options, I think they can also be used for TLS authentication as well.
> >>
> >> I prefer this solution now just because it looks like generating
> >> certificats
> >> automatically is not good, from what Enrico said.
> >>
> >> The problem is that what if we configured both `AuthenticationTls` and
> >> those
> >> two options? Because the underlying mechanisms are the same that a
> >> `SslContext`
> >> is created from the cert and key files and then the `SslContext` object
> >> will be
> >> used in the TCP or HTTP transport.
> >>
> >> I think the priority of `AuthenticationTls` must be higher. Then it
> should
> >> be
> >> encouraged to use `AuthenticationTls` when TLS authentication is
> enabled at
> >> broker side. Otherwise, these two options should be encouraged to use.
> >>
> >> Thanks,
> >> Yunze
> >>
> >>
> >>
> >>
> >>> 2022年3月22日 上午11:03，Zixuan Liu <no...@gmail.com> 写道：
> >>>
> >>> Hi Yunze,
> >>>
> >>> The current implementation is confusing, we should split the transport
> >> and
> >>> auth for TLS.
> >>>
> >>> For transport, the code can be so like:
> >>> ```
> >>> PulsarClient client = PulsarClient.builder()
> >>> .enableTls(true)
> >>> .tlsTrustCertsFilePath("ca.pem")
> >>> .tlsCertFilePath("client-ca.pem")
> >>> .tlsKeyFilePath("client-key.pem")
> >>> .build();
> >>> ```
> >>>
> >>> For auth, the code can be so like:
> >>> ```
> >>> Map<String, String> authParams = new HashMap<>();
> >>> authParams.put("tlsCertFile", "client-ca.pem");
> >>> authParams.put("tlsKeyFile", "client-key.pem");
> >>> PulsarClient client = PulsarClient.builder()
> >>> .enableTls(true)
> >>> .tlsTrustCertsFilePath("ca.pem")
> >>> .authentication(AuthenticationTls.class.getName(),
> >>> authParams)
> >>> .build();
> >>> ```
> >>>
> >>> When using the TLS auth, we don't need to set
> >>> tlsCertFilePath("client-ca.pem") and tlsKeyFilePath("client-key.pem"),
> >> the
> >>> authentication instead of this.
> >>>
> >>> There have an important thing that if we are using the authentication
> >> with
> >>> the token, we cannot setup the TLS transport.
> >>>
> >>>
> >>> Enrico Olivelli <eo...@gmail.com> 于2022年3月22日周二 00:40写道：
> >>>
> >>>> Il giorno lun 21 mar 2022 alle ore 16:31 Yunze Xu
> >>>> <yz...@streamnative.io.invalid> ha scritto:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Recently I found a document error when configuring Pulsar client for
> >> TLS
> >>>>> encryption. See https://github.com/apache/pulsar/issues/14762.
> >> However,
> >>>> the code
> >>>>> example in the official documents is more intuitive.
> >>>>>
> >>>>> See
> >>>> https://pulsar.apache.org/docs/en/security-tls-transport/#java-client
> ,
> >> the
> >>>>> example code doesn't configure `AuthenticationTls`, but it is
> required
> >>>> once TLS
> >>>>> encryption is enabled, even if TLS authentication is not enabled.
> >>>> Because the
> >>>>> client side can only send a SSL handshake via `AuthenticationTls`. It
> >>>> would be
> >>>>> confused.
> >>>>>
> >>>>> Since the cert file and the key file are generated using a CA, whose
> >>>> path is
> >>>>> specified by `tlsTrustCertsFilePath` method, I think it would be
> >>>> possible to
> >>>>> generate a cert and a key file automatically. We only need to
> specify a
> >>>> common
> >>>>> name, which represents the role when authentication is enabled.
> >>>>
> >>>> Usually a service cannot generate a "valid" certificate automatically,
> >>>> it MUST be signed by a CA.
> >>>>
> >>>> We may add an option to automatically generate a certificate (and a
> >>>> CA) but that will work only for
> >>>> DEV environments.
> >>>>
> >>>> Enrico
> >>>>
> >>>>
> >>>>>
> >>>>> My initial design is, when client configures the
> >> `tlsTrustCertsFilePath`:
> >>>>> - If no authentication plugin is enabled, generate the cert and key
> >> files
> >>>>> automatically using a default common name.
> >>>>> - Otherwise, use the cert and key files specified in
> >> `AuthenticationTls`.
> >>>>>
> >>>>> The benefit is, when you want to pass the TLS authentication, you
> must
> >>>> configure
> >>>>> `AuthenticationTls` at client side, while you only needs to configure
> >>>>> `tlsTrustCertsFilePath` if broker side only enables TLS encryption.
> >>>>>
> >>>>> What do you think? Is there a better solution?
> >>>>>
> >>>>> Thanks,
> >>>>> Yunze
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >>
>
>