I think these are very interesting ideas for another new feature. Would one of you like to write it up as a JIRA and start a new thread to discuss details? I think it would be good to keep this thread about the simpler proposal from CASSANDRA-17501 unless you all are against implementing that without the new abilities you are proposing? This “requires N grants” idea seems to me to be orthogonal to the original ticket.
> On Mar 30, 2022, at 10:00 AM, Stefan Miklosovic > <stefan.mikloso...@instaclustr.com> wrote: > > btw there is also an opposite problem, you HAVE TO have two guys (out > of two) to grant access. What if one of them is not available because > he went on holiday? So it might be wise to say "if three out of five > admins grants access that is enough", how would you implement it? > >> On Wed, 30 Mar 2022 at 16:56, Stefan Miklosovic >> <stefan.mikloso...@instaclustr.com> wrote: >> >> Why not N guys instead of two? Where does this stop? "2" seems to be >> an arbitrary number. This starts to remind me of Shamir's shared >> secrets. >> >> https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing >> >>> On Wed, 30 Mar 2022 at 16:36, Tibor Répási <tibor.rep...@anzix.org> wrote: >>> >>> … TWO_MAN_RULE could probably be poor naming and a boolean option not >>> flexible enough, let’s change that to an integer option like GRANTORS >>> defaulting 1 and could be any higher defining the number of grantors needed >>> for the role to become active. >>> >>>> On 30. Mar 2022, at 16:11, Tibor Répási <tibor.rep...@anzix.org> wrote: >>> >>> Having two-man rules in place for authorizing access to highly sensitive >>> data is not uncommon. I think about something like: >>> >>> As superuser: >>> >>> CREATE KEYSPACE patientdata …; >>> >>> CREATE ROLE patientdata_access WITH TWO_MAN_RULE=true; >>> >>> GRANT SELECT, MODIFY ON patientdata TO patientdata_access; >>> >>> CREATE ROLE security_admin; >>> GRANT AUTHORIZE patientdata_access TO security_admin; >>> >>> GRANT security_admin TO admin_guy1; >>> >>> GRANT security_admin TO admin_guy2; >>> >>> As admin_guy1: >>> >>> GRANT patientdata_access TO doctor_house; >>> >>> at this point doctor_house doesn’t have access to patientdata, it needs >>> admin_guy2 to: >>> >>> GRANT patientdata_access TO doctor_house; >>> >>> >>> >>> >>>> On 30. Mar 2022, at 15:13, Benjamin Lerer <ble...@apache.org> wrote: >>> >>>> What would prevent the security_admin from self-authorizing himself? >>> >>> >>> It is a valid point. :-) The idea is to have some mechanisms in place to >>> prevent that kind of behavior. >>> Of course people might still be able to collaborate to get access to some >>> data but a single person should not be able to do that all by himself. >>> >>> >>> Le mer. 30 mars 2022 à 14:52, Tibor Répási <tibor.rep...@anzix.org> a écrit >>> : >>>> >>>> I like the idea of separation of duties. But, wouldn’t be a security_admin >>>> role not just a select and modify permission on system_auth? What would >>>> prevent the security_admin from self-authorizing himself? >>>> >>>> Would it be possible to add some sort of two-man rule? >>>> >>>> On 30. Mar 2022, at 10:44, Berenguer Blasi <berenguerbl...@gmail.com> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> I would like to propose to add support for a sort of a security role that >>>> can grant/revoke >>>> permissions to a user to a resource (KS, table,...) but _not_ access the >>>> data in that resource itself. Data may be sensitive, >>>> have legal constrains, etc but this separation of duties should enable >>>> that. Think of a hospital where >>>> IT can grant/revoke permissions to doctors but IT should _not_ have access >>>> to the data itself. >>>> >>>> I have created https://issues.apache.org/jira/browse/CASSANDRA-17501 with >>>> more details. If anybody has >>>> any concerns or questions with this functionality I will be happy to >>>> discuss them. >>>> >>>> Thx in advance. >>>> >>>> >>> >>>
