I think both ideas are worth the discussion. I’ve opened CASSANDRA-17502 to summarise the idea of the-man rule.
> On 30. Mar 2022, at 17:06, J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > > 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. >>>>> >>>>> >>>> >>>>
