do not generate new passwords if the secrets already exist #414
Conversation
|
When reviewing and testing changes, check the passwords of the secrets that get created. Make sure that they do not change after running |
| @@ -14,6 +22,6 @@ data: | |||
| {{- if .Values.reaper.jmx.password }} | |||
| password: {{ .Values.reaper.jmx.password | b64enc | quote }} | |||
| {{- else }} | |||
| password: {{ include "k8ssandra-common.password" . }} | |||
| password: {{ $password }} | |||
There was a problem hiding this comment.
So this tackles the password, but is the username guaranteed to not be regenerated?
There was a problem hiding this comment.
Nice catch :) I missed that. I will update that now.
| {{- include "k8ssandra.clusterName" . }}-superuser | ||
| {{- end }} | ||
|
|
||
| {{- define "k8ssandra.reaperUserSecrentName" }} |
| {{- if and .Values.cassandra.auth.superuser.username (not .Values.cassandra.auth.superuser.secret) .Values.cassandra.auth.enabled }} | ||
|
|
||
| {{- if $secret }} | ||
| {{- $password = index $secret.data "password" }} |
There was a problem hiding this comment.
This question applies to this, medusa, reaper and stargate.. if I had a username in the Values-file, but changed it - won't my secrets be all messed up in the upgrade process? Currently, only the existing password is fetched in these, but not the existing username. So instead of existing username, we use the one from the values file, but old password. I'll be honest, I have no idea how messed up we could make the system if secret exists, but these are targetting a different username.
There was a problem hiding this comment.
if I had a username in the Values-file, but changed it - won't my secrets be all messed up in the upgrade process?
I tested this a bit, but it probably deserves more testing. I would not consider the secret messed up in this scenario because the user is intentionally changing them. What are the consequences? If the superuser username was foo and I change it to bar, then after upgrade I will have two superusers. For 1.0, we really cannot do anything other than document this behavior.
There was a problem hiding this comment.
For a first test, I installed with this configuration:
cassandra:
auth:
enabled: true
datacenters:
- name: dc1
size: 1
reaper:
enabled: true
stargate:
enabled: true
replicas: 1
reaper:
enabled: true
cassandraUser:That results in the creation of a secret named test-reaper and a Cassandra role/user named reaper with password U59R30EzNxcNUjqi1koK. I then changed my configuration to:
cassandra:
auth:
enabled: true
datacenters:
- name: dc1
size: 1
reaper:
enabled: true
stargate:
enabled: true
replicas: 1
reaper:
enabled: true
cassandraUser:
username: reaper-adminAfter upgrading the username in the secret was changed to reaper-admin. The password in the secret did not. A new role was created, reaper-admin, same password as for reaper role.
I think a really good question is what if anything should happen to the reaper role. Should it be deleted in this case? Even if the answer is yes, it would be a post-1.0 change and probably require changes in cass-operator.
There is an additional change that I think should be made. When I change the username, I think a different password should be generated.
There was a problem hiding this comment.
I think I agree on all fronts there. I would generally expect that if the username is changed, that should effectively create a new user, not reuse the password from the older account. I also think the cleanup of the left-over role can wait until post-1.0.0.
There was a problem hiding this comment.
https://github.com/datastax/cass-operator/issues/382 is related and something with which we need to be involved.
There was a problem hiding this comment.
I'm fine with postponing these to post-1.0
If the secret exists, reuse the existing username. If a username is provided, use the latter. If secret does not exist and no username specified, use default.
…#414) * do not generate new passwords if the secrets already exist * add helper templates * do not regenerate username for reaper jmx secret * fix typo * Bring remaining typos in sync. * add logic to handle usernames If the secret exists, reuse the existing username. If a username is provided, use the latter. If secret does not exist and no username specified, use default. * fix logic for reaper and stargate users * update logic for medusa secret and fix logic for when to reuse secret (thanks Jeff D) * update logic for default superuser and repaer jmx user * update logic to determine if secrets should be created and add docs Co-authored-by: Jeff DiNoto <jeff.dinoto@gmail.com>
What this PR does:
Which issue(s) this PR fixes:
Fixes #413
Checklist