Re: [DISCUSS] Add "Security Implications" section to KIP template

[Chris Egerton <ch...@aiven.io.INVALID>]

Hi Bruno,

Apologies for the delay; covid paid me a visit recently and took me away
from this discussion for a bit.

I'm fine with adding specific examples to help flesh out the questions we
want to think about while writing/reviewing KIPs, but IMO it's important to
emphasize that they are not comprehensive and that it's not enough to
address each example individually instead of considering the high-level
questions that they apply to.

RE creating/configuring Kafka clients with arbitrary settings: I was
imagining creating/configuring them on a machine that you do not otherwise
have access to, a detail that should definitely be added to the template if
we still want to call out this scenario. Creating/configuring a Kafka
client on a machine that you do not own can be used to, e.g., perform a DOS
attack on an arbitrary hostname by instantiating a large number of clients
that use that hostname for their bootstrap server.

Taking recent discussion into account, here's a revised draft for the
proposed "Security Implications" section:


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 access to the file system or execute code on the machine
running Kafka or one of its components?
• Does it allow users to create or arbitrarily configure Kafka clients on a
machine that they otherwise do not have access to?
• Does it give unauthenticated users new ways to access topics, connectors,
or other Kafka-related resources?
• Does it allow users to allocate an unbounded amount of some resource on
the user's machine, such as heap memory, network connections, or disk space?

Does it make Kafka or any of its components more difficult to run in a
fully-secured fashion?
• Does it introduce a new API such as a REST server that, if left
unsecured, could be used by malicious users to attack the component or the
machine it's running on?
• Does it require additional Kafka ACLs for the component to run
successfully, such as permission to access a new transactional producer ID?
• Does it require new access to resources on the user's machine, such as
permission to create, read, or modify files?
• Does it require new access to resources in the user's environment, such
as permission to issue arbitrary network requests?


Looking forward to your thoughts!

Cheers,

Chris

On Mon, Jan 16, 2023 at 4:47 AM Bruno Cadonna <ca...@apache.org> wrote:

> Hi Chris,
>
> Thanks for the clarifications!
>
> I am in favor to formulate the questions more concretely, like:
>
>
> Does the KIP access the file system or execute code on the machine
> running Kafka or one of its components?
>
> Does the KIP introduce new components that need to be secured separately?
>
>
> Probably, this list needs to be extended.
>
> I think, we need to be as concrete as possible to get the info we want
> in a KIP to be able to review it well.
>
>
>  From the examples you provided, I do not understand the following. What
> does it mean to "create or configure Kafka clients with arbitrary
> settings"? Independently of a change in a KIP, one can always create or
> configure a Kafka client with arbitrary settings. The brokers need to
> take care of such cases anyways. I do not see how this extends the
> attack surface. But maybe I am missing something here.
>
>
> Best,
> Bruno
>
>
> On 12.01.23 20:05, Chris Egerton wrote:
> > 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 <ca...@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 <chrise@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
> >>>>
> >>>
> >>
> >
>