Does anybody have any questions / comments?
Dinesh
> On Jul 17, 2023, at 12:37 PM, Dinesh Joshi wrote:
>
> Hi folks,
>
> Given the feedback received, we thought it would be best to do a CEP. Here's
> the link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34
>
> It incorporates t
Hi folks,
Given the feedback received, we thought it would be best to do a CEP. Here's
the link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34
It incorporates the feedback we've received. Please let me know if there are
any other comments. We'll wait for a bit and start a VOTE th
I can certainly start a VOTE thread for the CQL syntax addition. There
hasn't been any feedback that suggests that there is an unaddressed
concern to the changes we are making.
That said, I'm not sure if there was explicit decision that has resulted
in an update to the project's governance to refl
> folks - I think we’ve achieved lazy consensus here. Please continue with
feedback on the jira.
Hi Dinesh,
As Jeremiah commented on JIRA, shouldn't we have a vote in the ML?
For the future reference, in my opinion, adding new CQL syntax should have
a CEP as it is not something we can easily cha
EC - eventual consensus?
On Tue, Jul 11, 2023 at 4:03 PM Dinesh Joshi wrote:
> folks - I think we’ve achieved lazy consensus here. Please continue with
> feedback on the jira.
>
> Thanks,
>
> Dinesh
>
>
> On Jul 7, 2023, at 12:23 PM, Jyothsna Konisa
> wrote:
>
>
> Hi Yuki, Jeremiah & Christop
folks - I think we’ve achieved lazy consensus here. Please continue with feedback on the jira.Thanks,DineshOn Jul 7, 2023, at 12:23 PM, Jyothsna Konisa wrote:Hi Yuki, Jeremiah & Christopher,Thank you very much for the feedback. Regarding removing superuser check for adding/removing identities, I
Hi Yuki, Jeremiah & Christopher,
Thank you very much for the feedback.
Regarding removing superuser check for adding/removing identities, I have
relaxed that check and added permissions check instead. With this change
only users with appropriate permissions to add/drop identities can perform
that
> On Jun 30, 2023, at 1:09 PM, Jeremiah Jordan wrote:
>
> I don’t think users necessarily need to be able to update their own
> identities. I just don’t want to have to use the super user role. The super
> user role has all power over all things in the data base. I don’t want to
> have to g
> It is surprising to me that we load the identity from the keystore vs
> explicitly setting an expected value in cassandra.yaml. I get that an error
> is thrown if the identity doesn't match those of other nodes in the cluster,
> but does it make sense to prevent startup should the value in the
Looping back to the discussion around keystore usage and shared vs
individual identity. I understand the approach of having a single identity
shared by all nodes in the cluster. Including the entire response here, but
want to focus on the first line.
*The reason we use the keystore is that the nod
I don’t think users necessarily need to be able to update their own
identities. I just don’t want to have to use the super user role. The
super user role has all power over all things in the data base. I don’t
want to have to give that much power to the person who manages identities,
I just wan
Yuki, Jeremiah both are fair points. The mental model we're using for
mTLS authentication is slightly different.
In your model you're treating the TLS identity itself to be similar to
the password. The password is the 'shared secret' that currently needs
to be rotated by the user that owns the acc
I like the idea of extending CREATE ROLE rather than adding a brand new ADD
IDENTITY syntax. Not sure how that can line up with one to many
relationships for an identity, but maybe that can just be done through role
hierarchy?
In either case, I don’t think IDENTITY related operations should be ti
Thinking more about "CREATE ROLE" permission, if we can extend CREATE
ROLE/ALTER ROLE statements, it may look streamlined:
I don't have the good example, but something like:
```
CREATE ROLE dev WITH LOGIN = true AND IDENTITIES = {'spiffe://xxx'};
ALTER ROLE dev ADD IDENTITY 'xxx';
LIST ROLES;
```
Hi Jyothsna,
I think for the *initial* commit, the description looks fine to me.
I'd like to see/contribute to the future improvement though:
* ADD IDENTITY requires SUPERUSER, this means that the brand new cluster
needs to start with PasswordAuthenticator/CassandraAuthorizer first, and
then chan
Hi Yuki,
I have added cassandra docs for CQL syntax that we are adding and how to
get started with using mTLS authenticators along with the migration plan.
Please review it and let me know if it looks good.
Thanks,
Jyothsna Konisa.
On Wed, Jun 21, 2023 at 10:46 AM Jyothsna Konisa
wrote:
> Hi Y
Hi Yuki!
Thanks for the questions.
Here are the steps for the initial setup.
1. Since only super users can add/remove identities from the
`identity_to_roles` table, operators should use that role to add authorized
identities to the table. Note that the authenticator is not an mTLS
authenticator
Hi Jyothsna,
Thanks, sorry I have additional questions regarding set up and migration:
* Initial set up
Say, you are building the brand new cassandra cluster with
authenticator:
class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
parameters :
validator_class_name:
org.apache.ca
Hi Yuki,
Sorry I missed answering your other question in the above reply. Regarding
checking what identities are associated with a given role, one can make a
query to list identities for a given role to the table. Also note that,
addition or removal of identities from the table can only be perform
Hi Yuki,
You are right regarding adding a custom validator. If one wants to
implement a CN based validator, they can do that and configure that
validator in Cassandra.yaml in "authenticator.parameters.
validator_class_name".
Regarding a role having multiple identities, yes a role can have multiple
HI,
I was discussing with users the other day regarding a similar feature.
They were thinking of implementing the custom Authenticator similar to what
MySQL offers:
CREATE USER 'jeffrey'@'localhost'
REQUIRE SUBJECT '/C=SE/ST=Stockholm/L=Stockholm/
O=MySQL demo client certificate/
CN=cli
Folks, any feedback here?
On 6/15/23 12:46, Jyothsna Konisa wrote:
> Hi Everyone!
>
> We are adding the following CQL queries in this patch for adding and dropping
> identities in the new `system_auth.identity_to_role` table.
>
> ADD IDENTITY 'testIdentity' TO ROLE 'testRole';
> DROP IDENTITY '
Hi Everyone!
We are adding the following CQL queries in this patch for adding and
dropping identities in the new `system_auth.identity_to_role` table.
ADD IDENTITY 'testIdentity' TO ROLE 'testRole';
DROP IDENTITY 'testIdentity';
Please let us know if anyone has any concerns!
Thanks,
Jyothsna Ko
Sounds great, thanks for the clarification!
Cheers,
Derek
On Sat, Jun 3, 2023 at 12:48 AM Dinesh Joshi wrote:
> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker
> wrote:
>
> This certainly looks like a nice addition to the operator's tools for
> securing cluster access. Out of curiosity, is ther
> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker wrote:
>
> This certainly looks like a nice addition to the operator's tools for
> securing cluster access. Out of curiosity, is there anything in this work
> that would *preclude* a different authentication scheme for internode at some
> point i
Hi Dinesh,
This certainly looks like a nice addition to the operator's tools for
securing cluster access. Out of curiosity, is there anything in this work
that would *preclude* a different authentication scheme for internode at
some point in the future? Has there ever been discussion of pluggabili
Hi Christopher,
Thanks for all the questions. I want to add some details about internode mTLS
connection & internode mTLS authenticator that we are adding in this patch.
SSL/TLS related configuration for internode connections are present in
“server_encryption_options” section of cassandra.yam
> On Jun 2, 2023, at 1:56 PM, Christopher Bradford wrote:
>
> I am not sure what you mean by this would be used alongside internode and
> client TLS? The mutual TLS authentication allows the server to authenticate
> the client's identity using a client TLS certificate. The authenticators
> we'
> I am not sure what you mean by this would be used alongside internode and
> client TLS? The mutual TLS authentication allows the server to authenticate
> the client's identity using a client TLS certificate. The authenticators
> we're adding enable this functionality. There isn't an expectation t
> Is there an expectation that this would be used alongside internode and
> client TLS? Would the certificates be the same, different, or is that an
> implementation detail for the specific deployment to determine?
I am not sure what you mean by this would be used alongside internode and
client
Hi Dinesh,
This is awesome. I'm certain myself and the folks on the K8ssandra project
will be following along with this ticket. I had a few questions after
looking at the JIRA and attached PR:
1. Is there an expectation that this would be used alongside internode
and client TLS? Would the
Hi dev@,
We're planning to add mTLS client authentication as well as internode
authentication in CASSANDRA-18554. While this is all backward compatible, we
thought it would be a good idea to notify the dev list. If anybody is
interested please take a look at the JIRA.
Thanks,
Dinesh
32 matches
Mail list logo
