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 identities associated with it. For example, there can be several read_only users for a given cluster, so the role `readonly_user` can be associated with multiple identities. Regarding the uniqueness of identity, each identity should be associated with only one role. For example, a single identity can not be both admin user and a read only user. We have ensured this by carefully designing the schema of the new table for storing identity information by making identity as the primary key which guarantees that each identity is unique and the same role can have multiple identities. Thanks, Jyothsna Konisa. On Sun, Jun 18, 2023 at 5:42 PM Yuki Morishita <mor.y...@gmail.com> wrote: > 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=client/emailAddress=cli...@example.com'; > > (https://dev.mysql.com/doc/refman/8.0/en/create-user.html#create-user-tls) > > I think they can implement a custom Validator that validates the identity > (for their case, CN) associated with a role using the certificate's > subject, so that's great! > > Regarding new CQL syntax, > > > ADD IDENTITY 'testIdentity' TO ROLE 'testRole'; > > DROP IDENTITY 'testIdentity'; > > This means a role can have multiple identities, and each identities must > be unique? > How can users check what identities are associated with certain roles? > > > On Sun, Jun 18, 2023 at 12:15 AM Dinesh Joshi <djo...@apache.org> wrote: > >> 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 'testIdentity'; >> > >> > Please let us know if anyone has any concerns! >> > >> > Thanks, >> > Jyothsna Konisa. >> > >> > >> > On Sat, Jun 3, 2023 at 7:18 AM Derek Chen-Becker <de...@chen-becker.org >> > <mailto:de...@chen-becker.org>> wrote: >> > >> > Sounds great, thanks for the clarification! >> > >> > Cheers, >> > >> > Derek >> > >> > On Sat, Jun 3, 2023 at 12:48 AM Dinesh Joshi <djo...@apache.org >> > <mailto:djo...@apache.org>> wrote: >> > >> >> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker >> >> <de...@chen-becker.org <mailto:de...@chen-becker.org>> 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 in the >> >> future? Has there ever been discussion of pluggability similar >> >> to the client protocol? >> > >> > This is a pluggable implementation so it's not mandatory to use >> > it and doesn't preclude one from using a different mechanism in >> > the future. We haven't explicitly discussed pluggability i.e. >> > part of protocol negotiation in the past for internode >> > connections. However, this work also does not preclude us from >> > implementing such changes. If we do add negotiation this could >> > be one of the authentication mechanisms. So it would be >> > complimentary. >> > >> > >> >> Also, am I correct in understanding that this would allow for >> >> multiple certificates for the same identity (e.g. distinct >> >> cert per node)? I certainly understand the decision to keep >> >> things simple and have all nodes share identity from the >> >> perspective of operational simplicity, but I also don't want >> >> to get in a situation where a single compromised node would >> >> require an invalidation and redeployment on all nodes in the >> >> cluster. >> > >> > I don't recommend all nodes share the same certificate. Each >> > node in the cluster should obtain a unique certificate with the >> > same SPIFFE. In the event a node is compromised, the operator >> > can revoke that node's certificate without having to redeploy to >> > all nodes in the cluster. >> > >> > thanks, >> > >> > Dinesh >> > >> > >> > >> > -- >> > +---------------------------------------------------------------+ >> > | Derek Chen-Becker | >> > | GPG Key available at https://keybase.io/dchenbecker >> > <https://keybase.io/dchenbecker>and | >> > | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org >> > <https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org> | >> > | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC | >> > +---------------------------------------------------------------+ >> > >> >>
