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 <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
