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 :-)
Reg
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 app
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
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 i
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
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 ne
> 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.valu
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 i
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 w
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
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 namin
… 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
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
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 p
>
> 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
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, Bereng
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
[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 t
>
>
> 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
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
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
22 matches
Mail list logo
