[ https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382483#comment-16382483 ]
Vinay Chella commented on CASSANDRA-12151: ------------------------------------------ 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