+1 to this proposal. On Mon, Oct 16, 2017 at 7:49 AM, Jakub Scholz <ja...@scholz.cz> wrote:
> I was having some more thoughts about it. We can simply take over what > Kafka broker implements for the listeners: > - We can take over the "listener" and "listener.security.protocol.map" > options to define multiple REST listeners and the security protocol they > should use > - The HTTPS interface will by default use the default configuration options > ("ssl.keystore.localtion" etc.). But if desired, the values can be > overridden for given listener (again, as in Kafka broker "listener.name > .<LISTENER_NAME>.ssl.keystore.location") > > This should address both issues raised. But before I incorporate it into > the KIP, I would love to get some feedback if this sounds OK. Please let me > know what do you think ... > > Jakub > > On Sun, Oct 15, 2017 at 12:23 AM, Jakub Scholz <ja...@scholz.cz> wrote: > > > I agree, adding both HTTP and HTTPS is not complicated. I just didn't saw > > the use case for it. But I can add it. Would you add just support for a > > single HTTP and single HTTPS interface? Or do you see some value even in > > allowing more than 2 interfaces (for example one HTTP and two HTTPS with > > different configuration)? It could be done similarly to how the Kafka > > broker does it through the "listener" configuration parameter with comma > > separated list. What do you think? > > > > As for the "rest" prefix - if we remove it, some of the same > configuration > > options are already used today as the option for connecting from Kafka > > Connect to Kafka broker. So I'm not sure we should mix them. I can > > definitely imagine some cases where the client SSL configuration will not > > be the same as the REST HTTPS configuration. That is why I added the > > prefix. If we remove the prefix, how would you deal with this? > > > > On Fri, Oct 13, 2017 at 6:25 PM, Randall Hauch <rha...@gmail.com> wrote: > > > >> Also, do we need these properties to be preceded with `rest`? I'd argue > >> that we're just configuring the worker's SSL information, and that the > >> REST > >> API would just use that. If we added another non-REST API, we'd want to > >> use > >> the same security configuration. > >> > >> It's not that complicated in Jetty to support both "http" and "https" > >> simultaneously, so IMO we should add that from the beginning. > >> > >> On Fri, Oct 13, 2017 at 9:34 AM, Randall Hauch <rha...@gmail.com> > wrote: > >> > >> > It'd be useful to specify the default values for the configuration > >> > properties. > >> > > >> > On Tue, Oct 10, 2017 at 2:53 AM, Jakub Scholz <ja...@scholz.cz> > wrote: > >> > > >> >> FYI: Based on Ewen's suggestion from the related JIRA, I added a > >> >> clarification to the KIP that it doesn't do anything around > >> authorization > >> >> / > >> >> ACLs. While authorization / ACLs would be for sure valuable feature I > >> >> would > >> >> prefer to leave it for different KIP. > >> >> > >> >> Jakub > >> >> > >> >> On Mon, Oct 9, 2017 at 5:25 PM, Jakub Scholz <ja...@scholz.cz> > wrote: > >> >> > >> >> > Hi, > >> >> > > >> >> > I would like to start a discussion about KIP-208: Add SSL support > to > >> >> Kafka > >> >> > Connect REST interface (https://cwiki.apache.org/ > >> >> > confluence/display/KAFKA/KIP-208%3A+Add+SSL+support+to+ > >> >> > Kafka+Connect+REST+interface). > >> >> > > >> >> > I think this would be useful feature to improve the security of > Kafka > >> >> > Connect. > >> >> > > >> >> > Thanks & Regards > >> >> > Jakub > >> >> > > >> >> > >> > > >> > > >> > > > > >