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