[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382483#comment-16382483
]
Vinay Chella edited comment on CASSANDRA-12151 at 3/1/18 8:32 PM:
------------------------------------------------------------------
I like the idea of keeping the auditing configurations to be simple at keyspace
level, as you mentioned specifying the configurations at table level gets too
messy to manage. Also adding new configurations as on when adding new tables
would be tough to manage and operate. Regarding maintaining separate files for
audit log configurations, makes it difficult for the C* operators, sidecars,
config management systems to manage several configuration files. It would
become maintenance overhead to manage configuration files per feature. So I
would keep it simple and manage configurations via a single file in
cassandra.yaml. Even maintaining separate config file does not reduce the
overhead of adding/ removing table level audit log configurations. IMO, if we
are managing any configurations at table level, config file might not be a good
place, table property?
{quote}Configuration of whitelisted users and separate auditing configuration
for each user
{quote}
Seems like a complicated configuration, would like to understand the use cases
more here and see if anyone else needs this functionality. All the usecases
that I see here are Auditing at the cluster or no auditing, but not specific to
user. I would love to hear if there are any other users with this usecase.
{quote}Auditing bind values of prepared statements and its configuration
{quote}
This would be a security concern to keep the actual data in logs, these logs
could be shipped over the wire to an archival system for log rotation, in which
case data goes over the wire as a plain text and all the effort of securing the
C* cluster are not helpful at that point. Audit log should not become a
security hole in C* design.
{quote}Logging every statement in a Batch separately may have significant
performance hit.
{quote}
Merging the entire batch of statements to a single log line would be a
performance hit or might hit the limitations of message sizes in logger or any
such implementations. Considering the performance of storing the entire batch
of statements and logging them might not be a great idea for GC reasons as
well, there is always a tradeoff between small working set size vs one large
working set in terms of low garbage collection overhead, allocator overhead. If
we think logging individual statement in the batch might not come for free, I
would rather approach it differently in case of batch, we just limit it to log
only statement types and its count or just the prepared statement ids? We also
need to keep the performance overhead that we are adding to the request path
with AuditLog.
{quote} Password Obfuscation for DCL Queries
{quote}
Yes, Agreed - Password Obfuscation for DCL Queries shall be fixed.
{quote}Are you planning to evaluate and implement a Chronicle Queue variant
similar to CASSANDRA-13983?
{quote}
Yes, there is certainly a possible option to provide one more minimal
performance impact implementation for IAuditLogger, and we can consider binlog.
I will take a look at it next week and create a follow-up JIRA as needed.
was (Author: vinaykumarcse):
I like the idea of keeping the auditing configurations to be simple at keyspace
level, as you mentioned specifying the configurations at table level gets too
messy to manage. Also adding new configurations as on when adding new tables
would be tough to manage and operate. Regarding maintaining separate files for
audit log configurations makes it difficult for the C* operators, sidecars,
config management systems to manage several configuration files. It would
become maintenance overhead to manage configuration files per feature. So I
would keep it simple and manage configurations via a single file in
cassandra.yaml. Even maintaining separate config file does not reduce the
overhead of adding/ removing table level audit log configurations. IMO, if we
are managing any configurations at table level, config file might not be a good
place, table property?
{quote}Configuration of whitelisted users and separate auditing configuration
for each user
{quote}
seems like a complicated configuration, would like to understand the use cases
more here and would like to see if anyone else needs this functionality. All
the usecases that I see here, either Audit the cluster or not, but not specific
to user, I would love to hear if there are any other users with this usecase.
{quote}Auditing bind values of prepared statements and its configuration
{quote}
This would be a security concern to keep the actual data in logs, these logs
could be shipped over the wire to an archival system for log rotation, in which
case data goes over the wire as a plain text and all the effort of securing the
C* cluster are not helpful at that point. Audit log should not become a
security hole in C* design.
{quote}Logging every statement in a Batch separately may have significant
performance hit.
{quote}
Merging the entire batch of statements to a single log line would be a
performance hit or might hit the limitations of message sizes in logger or any
such implementations. Considering the performance of storing the entire batch
of statements and logging them might not be a great idea for GC reasons as
well, there is always a tradeoff between small working set size vs one large
working set in terms of low garbage collection overhead, allocator overhead. If
we think logging individual statement in the batch might not come for free, I
would rather approach it differently in case of batch, we just limit it to log
only statement types and its count or just the prepared statement ids? We also
need to keep the performance overhead that we are adding to the request path
with AuditLog.
{quote} Password Obfuscation for DCL Queries
{quote}
Yes, Agreed - Password Obfuscation for DCL Queries shall be fixed.
{quote}Are you planning to evaluate and implement a Chronicle Queue variant
similar to CASSANDRA-13983?
{quote}
Yes, there is certainly a possible option to provide one more minimal
performance impact implementation for IAuditLogger, and we can consider binlog.
I will take a look at it next week and create a follow-up JIRA as needed.
> Audit logging for database activity
> -----------------------------------
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
> Issue Type: New Feature
> Reporter: stefan setyadi
> Assignee: Vinay Chella
> Priority: Major
> Fix For: 4.x
>
> Attachments: 12151.txt,
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done
> on our server.
> It should show username, remote address, timestamp, action type, keyspace,
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting
> a specific keyspace and column family.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
