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