[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789634#comment-17789634
]
Stefan Miklosovic edited comment on CASSANDRA-15254 at 11/25/23 9:42 AM:
-------------------------------------------------------------------------
I just stumbled upon this again ... (which tells me there is something
attractive in this ticket that I tend to gravitate towards it every now and
then :) )
Imagine a scenario that we start a node with default configuration from
cassandra.yaml and then somebody tweaks the configuration via a system table so
it starts to diverge from what is in cassandra.yaml on the disk. When that node
is restarted, since all settings we changed were living solely in a memory, we
lost that configuration, right? So you have to go to that node again, start it
and manually tweak it again (an operator might not even know anymore what the
tweaks were about).
What would be great is to have some nodetool command which would connect to a
running node and it would dump what is in DatabaseDescriptor into a yaml file.
Then, this file might be used upon node's restart.
The problem with this solution is that a person having the access to nodetool
does not necessarily need to have the access to CQL or similar. In other words,
if a person doing the dump via nodetool is not supposed to know what the
credentials in cassandra.yaml are (password to keystore / truststore
credentials and similar), then by mere dumping of that info to a yaml, we have
a security leak.
The workaround might be a property in cassandra.yaml which would tell what the
destination of a dumped configuration on disk would be (some path) which would
be immutable property. Then the ownership / disk permissions might be changed
in such a way that an operator would not be able to read it from there if he
does not have such permission.
It is worth to look at Cassandra Sidecar to check if they have an endpoint
which would return such yaml. I am not sure what security model they have there
if such dumping of configuration is possible.
was (Author: smiklosovic):
I just stumbled upon this again ... (which tells me there is something
attractive in this ticket that I tend to gravitate towards it every now and
then :) )
Imagine a scenario that we start a node with default configuration from
cassandra.yaml and then somebody tweaks the configuration via a system table so
it starts to diverge from what is in cassandra.yaml on the disk. When that node
is restarted, since all settings we changed were living solely in a memory, we
lost that configuration, right? So you have to go to that node again, start it
and manually tweak it again (an operator might not even know anymore what the
tweaks were about).
What would be great is to have some nodetool command which would connect to a
running node and it would dump what is in DatabaseDescriptor into a yaml file.
Then, this file might be used upon node's restart.
The problem with this solution is that a person having the access to nodetool
does not necessarily need to have the access to CQL or similar. In other words,
if a person doing the dump via nodetool is not supposed to know what the
credentials in cassandra.yaml are (password to keystore / truststore
credentials and similar), then by mere dumping of that info to a yaml, we have
a security leak.
The workaround might be a property in cassandra.yaml which would tell what the
destination of a dumped configuration on disk would be (some path) which would
be immutable property. Then the ownership / disk permissions might be changed
in such a way that an operator would not be able to read it from there if he
does not have such permission.
> Allow UPDATE on settings virtual table to change running configurations
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15254
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
> Reporter: Chris Lohfink
> Assignee: Maxim Muzafarov
> Priority: Normal
> Fix For: 5.x
>
> Attachments: Configuration Registry Diagram.png
>
> Time Spent: 20h 10m
> Remaining Estimate: 0h
>
> Allow using UPDATE on the system_views.settings virtual table to update
> configs at runtime for the equivalent of the dispersed JMX
> attributes/operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
