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/[email protected]';
(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 <[email protected]> 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 <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Sounds great, thanks for the clarification!
> >
> > Cheers,
> >
> > Derek
> >
> > On Sat, Jun 3, 2023 at 12:48 AM Dinesh Joshi <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >> On Jun 2, 2023, at 9:06 PM, Derek Chen-Becker
> >> <[email protected] <mailto:[email protected]>> 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 |
> > +---------------------------------------------------------------+
> >
>
>
