Hi Ryanne, Yes, if the Connect group is left unsecured then that is a potential vulnerability. However, in a truly secure Connect cluster, the group would need to be secured anyways to prevent attackers from joining the group with the intent to either snoop on connector/task configurations or bring the cluster to a halt by spamming the group with membership requests and then not running the assigned connectors/tasks. Additionally, for a Connect cluster to be secure, access to internal topics (for configs, offsets, and statuses) would also need to be restricted so that attackers could not, e.g., write arbitrary connector/task configurations to the configs topic. This is all currently possible in Kafka with the use of ACLs.
I think the bottom line here is that there's a number of steps that need to be taken to effectively lock down a Connect cluster; the point of this KIP is to close a loophole that exists even after all of those steps are taken, not to completely secure this one vulnerability even when no other security measures are taken. Cheers, Chris On Wed, Aug 14, 2019 at 10:56 PM Ryanne Dolan <ryannedo...@gmail.com> wrote: > Chris, I don't understand how the rebalance protocol can be used to give > out session tokens in a secure way. It seems that any attacker could just > join the group and sign requests with the provided token. Am I missing > something? > > Ryanne > > On Wed, Aug 14, 2019, 2:31 PM Chris Egerton <chr...@confluent.io> wrote: > > > The KIP page can be found at > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-507%3A+Securing+Internal+Connect+REST+Endpoints > > , > > by the way. Apologies for neglecting to include it in my initial email! > > > > On Wed, Aug 14, 2019 at 12:29 PM Chris Egerton <chr...@confluent.io> > > wrote: > > > > > Hi all, > > > > > > I'd like to start discussion on a KIP to secure the internal "POST > > > /connectors/<name>/tasks" endpoint for the Connect framework. The > > proposed > > > changes address a vulnerability in the framework in its current state > > that > > > allows malicious users to write arbitrary task configurations for > > > connectors; it is vital that this issue be addressed in order for any > > > Connect cluster to be secure. > > > > > > Looking forward to your thoughts, > > > > > > Chris > > > > > >
