support in-place secret changes (PR 5 of 6) #346
+471
−65
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zzzeek
changed the title
zzzeek
force-pushed
the
OSPRH-14916-pr5
branch
3 times, most recently
from
11b8925 to
a1ccbd6
Compare
zzzeek
force-pushed
the
OSPRH-14916-pr5
branch
2 times, most recently
from
06467ea to
350ed1f
Compare
zzzeek
force-pushed
the
OSPRH-14916-pr5
branch
from
350ed1f to
4174fa8
Compare
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: zzzeek The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
zzzeek
force-pushed
the
OSPRH-14916-pr5
branch
3 times, most recently
from
116ddda to
74e9a8e
Compare
zzzeek
force-pushed
the
OSPRH-14916-pr5
branch
2 times, most recently
from
e685bef to
1811f02
Compare
introduce a new class of MariaDBAccount called a "system" MariaDBAccount, indicated by a new enumerated field AccountType on the CR. Such accounts link directly to a Galera instance and have no dependency on a MariaDBDatabase CR. The expected targets for "system" accounts will include the Galera/mysql root username and password, as well as a system account used by mariadbbackup for SST. Refactor mariadbaccount_controller to isolate logic used for acquiring MariaDBDatabase and Galera CRs into separate functions, and ensure all MariaDBDatabase logic takes place only for "user" accounts (which would be all current MariaDBAccount CRs). Also correct an oversight where MariaDBAccount would not unconditionally apply a finalizer to its Secret object. This logic now takes place in addition to an unconditional removal of the finalizer when the MariaDBAccount object is deleted. A subsequent change will allow system-level passwords to be changed in place by applying the secret name to two separate fields MariaDBAccount/Spec/Secret and MariaDBAccount/Status/Secret. When these two names differ it will indicate an in-place password change should take place.
The existing mariadb operator in fact already "supports" in-place change of secret, since if you change Spec.Secret to a new secret name, that would imply a new job hash, and the account.sh script running using only GRANT statements would update the password per mariadb. This already works for flipping the TLS flag on and off too. So in this patch, we clean this up and add a test to include: * a new field Status.CurrentSecret, which is used to indicate the previous secret from which the finalizer should be removed. This will also be used when we migrate the root password to use MariaDBAccount by providing the "current" root password when changing to a new root password * improved messaging in log messages, name of job. This changes the job hash for mariadbaccount which will incur a run on existing environments, however the job hashes are already changing on existing environments due to the change in how the mysql root password is sent, i.e. via volume mounted script rather than env var secret * update account.sh to use modern idiomatic patterns for user create /alter, while mariadb is fine with the legacy style of using only GRANT statements, MySQL 8 no longer allows this statement to proceed without a CREATE USER, so formalize the commands used here to use distinct CREATE USER, ALTER USER, GRANT statements and clarify the script is good for all create/update user operations.
zzzeek
force-pushed
the
OSPRH-14916-pr5
branch
from
1811f02 to
a6e941f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The existing mariadb operator in fact already "supports" in-place
change of secret, since if you change Spec.Secret to a new secret
name, that would imply a new job hash, and the account.sh script running
using only GRANT statements would update the password per mariadb.
This already works for flipping the TLS flag on and off too.
So in this patch, we clean this up and add a test to include:
previous secret from which the finalizer should be removed. This will
also be used when we migrate the root password to use MariaDBAccount
by providing the "current" root password when changing to a new root
password
job hash for mariadbaccount which will incur a run on existing environments,
however the
job hashes are already changing on existing environments due to the
change in how the mysql root password is sent, i.e. via volume mounted
script rather than env var secret
/alter, while mariadb is fine with the legacy style of using only
GRANT statements, MySQL 8 no longer allows this statement to proceed
without a CREATE USER, so formalize the commands used here to use
distinct CREATE USER, ALTER USER, GRANT statements and clarify the
script is good for all create/update user operations.