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> 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>
> 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>
>> 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' 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>
>>> 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>
>>>> 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> 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>
>>>>>> 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 |
>>>>>>>> >
>>>>>>>> +---------------------------------------------------------------+
>>>>>>>> >
>>>>>>>>
>>>>>>>>
