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 want to give them the power to manage identities.
Jeremiah Jordan e. jerem...@datastax.com w. www.datastax.com On Jun 30, 2023 at 1:35:41 PM, Dinesh Joshi <djo...@apache.org> wrote: > 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 account therefore necessitating > the permission to update their password. But that is not the case with > TLS certificates and mTLS identities. > > The model we're going for is different. The identity is provisioned for > an account by a super user. This is more locked down and the user can > still rotate their own certificates but not change the identity > associated with their account without a super user. > > Once provisioned, a user does not need rotate the identity itself. They > only need to obtain fresh certificates as their certificates near > expiry. This requires no updates on the database unlike passwords. > > We could extend this functionality in the future to allow users to > change their own identity. Nothing here prevents that. > > thanks, > > Dinesh > > > > On 6/29/23 08:16, Jeremiah Jordan wrote: > > 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 tied > > to the super user flag. They should be tied to either existing role > > permissions, or a brand new permissions about IDENTITY. We should not > > require that end users give the account allowed to make IDENTITY changes > > super user permission to do what ever they want across the whole database. > > > On Jun 28, 2023 at 11:48:02 PM, Yuki Morishita <mor.y...@gmail.com > > <mailto:mor.y...@gmail.com>> wrote: > > > 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; > > > ``` > > > > > > This requires a role to identities table as well as the current > > > identity to role table though. > > > > > > On Thu, Jun 29, 2023 at 12:34 PM Yuki Morishita <mor.y...@gmail.com > > > <mailto:mor.y...@gmail.com>> wrote: > > > > > > 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 change > > > to mTLS one. > > > * For this, I'd really like to see Cassandra use password > > > authn and authz by default. > > > * Cassandra allows the user with "CREATE ROLE" permission to > > > create roles without superuser privilege. Maybe it is natural to > > > allow them to add identities also? > > > > > > > > > On Thu, Jun 29, 2023 at 7:35 AM Jyothsna Konisa > > > <jyothsna1...@gmail.com <mailto:jyothsna1...@gmail.com>> wrote: > > > > > > 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 > > > <jyothsna1...@gmail.com <mailto:jyothsna1...@gmail.com>> wrote: > > > > > > 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 yet. > > > EX: ADD IDENTITY > > > 'spiffe://testdomain.com/testIdentifier/testValue > > > < > https://urldefense.com/v3/__http://testdomain.com/testIdentifier/testValue__;!!PbtH5S7Ebw!bc-bxD5J_z84ErqBnLngRGkogZQQF2d5tQcORTek4SaE5S_LVkzIYlLIFY73R48icK6fAwtUBLwxgTEHUA$>' > TO ROLE 'read_only_user' > > > > > > 2. Change authenticator configuration in cassandra.yaml to > > > use mTLS authenticator > > > EX: authenticator: > > > class_name > :org.apache.cassandra.auth.MutualTlsAuthenticator > > > parameters : > > > validator_class_name: > > > org.apache.cassandra.auth.SpiffeCertificateValidator > > > 3. Restart the cluster so that newly configured mTLS > > > authenticator is used > > > > > > What will be the op's first step to set up the roles and > > > identities? > > > -> Yes, the op should set up roles & identities first. > > > > > > Is default cassandra / cassandra superuser login still > > > required to set up other roles and identities? > > > -> When transitioning from a password based to mTLS based > > > authenticators, yes superuser login is required to add > > > identities, as only super users can add them. However when > > > a cluster is using mTLS based authenticator, the super > > > user will be associated with some certificate identity and > > > hence we don't need password based cassandra super user > login. > > > > > > If initial cassandra super user login is required, does > > > that mean super users and "cassandra '' superuser bypass > > > mTLS check? > > > -> No, while adding identities to the roles table in step1 > > > the authenticator will not be an mTLS authenticator. Once > > > the identities are added and the authenticator is > > > configured, even super users have to go through an mTLS > > > check during connection. > > > > > > > > > Regarding migration > > > > > > I *think* you need to first use > > > MutualTlsWithPasswordFallbackAuthenticator so the current > > > roles can login with their password, > > > and eventually the admin sets up identity and then can > > > switch to mTLS auth. > > > Is this the expected way for migration? > > > -> Yes you can do that or else we can add identities with > > > password based login and then change the authenticator to > > > be mTLS authenticator. > > > > > > I think a thorough documentation for this new feature > > > including new CQL syntax, setting up and migration would > > > be greatly appreciated. > > > -> I have added documentation for the authenticators, > > > cqlsh commands in the Javadocs in the source code. Maybe I > > > will add the setup process & migration process in the > > > Javadocs, does this sound good? > > > > > > Thanks, > > > Jyothsna Konisa. > > > > > > On Tue, Jun 20, 2023 at 11:33 PM Yuki Morishita > > > <mor.y...@gmail.com <mailto:mor.y...@gmail.com>> wrote: > > > > > > 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.cassandra.auth.SpiffeCertificateValidator > > > > > > What will be the op's first step to set up the roles > > > and identities? > > > Is default cassandra / cassandra super user login > > > still required to set up other roles and identities? > > > If initial cassandra super user login is required, > > > does that mean super users and "cassandra" superuser > > > bypass mTLS check? > > > > > > * Migration > > > > > > If you are currently using PasswordAuthenticator and > > > would like to migrate to mTLS authentication: > > > > > > I *think* you need to first use > > > MutualTlsWithPasswordFallbackAuthenticator so the > > > current roles can login with their password, > > > and eventually the admin sets up identity and then can > > > switch to mTLS auth. > > > Is this the expected way for migration? > > > > > > I think a thorough documentation for this new feature > > > including new CQL syntax, setting up and migration > > > would be greatly appreciated. > > > > > > > > > On Wed, Jun 21, 2023 at 4:13 AM Jyothsna Konisa > > > <jyothsna1...@gmail.com > > > <mailto:jyothsna1...@gmail.com>> wrote: > > > > > > 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 > > > performed by the super user only. Not even > > > read-write users can perform modifications to the > > > table. > > > > > > Also, If others have no concerns regarding this > > > patch, can we move forward with the merge? or do > > > we need voting on this one? > > > > > > Thanks, > > > Jyothsna Konisa. > > > > > > > > > On Mon, Jun 19, 2023 at 4:00 PM Jyothsna Konisa > > > <jyothsna1...@gmail.com > > > <mailto:jyothsna1...@gmail.com>> wrote: > > > > > > 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 > > > <mailto: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 > > > <mailto:cli...@example.com>'; > > > > > > ( > https://urldefense.com/v3/__https://dev.mysql.com/doc/refman/8.0/en/create-user.html*create-user-tls__;Iw!!PbtH5S7Ebw!cDEDWVGjPSrF-8uo85vvzwyJNKT_LUJeFgNpMs_-8JzHZV7TVTU8XrYNZ2cFrT7RSQ8EyDjMD2-XpOdC$ > < > https://urldefense.com/v3/__https://dev.mysql.com/doc/refman/8.0/en/create-user.html*create-user-tls__;Iw!!PbtH5S7Ebw!bc-bxD5J_z84ErqBnLngRGkogZQQF2d5tQcORTek4SaE5S_LVkzIYlLIFY73R48icK6fAwtUBLyaE8NW0A$ > >) > > > > > > 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 > > > <mailto: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> > > > > <mailto: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> > > > > <mailto: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> > > > <mailto: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://urldefense.com/v3/__https://keybase.io/dchenbecker__;!!PbtH5S7Ebw!cDEDWVGjPSrF-8uo85vvzwyJNKT_LUJeFgNpMs_-8JzHZV7TVTU8XrYNZ2cFrT7RSQ8EyDjMD0yQ6GLo$ > > > < > https://urldefense.com/v3/__https://keybase.io/dchenbecker__;!!PbtH5S7Ebw!bc-bxD5J_z84ErqBnLngRGkogZQQF2d5tQcORTek4SaE5S_LVkzIYlLIFY73R48icK6fAwtUBLzc9mLgPA$ > > > > > > < > https://urldefense.com/v3/__https://keybase.io/dchenbecker__;!!PbtH5S7Ebw!cDEDWVGjPSrF-8uo85vvzwyJNKT_LUJeFgNpMs_-8JzHZV7TVTU8XrYNZ2cFrT7RSQ8EyDjMD0yQ6GLo$ > > > < > https://urldefense.com/v3/__https://keybase.io/dchenbecker__;!!PbtH5S7Ebw!bc-bxD5J_z84ErqBnLngRGkogZQQF2d5tQcORTek4SaE5S_LVkzIYlLIFY73R48icK6fAwtUBLzc9mLgPA$>>and > | > > > > | > > > > https://urldefense.com/v3/__https://pgp.mit.edu/pks/lookup?search=derek*40chen-becker.org__;JQ!!PbtH5S7Ebw!cDEDWVGjPSrF-8uo85vvzwyJNKT_LUJeFgNpMs_-8JzHZV7TVTU8XrYNZ2cFrT7RSQ8EyDjMD8al-xmr$ > < > https://urldefense.com/v3/__https://pgp.mit.edu/pks/lookup?search=derek*40chen-becker.org__;JQ!!PbtH5S7Ebw!bc-bxD5J_z84ErqBnLngRGkogZQQF2d5tQcORTek4SaE5S_LVkzIYlLIFY73R48icK6fAwtUBLzUrXA0Zg$ > > > > > > > > > < > https://urldefense.com/v3/__https://pgp.mit.edu/pks/lookup?search=derek*40chen-becker.org__;JQ!!PbtH5S7Ebw!cDEDWVGjPSrF-8uo85vvzwyJNKT_LUJeFgNpMs_-8JzHZV7TVTU8XrYNZ2cFrT7RSQ8EyDjMD8al-xmr$ > < > https://urldefense.com/v3/__https://pgp.mit.edu/pks/lookup?search=derek*40chen-becker.org__;JQ!!PbtH5S7Ebw!bc-bxD5J_z84ErqBnLngRGkogZQQF2d5tQcORTek4SaE5S_LVkzIYlLIFY73R48icK6fAwtUBLzUrXA0Zg$>> > | > > > > | Fngrprnt: EB8A 6480 F0A3 C8EB > > > C1E7 7F42 AFC5 AFEE 96E4 6ACC | > > > > > > > > > +---------------------------------------------------------------+ > > > > > > > > > >
