Hi Nikolai!
>Can you, please, make it more specific?
Why does a business want to have this information?
>What are the use-cases for it?
>Who will be analyzing these events and how?
>Why it’s not convenient to implement it with third-party tools?
This is required by the guys from information security to detect potential
threats of violation the rules for providing access to the data layer.
Analysis in the audit system is usually based on identifying
uncharacteristic integrations. The key feature of the audit, is that
cluster administrators do not have access to modification of audit events.
Third-party tools are great for data analysis, but its not good idea to use
it for audit events collection.
>It’s not clear for me where and when AuditEvents will be sent?
Who will be the receiver of events?
In my opinion, sending an audit event should be initiated when the broker
receives a request that matches the audit parameters. Each organization has
its own receiver system, so a common interface is required that the
organization’s development team can implement to integrate with their audit
system.
Best wishes, Vladimir
Hello, Igor.
>
> Thanks for the KIP.
> I have a couple of comments for it:
>
> > Motivation
> > It is highly demanded in most businesses to have the ability of
> obtaining audit information in case someone changes cluster configuration
> (like creation/deletion/modify/description of any topic or ACLs).
>
> Can you, please, make it more specific?
> Why does a business want to have this information?
> What are the use-cases for it?
> Who will be analyzing these events and how?
> Why it’s not convenient to implement it with third-party tools?
>
> It’s not clear for me where and when AuditEvents will be sent?
> Who will be the receiver of events?
>
> > void audit<T extends AbstractRequest>(AuditEvent<T> event);
>
> 1. `audit` name sounds too general for me. How about `onEvent`?
> 2. Should we introduce a special marker interface for audit events?
> `AuditableRequest`, for example?
>
> > public interface AuditEvent<T extends AbstractRequest> {
> > String guid();
>
> Where this `guid` comes from?
> Will it be the same on each node that receives an auditable event?
> Do we have `guid` for any extensions of `AbstractRequest`?
> If this field is `guid` why do we format this as a String on the API level?
>
> > One or more of AuditExtension's implementations can be configured via
> the configuration audit.extension.classes
>
> Can you, please, add a full list of proposed new configuration properties
> and examples for each to clarify your intentions?
>
>
> > 24 янв. 2020 г., в 18:12, Alexander Dunayevsky <a.a.dunayev...@gmail.com>
> написал(а):
> >
> > Hello Igor,
> >
> > Thanks for your KIP 🙌🏽
> > It would be great to adopt this functionality and getting the best of
> > tracking cluster activity.
> >
> > +1 vote from me
> >
> > Cheers,
> > Alex Dunayevsky
> >
> >
> > On Fri, 24 Jan 2020, 15:35 Игорь Мартемьянов, <ledost...@gmail.com>
> wrote:
> >
> >> Motivation:
> >>
> >>
> >> *It is highly demanded in most businesses to have the ability of
> obtaining
> >> audit information in case someone changes cluster configuration (like
> >> creation/deletion/modify/description of any topic or ACLs).We may add
> this
> >> ability. Since audit requirements are so broad, it's impractical to
> support
> >> all of them.Hence we have to provide ability for users to plug resources
> >> helping to achieve required capabilities.*
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-567%3A+Kafka+Cluster+Audit
> >>
> >>
> >> пт, 24 янв. 2020 г., 17:29 Игорь Мартемьянов <ledost...@gmail.com>:
> >>
> >>> Hello there.
> >>> Please review this KIP.
> >>> Thanks.
> >>>
> >>
>
>
