[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356230#comment-17356230
]
Sumanth Pasupuleti edited comment on CASSANDRA-16669 at 6/3/21, 6:43 AM:
-------------------------------------------------------------------------
Thanks [~stefan.miklosovic] and [~vinaykumarcse] for the feedback.
I've incorporated following updates and the
[PR|https://github.com/apache/cassandra/pull/1028] reflects the changes.
1. I changed obfuscation logic to just replace the password with ****** and
retain rest of the operation string.
2. Having thought about it again, I agree we may not need a toggle to turn off
password obfuscation for audit logging. I've now removed the configurable, and
we now always obfuscate password for DCL statements
3. Extracted obfuscation logic into its own (singleton) class that implements
an interface.
4. Added test cases specific to password obfuscation logic.
5. Audit logging documentation has been updated to reflect this change about
obfuscating passwords
With regards to "Why did you choose to obfuscate passwords in AuditLogging vs
QueryEvents? What is your stance on password being visible in FQL or other
subscribers of QueryEvents?",
1. Given that QueryEvents is a centralized common emitter of events to all
registered listeners, choosing to obfuscate password in QueryEvents would force
the obfuscation behavior to all the registered listeners vs leaving that
decision to individual listeners. This is the reason why I chose to keep this
obfuscation change localized to AuditLogging.
2. My stance on password visibility in FQL is that, given FQL is meant to
replay traffic to achieve identical results, I would vote for password staying
visible in FQL.
Please let me know if you have further feedback on the PR.
was (Author: sumanth.pasupuleti):
Thanks [~stefan.miklosovic] and [~vinaykumarcse] for the feedback.
I've incorporated following updates and the
[PR|https://github.com/apache/cassandra/pull/1028] reflects the changes.
1. I changed obfuscation logic to just replace the password with ****** and
retain rest of the operation string.
2. Having thought about it again, I agree we may not need a toggle to turn off
password obfuscation for audit logging. I've now removed the configurable, and
we now always obfuscate password for DCL statements
3. Extracted obfuscation logic into its own (singleton) class that implements
an interface.
4. Added test cases specific to password obfuscation logic.
5. Audit logging documentation has been updated to reflect this change about
obfuscating passwords
With regards to "Why did you choose to obfuscate passwords in AuditLogging vs
QueryEvents? What is your stance on password being visible in FQL or other
subscribers of QueryEvents?",
1. Given that QueryEvents is a centralized common emitter of events to all
registered listeners, choosing to obfuscate password in QueryEvents would force
the obfuscation behavior to all the registered listeners vs leaving that
decision to individual listeners. This is the reason why I chose to keep this
obfuscation change localized to AuditLogging.
2. My stance on password visibility in FQL is that, given FQL is meant to
replay traffic to achieve identical results, I would vote for password staying
visible in FQL.
> Password obfuscation for DCL audit log statements
> -------------------------------------------------
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/auditlogging
> Reporter: Vinay Chella
> Assignee: Sumanth Pasupuleti
> Priority: Normal
> Labels: audit, security
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
