-
Notifications
You must be signed in to change notification settings - Fork 1
[DPE-7641] Authentication #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good starting point. I thought that this PR was also including the handling of system user password with secrets like here. Will this be part of another PR ?
Did I understood it correctly, that this question is about secret changed event? I thought I'll put it in another PR, but considering that this PR is relatively small, I'll include it here. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just discuss about the authenitcation flow, to be on the same page. I'll continue with the review after the discussion
seeds=["127.0.0.1:7000"], | ||
authentication=False, | ||
) | ||
self.workload.start() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question If I understand the logic correctly, here we are starting the server with no authentication. This seems weird and it could pose a security threat. I understand that we are possibly restricting the listen_address into localhost, but why do we need to do this?
Another possibility could also be to start the server using a temporary username and password that only the units knows, such that it can still use the service in authenticated fashion, and then change the password to use the "official" one.
anyhow, let's discuss later at daily
keystore_password=self.state.unit.keystore_password, | ||
truststore_password=self.state.unit.truststore_password, | ||
authentication=bool(self.state.cluster.cassandra_password_secret), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
quesiton why do we allow this? Maybe I would not expose this, and only allow authentication to be true, just to prevent mistakes. We must ensure that authentication is enabled at all times, if external access is possible.
yaml.dump(config, allow_unicode=True, default_flow_style=False) | ||
yaml.dump( | ||
self._merge_dicts( | ||
[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise I really really really like how you splitted the config into separate section. It is a lot more maintanable IMHO
self.database_manager.update_system_user_password( | ||
"cassandra", self.state.cluster.cassandra_password_secret | ||
) | ||
self.cluster_manager.prepare_shutdown() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question why do we drain before reconfiguring the password? The drai operation may be massive?
): | ||
self.database_manager.update_system_user_password("cassandra", password) | ||
self.state.cluster.cassandra_password_secret = password | ||
self.cluster_manager.prepare_shutdown() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue it is strange that we need to drain for every config change/rotation password
f923544
to
7476eea
Compare
Overview
This PR:
cassandra
user. Showcase diagram of changes is presented below.Diagram of startup logic changes
Diagram describes
on_start
event handling represented from the leader perspective as there's no changes for the subordinate units.