You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Christopher Bradford <br...@gmail.com> on 2023/07/06 20:54:10 UTC
Re: CASSANDRA-18554 - mTLS based client and internode authenticators
Looping back to the discussion around keystore usage and shared vs
individual identity. I understand the approach of having a single identity
shared by all nodes in the cluster. Including the entire response here, but
want to focus on the first line.
*The reason we use the keystore is that the node extracts its own identity
> and expects other nodes in the cluster to share the same identity.* This
> default behavior makes it easy to avoid configuring individual identities
> of nodes in the cluster. It's critical to recognize that if we had a
> separate identity for each node in the cluster, then we would need to
> update all nodes in the cluster when a new node is added or removed. This
> way all nodes in the cluster can have a shared identity while
> simultaneously preventing unnecessary operational pain of adding and
> removing identities each time a node is added or removed from the cluster.
(emphasis mine)
It is surprising to me that we load the identity from the keystore vs
explicitly setting an expected value in cassandra.yaml. I get that an error
is thrown if the identity doesn't match those of other nodes in the
cluster, but does it make sense to prevent startup should the value in the
keystore deviate from a (currently nonexistent) value in cassandra.yaml?
It feels like there is a parallel to how we set the cluster name in
cassandra.yaml even though the value is also present within our local
sstables and leads to startup errors should they differ.
Christopher Bradford
On Fri, Jun 30, 2023 at 4:09 PM Jeremiah Jordan <je...@datastax.com>
wrote:
> 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. jeremiah@datastax.com
> w. www.datastax.com
>
>
>
> On Jun 30, 2023 at 1:35:41 PM, Dinesh Joshi <dj...@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.yuki@gmail.com
>>
>> <ma...@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.yuki@gmail.com
>>
>> > <ma...@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
>>
>> > <jyothsna1503@gmail.com <ma...@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
>>
>> > <jyothsna1503@gmail.com <ma...@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.yuki@gmail.com <ma...@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
>>
>> > <jyothsna1503@gmail.com
>>
>> > <ma...@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
>>
>> > <jyothsna1503@gmail.com
>>
>> > <ma...@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.yuki@gmail.com
>>
>> > <ma...@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=client@example.com
>>
>> > <ma...@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 <djoshi@apache.org
>>
>> > <ma...@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 <derek@chen-becker.org
>>
>> > <ma...@chen-becker.org>
>>
>> > > <mailto:derek@chen-becker.org
>>
>> > <ma...@chen-becker.org>>> wrote:
>>
>> > >
>>
>> > > Sounds great, thanks for the
>>
>> > clarification!
>>
>> > >
>>
>> > > Cheers,
>>
>> > >
>>
>> > > Derek
>>
>> > >
>>
>> > > On Sat, Jun 3, 2023 at 12:48 AM
>>
>> > Dinesh Joshi <djoshi@apache.org
>>
>> > <ma...@apache.org>
>>
>> > > <mailto:djoshi@apache.org
>>
>> > <ma...@apache.org>>> wrote:
>>
>> > >
>>
>> > >> On Jun 2, 2023, at 9:06 PM,
>>
>> > Derek Chen-Becker
>>
>> > >> <derek@chen-becker.org
>>
>> > <ma...@chen-becker.org>
>>
>> > <mailto:derek@chen-becker.org
>>
>> > <ma...@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 |
>>
>> > >
>>
>> >
>> +---------------------------------------------------------------+
>>
>> > >
>>
>> >
>>
>>
>>
Re: CASSANDRA-18554 - mTLS based client and internode authenticators
Posted by Dinesh Joshi <dj...@apache.org>.
> It is surprising to me that we load the identity from the keystore vs explicitly setting an expected value in cassandra.yaml. I get that an error is thrown if the identity doesn't match those of other nodes in the cluster, but does it make sense to prevent startup should the value in the keystore deviate from a (currently nonexistent) value in cassandra.yaml?
We can make it optionally configurable. The concern about adding identities in a yaml is that it generally requires a bounce for Cassandra to pick up new values.
> It feels like there is a parallel to how we set the cluster name in cassandra.yaml even though the value is also present within our local sstables and leads to startup errors should they differ.
I can see the parallels here. Thanks for the feedback.
Dinesh