Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Benjamin Lerer]

Thank Erick for raising the discussion.
My apologies for not responding before. The original thread raised several
questions for me and I needed time to think about them.
One question is the Linkedin Company vs Group one. I must admit that it
makes sense but the whole story made me realize my lack of understanding of
how Linkedin works and wanted to explore that more deeply than I did before
creating the group.
Another thing that the thread made me realize is that there are several
people interested in being involved in C* marketing/Public Relations and
that we probably need to do the things in a more mature and open way.
Partick and I would like to organize a contributor meeting focused on
Apache Cassandra marketing to give a chance to everybody to join and
discuss how we could do things better if people are interested.
I feel that it would help us to evolve in this area

Le mer. 30 mars 2022 à 03:01, Paulo Motta  a
écrit :

> I was unpleasantly surprised to find out that Linkedin group posts are not
> visible outside of the group, which greatly reduces post visibility. I
> originally supported the group creation because I thought the posts would
> be visible outside the group but this doesn't seem to be the case.
>
> The only thing that bothers me about having a company page is that the
> project is not technically a company, but if this is not breaking any
> Linkedin ToS and there is precedence in other Apache projects I think it
> makes sense to create the company page to give more visibility to community
> posts.
>
> I just don't see much value in keeping the group if we decide to create
> the company page, since we may risk duplicating effort and attention. I
> don't think Linkedin is the place for technical discussions since we have
> other forums for that, I see it more as a marketing channel.
>
> Em ter., 29 de mar. de 2022 às 21:41, Erick Ramirez <
> erickramire...@apache.org> escreveu:
>
>> I wanted to bring this up again from Benjamin's original thread
>> . I
>> agree with Melissa and I really think there's a lot of value in creating a
>> company page on LinkedIn in addition to the "C* Community" group. There is
>> a bigger potential for us from a marketing perspective to promote Cassandra
>> to a wider audience with a company page. For what it's worth, Apache
>> Pulsar  already does
>> this. Off the top of my head, here are some notable points:
>>
>> LinkedIn company page:
>>
>>- ✅ users can "follow" the page and see posts in their feed
>>- ✅ users can @-tag Cassandra in their own posts
>>- ✅ reach a wider network on LinkedIn
>>- ✅ promote new contributors publicly
>>
>> LinkedIn group:
>>
>>- ✅ great for building a community
>>- ✅ deeper discussion on topics
>>- 👎 users need to join the group
>>- 👎 posts are only visible to members
>>
>> Is there an appetite from the project to pursue this? Cheers!
>>
>> On Thu, 10 Mar 2022 at 06:06, Melissa Logan 
>> wrote:
>>
>>> I agree there should be an official LinkedIn page for the project hosted
>>> by the community. It's an easy way for people to stay current.
>>>
>>> If the goal of the new LinkedIn page is to publicly and broadly share
>>> what the Cassandra community is doing, one solution would be to change the
>>> new Cassandra page from a "group" page to a "company" page.
>>>
>>> Company pages show all posts publicly by default, and admins don't have
>>> to manage requests to join. Anyone can "follow" the page and see/share the
>>> posts -- while only allowing community admins to publish. This would also
>>> require less care and feeding from community admins. (What I don't know if
>>> it's easy to "convert" a group page to company or if it requires starting
>>> from scratch.)
>>>
>>> Then, admins of the existing "group" page could repost any/all items
>>> from the community page to keep people informed.
>>>
>>> This solution could help both pages achieve their goals of spreading the
>>> word about Cassandra.
>>>
>>> --
>>> Melissa Logan (she/her)
>>> Principal, Constantia.io
>>> LinkedIn  | Twitter
>>> 
>>>
>>

Adding a security role to grant/revoke with no access to the data itself

[Berenguer Blasi]

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 createdhttps://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.

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Benjamin Lerer]

>
>
> I think we can get rid of this by extending CassandraDaemon, just need to
> add a few hooks to mock out gossip/internode/client (for cases where the
> mocks are desired), and when mocks are not desired just run the real logic.
>
> Too many times I have had to make the 2 more in-line, and this is hard to
> maintain… we should fix this and feel this is 100% fixable
>

Thanks for the explanation David. Outside of this area is there some other
difference in the coverage of the tests. Is serialization fully covered?
I would like to be sure that we will not miss anything by using in-jvm
dtests instead of python dtests.


Le mer. 30 mars 2022 à 02:15, bened...@apache.org  a
écrit :

> > a well-defined path to reduce/eliminate code duplication and basic
> documentation for newcomers to get up to speed with writing in-jvm dtests
> and extending the framework
>
>
>
> Are python tests much better here? If not, I do not see why these should
> be blockers for their deprecation.
>
>
>
> Perfect feature parity also seems unnecessary - unless a missing feature
> is an active impediment. But as far as I know every missing feature is
> actively under development and can be expected very soon.
>
>
>
> Let’s get this decision over and done with.
>
>
>
>
>
> *From: *Paulo Motta 
> *Date: *Wednesday, 30 March 2022 at 00:46
> *To: *Cassandra DEV 
> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>
> I support deprecating python dtests, as long as in-jvm dtests have feature
> parity with python dtests, a well-defined path to reduce/eliminate code
> duplication and basic documentation for newcomers to get up to speed with
> writing in-jvm dtests and extending the framework.
>
>
>
> Em ter., 29 de mar. de 2022 às 20:09, bened...@apache.org <
> bened...@apache.org> escreveu:
>
> It often does not work. I can attest to many wasted weeks, on some
> environments never getting them to work.
>
>
>
> They happen to work right now for me, though.
>
>
>
> I think the learning curve thing is a bit of a distraction, personally. I
> have always found python dtests hard to work with, both developing against
> and running, so their learning curve for me is going on 10 years. Some folk
> may be more comfortable with python dtests due to their familiarity with
> python, ccm or other tooling, but that is a different matter.
>
>
>
> Looking at git, most contributors to python dtests are contributors to
> in-jvm dtests, and the latter have received 20x as many net code
> contributions over the past year.
>
>
>
> I think it’s quite justified to just say in-jvm dtests are simply better
> to work with, and already better and more widely used despite their youth,
> whatever their remaining teething problems.
>
>
>
> I vote we immediately discontinue python dtest development, and
> discontinue running python dtests pre-commit, retaining them for releases
> only. This will provide the necessary impetus to polish off any last
> remaining gaps, without reducing coverage.
>
>
>
> *From: *Brandon Williams 
> *Date: *Tuesday, 29 March 2022 at 23:42
> *To: *dev 
> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>
> > In fact there is a high learning curve to setup cassandra-dtest
> environment
>
> I think this is fairly well documented:
> https://github.com/apache/cassandra-dtest/blob/trunk/README.md
>
> On Tue, Mar 29, 2022 at 5:27 PM Paulo Motta 
> wrote:
> >
> > > I am curious about this comment.  When I first joined I learned
> jvm-dtest within an hour and started walking Repair code in a debugger (and
> this was way before the improvements that let us do things like nodetool)…
> python dtest took weeks to get working correctly (still having issues with
> the MBean library we use… so have to comment out error handling to get some
> tests to pass)….
> >
> > Thanks for sharing your perspective. In fact there is a high learning
> curve to setup cassandra-dtest environment, but once it's working it's
> pretty straightforward to test any existing or new functionality.
> >
> > I think with in-jvm dtests you don't have the hassle of setting up a
> different environment and this is a great motivator to standardize on this
> solution. The main difficulty I had was testing features not supported by
> the framework, which require you to extend the framework. I don't recall
> having to extend ccm/cassandra-dtest many times when working on new
> features.
> >
> > Perhaps this has improved recently and we no longer need to worry about
> extending the framework or duplicating code when testing new functionality.
> >
> > Em ter., 29 de mar. de 2022 às 15:12, Ekaterina Dimitrova <
> e.dimitr...@gmail.com> escreveu:
> >>
> >> One thing that we can add to docs is for people how to update the
> in-jvm framework and test their patches before asking for in-jvm api
> release. The assumption is those won’t be many updates needed I think, but
> it is good to be documented.
> >>
> >> On Tue, 29 Mar 2022 at 13:51, David Capwell  wrote:
> >

Call for Presentations now open, ApacheCon North America 2022

[Rich Bowen]

[You are receiving this because you are subscribed to one or more user
or dev mailing list of an Apache Software Foundation project.]

ApacheCon draws participants at all levels to explore “Tomorrow’s
Technology Today” across 300+ Apache projects and their diverse
communities. ApacheCon showcases the latest developments in ubiquitous
Apache projects and emerging innovations through hands-on sessions,
keynotes, real-world case studies, trainings, hackathons, community
events, and more.

The Apache Software Foundation will be holding ApacheCon North America
2022 at the New Orleans Sheration, October 3rd through 6th, 2022. The
Call for Presentations is now open, and will close at 00:01 UTC on May
23rd, 2022.

We are accepting presentation proposals for any topic that is related
to the Apache mission of producing free software for the public good.
This includes, but is not limited to:

Community
Big Data
Search
IoT
Cloud
Fintech
Pulsar
Tomcat

You can submit your session proposals starting today at
https://cfp.apachecon.com/

Rich Bowen, on behalf of the ApacheCon Planners
apachecon.com
@apachecon

Re: [DISCUSS] Should we deprecate / freeze python dtests

[Josh McKenzie]

How are we gauging what our python dtest coverage is vs. in-jvm dtest coverage?

On Wed, Mar 30, 2022, at 4:51 AM, Benjamin Lerer wrote:
>> 
>> 
>> I think we can get rid of this by extending CassandraDaemon, just need to 
>> add a few hooks to mock out gossip/internode/client (for cases where the 
>> mocks are desired), and when mocks are not desired just run the real logic.
>> 
>> Too many times I have had to make the 2 more in-line, and this is hard to 
>> maintain… we should fix this and feel this is 100% fixable
> 
> Thanks for the explanation David. Outside of this area is there some other 
> difference in the coverage of the tests. Is serialization fully covered?
> I would like to be sure that we will not miss anything by using in-jvm dtests 
> instead of python dtests.
> 
> 
> Le mer. 30 mars 2022 à 02:15, bened...@apache.org  a 
> écrit :
>> > a well-defined path to reduce/eliminate code duplication and basic 
>> > documentation for newcomers to get up to speed with writing in-jvm dtests 
>> > and extending the framework
>> __ __
>> Are python tests much better here? If not, I do not see why these should be 
>> blockers for their deprecation.
>> __ __
>> Perfect feature parity also seems unnecessary - unless a missing feature is 
>> an active impediment. But as far as I know every missing feature is actively 
>> under development and can be expected very soon. 
>> __ __
>> Let’s get this decision over and done with.
>> __ __
>> __ __
>> *From: *Paulo Motta 
>> *Date: *Wednesday, 30 March 2022 at 00:46
>> *To: *Cassandra DEV 
>> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>> I support deprecating python dtests, as long as in-jvm dtests have feature 
>> parity with python dtests, a well-defined path to reduce/eliminate code 
>> duplication and basic documentation for newcomers to get up to speed with 
>> writing in-jvm dtests and extending the framework.
>> __ __
>> Em ter., 29 de mar. de 2022 às 20:09, bened...@apache.org 
>>  escreveu:
>>> It often does not work. I can attest to many wasted weeks, on some 
>>> environments never getting them to work.
>>>  
>>> They happen to work right now for me, though.
>>>  
>>> I think the learning curve thing is a bit of a distraction, personally. I 
>>> have always found python dtests hard to work with, both developing against 
>>> and running, so their learning curve for me is going on 10 years. Some folk 
>>> may be more comfortable with python dtests due to their familiarity with 
>>> python, ccm or other tooling, but that is a different matter.
>>>  
>>> Looking at git, most contributors to python dtests are contributors to 
>>> in-jvm dtests, and the latter have received 20x as many net code 
>>> contributions over the past year. 
>>>  
>>> I think it’s quite justified to just say in-jvm dtests are simply better to 
>>> work with, and already better and more widely used despite their youth, 
>>> whatever their remaining teething problems.
>>>  
>>> I vote we immediately discontinue python dtest development, and discontinue 
>>> running python dtests pre-commit, retaining them for releases only. This 
>>> will provide the necessary impetus to polish off any last remaining gaps, 
>>> without reducing coverage.
>>>  
>>> *From: *Brandon Williams 
>>> *Date: *Tuesday, 29 March 2022 at 23:42
>>> *To: *dev 
>>> *Subject: *Re: [DISCUSS] Should we deprecate / freeze python dtests
>>> > In fact there is a high learning curve to setup cassandra-dtest 
>>> > environment
>>> 
>>> I think this is fairly well documented:
>>> https://github.com/apache/cassandra-dtest/blob/trunk/README.md
>>> 
>>> On Tue, Mar 29, 2022 at 5:27 PM Paulo Motta  
>>> wrote:
>>> >
>>> > > I am curious about this comment.  When I first joined I learned 
>>> > > jvm-dtest within an hour and started walking Repair code in a debugger 
>>> > > (and this was way before the improvements that let us do things like 
>>> > > nodetool)… python dtest took weeks to get working correctly (still 
>>> > > having issues with the MBean library we use… so have to comment out 
>>> > > error handling to get some tests to pass)….
>>> >
>>> > Thanks for sharing your perspective. In fact there is a high learning 
>>> > curve to setup cassandra-dtest environment, but once it's working it's 
>>> > pretty straightforward to test any existing or new functionality.
>>> >
>>> > I think with in-jvm dtests you don't have the hassle of setting up a 
>>> > different environment and this is a great motivator to standardize on 
>>> > this solution. The main difficulty I had was testing features not 
>>> > supported by the framework, which require you to extend the framework. I 
>>> > don't recall having to extend ccm/cassandra-dtest many times when working 
>>> > on new features.
>>> >
>>> > Perhaps this has improved recently and we no longer need to worry about 
>>> > extending the framework or duplicating code when testin

Re: Adding a security role to grant/revoke with no access to the data itself

[Tibor Répási]

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

Re: Adding a security role to grant/revoke with no access to the data itself

[Benjamin Lerer]

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

Re: Adding a security role to grant/revoke with no access to the data itself

[J. D. Jordan]

I think this is an important step in the authorization model of C*.  It brings 
parity with many other databases.

While further restrictions might make such restrictions less likely to be 
worked around, in most places I have heard of using audit logging of user 
management statements is how you prevent that.  With this type of restriction + 
audit logs of all user management you can show that an admin has not accessed 
data through their admin account.

The ability to have an even more restrictive mode would be a nice future add on.

-Jeremiah

> On Mar 30, 2022, at 8:13 AM, Benjamin Lerer  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  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  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.
>> 

Re: Adding a security role to grant/revoke with no access to the data itself

[Berenguer Blasi]

Hi thanks for the reply,

IIUC If you look in the ticket an evil security_admin would be under a 
'RESTRICT' for that keyspace i.e. That would take precedence over GRANTs 
so he couldn't self-auth to see that data. But having said that yes, if 
enough people collude... but then the audit logs will still reflect that.


On 30/3/22 15:22, J. D. Jordan wrote:
I think this is an important step in the authorization model of C*. 
 It brings parity with many other databases.


While further restrictions might make such restrictions less likely to 
be worked around, in most places I have heard of using audit logging 
of user management statements is how you prevent that.  With this type 
of restriction + audit logs of all user management you can show that 
an admin has not accessed data through their admin account.


The ability to have an even more restrictive mode would be a nice 
future add on.


-Jeremiah


On Mar 30, 2022, at 8:13 AM, Benjamin Lerer  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  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
 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 createdhttps://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.

Re: Adding a security role to grant/revoke with no access to the data itself

[Tibor Répási]

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

Re: Adding a security role to grant/revoke with no access to the data itself

[Tibor Répási]

… 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  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 > > 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 > > 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 >> > 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.
>> 
> 

Re: Adding a security role to grant/revoke with no access to the data itself

[Stefan Miklosovic]

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

Re: Adding a security role to grant/revoke with no access to the data itself

[Stefan Miklosovic]

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

Re: Adding a security role to grant/revoke with no access to the data itself

[J. D. Jordan]

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

Re: Adding a security role to grant/revoke with no access to the data itself

[Berenguer Blasi]

Hi,

I also think these are all valuable ideas. But iiuc I think there's 
nothing in 17501 incompatible to them. Also it seems to me like a 
sensible self-contained first step improvement in the right direction.


Regards

On 30/3/22 17:06, J. D. Jordan 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 
 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
 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  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  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  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  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  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.

Re: [DISCUSS] Should we deprecate / freeze python dtests

[David Capwell]

> Outside of this area is there some other difference in the coverage of the 
> tests. Is serialization fully covered?
> I would like to be sure that we will not miss anything by using in-jvm dtests 
> instead of python dtests.

So, if you do Cluster.build(num).withConfig(c -> 
c.with(Features.values())).start(), this will run the full Cassandra daemon, so 
the main difference will be with: startup (Instance vs CassandraDaemon), and 
JMX (direct method call rather than JMX).

The Features lets you enable different subsystems, so adding every feature will 
get you in-sync mostly.

Now, if you don’t define any Features, then the following are mocked/disabled 
out: Gossip, Internode, Client (disabled)

Gossip: gossiper isn’t running and the gossip state is defined by the Cluster, 
the state does not change for the life of the test (there are utility methods 
to mutate gossip state).  Since most tests do not care about gossip state 
changes, this is fine for majority of tests, when not just enable gossip with 
Feature.GOSSIP
NETWORK: messages do not go over network by default, but will be serialized; 
this logic does not match networking though the serializer is the same.  If you 
are actually testing internode messaging, enable it with Feature.NETWORK
NATIVE_PROTOCOL: by default CQL/thrift protocol are disabled, to enable do 
Feature.NATIVE_PROTOCOL (by default it acts as if 
-Dcassandra.start_native_transport=false)



> On Mar 30, 2022, at 1:51 AM, Benjamin Lerer  wrote:
> 
> 
> I think we can get rid of this by extending CassandraDaemon, just need to add 
> a few hooks to mock out gossip/internode/client (for cases where the mocks 
> are desired), and when mocks are not desired just run the real logic.
> 
> Too many times I have had to make the 2 more in-line, and this is hard to 
> maintain… we should fix this and feel this is 100% fixable
> 
> Thanks for the explanation David. Outside of this area is there some other 
> difference in the coverage of the tests. Is serialization fully covered?
> I would like to be sure that we will not miss anything by using in-jvm dtests 
> instead of python dtests.
> 
> 
> Le mer. 30 mars 2022 à 02:15, bened...@apache.org 
>   > a écrit :
> > a well-defined path to reduce/eliminate code duplication and basic 
> > documentation for newcomers to get up to speed with writing in-jvm dtests 
> > and extending the framework
> 
>  
> 
> Are python tests much better here? If not, I do not see why these should be 
> blockers for their deprecation.
> 
>  
> 
> Perfect feature parity also seems unnecessary - unless a missing feature is 
> an active impediment. But as far as I know every missing feature is actively 
> under development and can be expected very soon.
> 
>  
> 
> Let’s get this decision over and done with.
> 
>  
> 
>  
> 
> From: Paulo Motta mailto:pauloricard...@gmail.com>>
> Date: Wednesday, 30 March 2022 at 00:46
> To: Cassandra DEV mailto:dev@cassandra.apache.org>>
> Subject: Re: [DISCUSS] Should we deprecate / freeze python dtests
> 
> I support deprecating python dtests, as long as in-jvm dtests have feature 
> parity with python dtests, a well-defined path to reduce/eliminate code 
> duplication and basic documentation for newcomers to get up to speed with 
> writing in-jvm dtests and extending the framework.
> 
>  
> 
> Em ter., 29 de mar. de 2022 às 20:09, bened...@apache.org 
>   > escreveu:
> 
> It often does not work. I can attest to many wasted weeks, on some 
> environments never getting them to work.
> 
>  
> 
> They happen to work right now for me, though.
> 
>  
> 
> I think the learning curve thing is a bit of a distraction, personally. I 
> have always found python dtests hard to work with, both developing against 
> and running, so their learning curve for me is going on 10 years. Some folk 
> may be more comfortable with python dtests due to their familiarity with 
> python, ccm or other tooling, but that is a different matter.
> 
>  
> 
> Looking at git, most contributors to python dtests are contributors to in-jvm 
> dtests, and the latter have received 20x as many net code contributions over 
> the past year.
> 
>  
> 
> I think it’s quite justified to just say in-jvm dtests are simply better to 
> work with, and already better and more widely used despite their youth, 
> whatever their remaining teething problems.
> 
>  
> 
> I vote we immediately discontinue python dtest development, and discontinue 
> running python dtests pre-commit, retaining them for releases only. This will 
> provide the necessary impetus to polish off any last remaining gaps, without 
> reducing coverage.
> 
>  
> 
> From: Brandon Williams mailto:dri...@gmail.com>>
> Date: Tuesday, 29 March 2022 at 23:42
> To: dev mailto:dev@cassandra.apache.org>>
> Subject: Re: [DISCUSS] Should we deprecate / freeze python dtests
> 
> > In fact there is a high learning curv

Re: Adding a security role to grant/revoke with no access to the data itself

[Tibor Répási]

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

Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Eric Evans]

On Wed, Mar 30, 2022 at 3:35 AM Benjamin Lerer  wrote:

> Thank Erick for raising the discussion.
> My apologies for not responding before. The original thread raised several
> questions for me and I needed time to think about them.
> One question is the Linkedin Company vs Group one. I must admit that it
> makes sense but the whole story made me realize my lack of understanding of
> how Linkedin works and wanted to explore that more deeply than I did before
> creating the group.
> Another thing that the thread made me realize is that there are several
> people interested in being involved in C* marketing/Public Relations and
> that we probably need to do the things in a more mature and open way.
> Partick and I would like to organize a contributor meeting focused on
> Apache Cassandra marketing to give a chance to everybody to join and
> discuss how we could do things better if people are interested.
> I feel that it would help us to evolve in this area
>

Please bear in mind that contributor meetings like these are exclusive by
nature; There is no time suitable for every timezone, not everyone has
equal connectivity, and those who don't natively speak English might
struggle to keep pace in real time (to name just a few reasons).  This is
probably why the ASF is so adamant about the use of email.

--
Eric Evans
eev...@apache.org

Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Patrick McFadin]

I agree that is a problem. In the past, I have tried to make these as
inclusive as possible by offering multiple time zones, recording every
meeting, and posting it on YouTube with an email sent to dev@. What we
can't substitute in a mailing list is the energy that comes from
brainstorming, which is kind of a feature of people interested in this sort
of thing for the project. Just like meeting once or twice a year at
ApacheCon. It's part of an overall package of community vibrancy and none
of it is exclusive.

One thing that occurred to me is that everything is getting dumped on dev@.
Is it time for a marketing@ list for Cassandra?

Patrick

On Wed, Mar 30, 2022 at 12:00 PM Eric Evans  wrote:

>
>
> On Wed, Mar 30, 2022 at 3:35 AM Benjamin Lerer  wrote:
>
>> Thank Erick for raising the discussion.
>> My apologies for not responding before. The original thread raised
>> several questions for me and I needed time to think about them.
>> One question is the Linkedin Company vs Group one. I must admit that it
>> makes sense but the whole story made me realize my lack of understanding of
>> how Linkedin works and wanted to explore that more deeply than I did before
>> creating the group.
>> Another thing that the thread made me realize is that there are several
>> people interested in being involved in C* marketing/Public Relations and
>> that we probably need to do the things in a more mature and open way.
>> Partick and I would like to organize a contributor meeting focused on
>> Apache Cassandra marketing to give a chance to everybody to join and
>> discuss how we could do things better if people are interested.
>> I feel that it would help us to evolve in this area
>>
>
> Please bear in mind that contributor meetings like these are exclusive by
> nature; There is no time suitable for every timezone, not everyone has
> equal connectivity, and those who don't natively speak English might
> struggle to keep pace in real time (to name just a few reasons).  This is
> probably why the ASF is so adamant about the use of email.
>
> --
> Eric Evans
> eev...@apache.org
>

Re: [DISCUSS] List Apache Cassandra as a "company" on LinkedIn

[Patrick McFadin]

Oh and +1 to the idea of making Apache Cassandra a company on LinkedIn.
Same energy as the Twitter handle. Outgoing updates from the project.

On Wed, Mar 30, 2022 at 2:41 PM Patrick McFadin  wrote:

> I agree that is a problem. In the past, I have tried to make these as
> inclusive as possible by offering multiple time zones, recording every
> meeting, and posting it on YouTube with an email sent to dev@. What we
> can't substitute in a mailing list is the energy that comes from
> brainstorming, which is kind of a feature of people interested in this sort
> of thing for the project. Just like meeting once or twice a year at
> ApacheCon. It's part of an overall package of community vibrancy and none
> of it is exclusive.
>
> One thing that occurred to me is that everything is getting dumped on dev@.
> Is it time for a marketing@ list for Cassandra?
>
> Patrick
>
> On Wed, Mar 30, 2022 at 12:00 PM Eric Evans  wrote:
>
>>
>>
>> On Wed, Mar 30, 2022 at 3:35 AM Benjamin Lerer  wrote:
>>
>>> Thank Erick for raising the discussion.
>>> My apologies for not responding before. The original thread raised
>>> several questions for me and I needed time to think about them.
>>> One question is the Linkedin Company vs Group one. I must admit that it
>>> makes sense but the whole story made me realize my lack of understanding of
>>> how Linkedin works and wanted to explore that more deeply than I did before
>>> creating the group.
>>> Another thing that the thread made me realize is that there are several
>>> people interested in being involved in C* marketing/Public Relations and
>>> that we probably need to do the things in a more mature and open way.
>>> Partick and I would like to organize a contributor meeting focused on
>>> Apache Cassandra marketing to give a chance to everybody to join and
>>> discuss how we could do things better if people are interested.
>>> I feel that it would help us to evolve in this area
>>>
>>
>> Please bear in mind that contributor meetings like these are exclusive by
>> nature; There is no time suitable for every timezone, not everyone has
>> equal connectivity, and those who don't natively speak English might
>> struggle to keep pace in real time (to name just a few reasons).  This is
>> probably why the ASF is so adamant about the use of email.
>>
>> --
>> Eric Evans
>> eev...@apache.org
>>
>

Re: Adding a security role to grant/revoke with no access to the data itself

[sathyanarayanan s]

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 
Sent: Wednesday, March 30, 2022 10:46 PM
To: 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  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 

Re: Adding a security role to grant/revoke with no access to the data itself

[Berenguer Blasi]

Hi All,


thanks for the input and ideas. If I am reading these correctly, it 
seems to me 17501 is a first step in the direction we want that we 
should also be able to extend easily. So unless sbdy objects and I 
didn't miss anything I would like to start working on it early next week :-)



Regards


On 31/3/22 4:58, sathyanarayanan s wrote:

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 
*Sent:*