Hi Luke and Bruno, Thanks for taking a look! Happy to provide some examples here to clarify the points, and if they seem useful enough, we can also add them to the template.
> Does it make Kafka or any of its components (brokers, clients, Kafka Connect, Kafka Streams, Mirror Maker 2, etc.) less secure when run with default settings? Examples include allowing unauthenticated users to access the file system of, or execute code on, the machine running Kafka/one of its components, or create or configure Kafka clients with arbitrary settings > Does it give users new access to configure clients, brokers, topics, etc. in situations where they did not have this access before? Keep in mind that the ability to arbitrarily configure a Kafka client can add to the attack surface of a project and may be safer to disable by default. With examples provided, this point is likely made redundant by the first/third points > Does it make Kafka or any of its components more difficult to run in a fully-secured fashion? Examples include requiring new ACLs to run existing components (e.g., requiring write permission for a specific transactional ID in order to start Kafka Connect), or adding new APIs that, if left unsecured, would leave the component vulnerable to malicious users (e.g., adding a REST server to Kafka Streams that allows topologies to be dynamically manipulated). I hope this helps; let me know what you think. Cheers, Chris - On Thu, Jan 12, 2023 at 3:51 AM Bruno Cadonna <cado...@apache.org> wrote: > Hi Chris, > > Thank you for the proposal! > > Could you add some examples to each of your points? > I think that would make it easier to discussion them. > > Best, > Bruno > > On 12.01.23 03:15, Luke Chen wrote: > > Hi Chris, > > > > I like this idea. > > Thanks for raising this! > > > > One question to the template bullet: > > • Does it make Kafka or any of its components more difficult to run in a > > fully-secured fashion? > > > > I don't quite understand what it means. Could you elaborate on it? > > > > Thank you. > > Luke > > > > On Wed, Jan 11, 2023 at 11:59 PM Chris Egerton <chr...@aiven.io.invalid> > > wrote: > > > >> Hi all, > >> > >> I'd like to propose augmenting the KIP template with a "Security > >> Implications" section. Similar to the recently-added "test plan" > section, > >> the purpose here is to draw explicit attention to the security impact of > >> the changes in the KIP during the design and discussion phase. On top of > >> that, it should provide a common framework for how to reason about > security > >> so that everyone from new contributors to seasoned committers/PMC > members > >> can use the same standards when evaluating the security implications of > a > >> proposal. > >> > >> Here's the draft wording I've come up with so far for the template: > >> > >> How does this impact the security of the project? > >> • Does it make Kafka or any of its components (brokers, clients, Kafka > >> Connect, Kafka Streams, Mirror Maker 2, etc.) less secure when run with > >> default settings? > >> • Does it give users new access to configure clients, brokers, topics, > etc. > >> in situations where they did not have this access before? Keep in mind > that > >> the ability to arbitrarily configure a Kafka client can add to the > attack > >> surface of a project and may be safer to disable by default. > >> • Does it make Kafka or any of its components more difficult to run in a > >> fully-secured fashion? > >> > >> Let me know your thoughts. My tentative plan is to add this (with any > >> modifications after discussion) to the KIP template after at least one > week > >> has elapsed, there has been approval from at least a couple seasoned > >> contributors, and there are no unaddressed objections. > >> > >> Cheers, > >> > >> Chris > >> > > >
