[DISCUSS] guardail for global schema modifcations - CASSANDRA-19556 in the context of CASSANDRA-17495

[Štefan Miklošovič <st...@gmail.com>]

Hi list,

there is a question in CASSANDRA-19556 we would like to have more feedback
on in order to move forward.

CASSANDRA-19556 wants to introduce two guardrails. One for forbidding /
allowing DCL statements - (Authentication|Authorization)Statement - and
another one
for DDL statements (all schema modifications).

However, there is already a guardrail implemented by CASSANDRA-17495 which
prevents only modifications of schema on a table level so CASSANDRA-19556
might be viewed as a superset of CASSANDRA-17495.

I am not sure why we stopped with tables only in CASSANDRA-17495, this
might be extended to keyspaces too, any schema modification really. I think
we have three options here:

1) drop CASSANDRA-17495 and implement CASSANDRA-19556 which would cover
_all_ schema modifications, not just table-related ones
2) keep CASSANDRA-17495 and implement CASSANDRA-19556 as is currently
proposed - that means that we would be able to forbid all schema
modifications by CASSANDRA-19556 but once schema modifications are allowed,
we might further forbid table modifications as implemented by
CASSANDRA-17495.
3) keep CASSANDRA-17495 but change the implementation of CASSANDRA-19556 in
such a way that it would be more granular. What I mean by the granularity
is that we would have separate guardrail for keyspace, for example.

2) is the least impactful approach but what I do not like is that,
basically, one guardrail (CASSANDRA-19556) would shadow CASSANDRA-17495.
For example, if the first one is disabled but the second one is enabled, we
can modify keyspaces but we can not modify tables. When the first one is
enabled, we can not modify tables even 17495 is not disabled which I find
counterintuitive.

The pros of 3) would be that it would be more granular, indeed, but, is
that even necessary? There are a lot of ddl statements, creation of
triggers, views, indices, functions, aggregates ... How are we going to
categorize it? Do we want to have a guardrail per logical schema component?
Is that not an overkill? Can you come up with a scenario when an operator
wants to disable keyspace modifications but they would enable table
modifications? Or disabling just index, materialized view or function
creations / modifications but e.g keyspace modifications would be possible?
Is it not easier to have one guardrail for all schema modifications?

Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1),
I think that the option 1) is still viable - we would drop CASSANDRA-17495
and we would have CASSANDRA-19556 instead of that which would act as a
global on/off on all schema modifications however given that we go into
beta2 I am not sure if it is not just too late.

Thank you for your opinions in advance.

Regards

Re: [DISCUSS] guardail for global schema modifcations - CASSANDRA-19556 in the context of CASSANDRA-17495

[Josh McKenzie <jm...@apache.org>]

> Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1), I think that the option 1) is still viable - we would drop CASSANDRA-17495 and we would have CASSANDRA-19556 instead of that which would act as a global on/off on all schema modifications however given that we go into beta2 I am not sure if it is not just too late.
I think this is the best solution for our end-users long term excepting how close we are to a 5.0 GA. That said, guardrails aren't exactly super invasive destabilizing new features, so if you could get this patch in before we GA'd, I'd personally support making an exception for it.

We discussed a bit on the ticket; I fall in the ambivalent space of "I like modularity, except for when it's unnecessary complexity for a use-case or flexibility that users don't need", and not being sure whether operators would need different guardrails for functionality. Especially given security and roles.

On Mon, May 6, 2024, at 7:51 AM, Štefan Miklošovič wrote:
> Hi list,
> 
> there is a question in CASSANDRA-19556 we would like to have more feedback on in order to move forward.
> 
> CASSANDRA-19556 wants to introduce two guardrails. One for forbidding / allowing DCL statements - (Authentication|Authorization)Statement - and another one 
> for DDL statements (all schema modifications).
> 
> However, there is already a guardrail implemented by CASSANDRA-17495 which prevents only modifications of schema on a table level so CASSANDRA-19556 might be viewed as a superset of CASSANDRA-17495.
> 
> I am not sure why we stopped with tables only in CASSANDRA-17495, this might be extended to keyspaces too, any schema modification really. I think we have three options here:
> 
> 1) drop CASSANDRA-17495 and implement CASSANDRA-19556 which would cover _all_ schema modifications, not just table-related ones
> 2) keep CASSANDRA-17495 and implement CASSANDRA-19556 as is currently proposed - that means that we would be able to forbid all schema modifications by CASSANDRA-19556 but once schema modifications are allowed, we might further forbid table modifications as implemented by CASSANDRA-17495.
> 3) keep CASSANDRA-17495 but change the implementation of CASSANDRA-19556 in such a way that it would be more granular. What I mean by the granularity is that we would have separate guardrail for keyspace, for example. 
> 
> 2) is the least impactful approach but what I do not like is that, basically, one guardrail (CASSANDRA-19556) would shadow CASSANDRA-17495. For example, if the first one is disabled but the second one is enabled, we can modify keyspaces but we can not modify tables. When the first one is enabled, we can not modify tables even 17495 is not disabled which I find counterintuitive.
> 
> The pros of 3) would be that it would be more granular, indeed, but, is that even necessary? There are a lot of ddl statements, creation of triggers, views, indices, functions, aggregates ... How are we going to categorize it? Do we want to have a guardrail per logical schema component? Is that not an overkill? Can you come up with a scenario when an operator wants to disable keyspace modifications but they would enable table modifications? Or disabling just index, materialized view or function creations / modifications but e.g keyspace modifications would be possible? Is it not easier to have one guardrail for all schema modifications?
> 
> Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1), I think that the option 1) is still viable - we would drop CASSANDRA-17495 and we would have CASSANDRA-19556 instead of that which would act as a global on/off on all schema modifications however given that we go into beta2 I am not sure if it is not just too late.
> 
> Thank you for your opinions in advance.
> 
> Regards