[ 
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17357424#comment-17357424
 ] 

Vinay Chella commented on CASSANDRA-16669:
------------------------------------------

Thank you for the update [~sumanth.pasupuleti]. I left a few nitpicks (doc 
updates and few more specific tests covering regex) on your PR.
{quote}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.
{quote}
SGTM, thanks to [~stefan.miklosovic] for asking about FQL password obfuscation 
on dev list, I would love to hear other's opinions on this,

> Password obfuscation for DCL audit log statements
> -------------------------------------------------
>
>                 Key: CASSANDRA-16669
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tool/auditlogging
>            Reporter: Vinay Chella
>            Assignee: Sumanth Pasupuleti
>            Priority: Normal
>              Labels: audit, security
>             Fix For: 4.0-rc, 4.0.x, 4.x
>
>          Time Spent: 50m
>  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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to