Hi all,
As extension to the N-man rule, I would like to propose a self-evolving
policy-based approval mechanism.
Policies
I am defining the following policies for illustration purpose. In practical
implementation, we can implement more complex policies.
Super User Add Policy: The number of approvals required to add another super
user
Super User Remove Policy: The number of approvals required to remove an
existing super user
User Role Assignment Policy: The number of approvals required to add a role
assignment to the user
User Role Removal Policy: The number of approvals required to remove a role
assignment from the user
Bootstrapping
When the administrator boots up Cassandra, he defines the set of super users
and super user approval policies.
In case of a development instance, the instance will be self-managed and there
will be only one super user. The policy for such instances can be like the
following:
superUsers: [A]
policies:
superUserAddPolicy: 1
superUserRemovePolicy: 2
userRoleAssignmentPolicy: 1
userRoleRemovelPolicy: 1
In case of a production instances, the policies should be strong enough to
prevent ad-hoc operations. Also, some good set of super users should be aware
of the changes. The policy will be something similar to the following:
superUsers: [A,B,C,D,E]
policies:
superUserAddPolicy: ALL
superUserRemovePolicy: ALL-1
userRoleAssignmentPolicy: MAJORITY
userRoleRemovelPolicy: ONE
The above policy mean the following:
1. To add another super user (let's say F), we need approval of all the
existing super users
2. To remove an existing super user (let's say E), we need approval of all
existing super users except one
3. To add a role assignment to an user, majority of the super users should
approve
4. To remove a role assignment from an user, approval of only one super user
is good enough
Let's assume we have user X and he requires database_reader role. This new role
assignment has to be proposed by one of the super users; let's assume A
proposes the new role assignment. Since he proposes, he implicitly approves the
same. According to the policy, we need two more approvals to reach majority. If
two more super users (say C & E) approve the user role assignment, the role
assignment becomes effective.
This shows the flexibility of policy-based approval flow.
Evolvability
Let's assume that for any change in policies, we need approval of all super
users.
The dev instance where the user A is the only super user needs to be upgraded
to a prod instance. This means, we have to evolve our policies to that of the
prod instance.
The initial policy can be like this:
superUsers: [A]
policies:
superUserAddPolicy: 1
superUserRemovePolicy: 2
userRoleAssignmentPolicy: 1
userRoleRemovelPolicy: 1
Now he can change the last three policies to ALL-1, MAJORITY and ONE
respectively. As he is the only one super user, no other users' approval is
required for policy change. After this change, the policy looks like:
superUsers: [A]
policies:
superUserAddPolicy: 1
superUserRemovePolicy: ALL-1
userRoleAssignmentPolicy: MAJORITY
userRoleRemovelPolicy: ONE
Now A can add other super users. He doesn't need any approval as the
superUserAddPolicy is ONE. After this change, the policy will look like:
superUsers: [A,B,C,D,E]
policies:
superUserAddPolicy: 1
superUserRemovePolicy: ALL-1
userRoleAssignmentPolicy: MAJORITY
userRoleRemovelPolicy: ONE
Now we need to make superUserAddPolicy to 'ALL'. For changes in policies, we
need approval of all super users. So, A can propose the policy change and B,C,D
& E can approve the policy change. Now the policy becomes same as the prod
policy that we described in previous section:
superUsers: [A,B,C,D,E]
policies:
superUserAddPolicy: ALL
superUserRemovePolicy: ALL-1
userRoleAssignmentPolicy: MAJORITY
userRoleRemovelPolicy: ONE
This shows the evolvability of the policy based approach.
With this approach, we can make sure the customers can fine tune the policy
that are required for their company's compliance policies and they can evolve
as the requirements change.
References:
The above mentioned approach is inspired by policies in Hyperledger Fabric:
https://hyperledger-fabric.readthedocs.io/en/release-2.2/policies/policies.html
Thanks,
Sathyanarayanan S
________________________________
From: Tibor Répási <tibor.rep...@anzix.org>
Sent: Wednesday, March 30, 2022 10:46 PM
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: Adding a security role to grant/revoke with no access to the data
itself
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.
>>>>>
>>>>>
>>>>
>>>>
