[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815726#comment-17815726
]
Andy Tolbert edited comment on CASSANDRA-19366 at 2/8/24 3:46 PM:
------------------------------------------------------------------
{quote}Then it will print it twice, once as if it is with --all and the second
time as if it is with --verbose. Could we do it in such a way that when --all
is specified together with --verbose, we just set --all to false so --verbose
will print it just once? I consider --verbose to be a super set of --all as it
will print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{--client-options --all}} would interact with
each other previously, but I agree it shouldn't work this way with
{{{}--verbose{}}}, I will change this.
{quote}I also want to ask about the metadata. Is this something which is going
to expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this is
a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this shortly.
was (Author: andrew.tolbert):
{quote}
Then it will print it twice, once as if it is with --all and the second time as
if it is with --verbose. Could we do it in such a way that when --all is
specified together with --verbose, we just set --all to false so --verbose will
print it just once? I consider --verbose to be a super set of --all as it will
print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{\-\-metadata \-\-all}} would interact with
each other previously, but I agree it shouldn't work this way with
{{--verbose}}, I will change this.
{quote}
I also want to ask about the metadata. Is this something which is going to
expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this
is a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this
shortly.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> ----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
> Reporter: Andy Tolbert
> Assignee: Andy Tolbert
> Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map<string, string>}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
