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

Reply via email to