-
Notifications
You must be signed in to change notification settings - Fork 7.9k
operator bootstrap admin handling #30711
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
Conversation
vmuzikar
left a comment
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.
@shawkins Thank you for the Operator changes. Overall looks good, added just some minor comments. We'll also need some tests.
...or/src/main/java/org/keycloak/operator/crds/v2alpha1/deployment/spec/BootstrapAdminSpec.java
Outdated
Show resolved
Hide resolved
...or/src/main/java/org/keycloak/operator/crds/v2alpha1/deployment/spec/BootstrapAdminSpec.java
Outdated
Show resolved
Hide resolved
...or/src/main/java/org/keycloak/operator/crds/v2alpha1/deployment/spec/BootstrapAdminSpec.java
Outdated
Show resolved
Hide resolved
This works for me. We just populate the default Secret. We probably should also add some docs and reflect it there. |
closes: keycloak#30004 Signed-off-by: Steve Hawkins <[email protected]>
Added some docs to the advanced guide, see if that works for you. |
vmuzikar
left a comment
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.
@shawkins Added some last suggestions, nothing really blocking.
| When you create a new instance the Keycloak CR spec.bootstrapAdmin stanza may be used to configure the bootstrap user and/or service account. If you do not specify anything for the spec.bootstrapAdmin, the operator will create a Secret named "metadata.name"-initial-admin with a username temp-admin and a generated password. If you specify a Secret name for bootstrap admin user, then the Secret will need to contain username and password key value pairs. If you specify a Secret name for bootstrap admin service account, then the Secret will need to contain client-id and client-secret key value pairs. | ||
|
|
||
| If a master realm has already been created for you cluster, then the spec.boostrapAdmin is effectively ignored. If you need to create a recovery admin account, then you'll need to run the CLI command against a Pod directly. | ||
|
|
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.
It might be also good to add a link here to the Admin Bootstrapping guide (once it's merged).
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.
Ok, we can wait for #31039 to be merged first
...or/src/main/java/org/keycloak/operator/crds/v2alpha1/deployment/spec/BootstrapAdminSpec.java
Outdated
Show resolved
Hide resolved
...or/src/main/java/org/keycloak/operator/crds/v2alpha1/deployment/spec/BootstrapAdminSpec.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Václav Muzikář <[email protected]> Signed-off-by: Steven Hawkins <[email protected]>
closes: keycloak#30004 Signed-off-by: Steve Hawkins <[email protected]>
|
The strategy of modifying the Keycloak spec in the controller does not work well here - the dependents run before the controller, so we end up with a race condition as to whether a deployment is attempted without a bootstrap admin secret. Rather than trying to customize the operator workflow, the simplest thing is just to treat a non-specified user secret as the default. |
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.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.url.HostnameV2Test#testAdminLocal |
vmuzikar
left a comment
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.
The changes still look good to me. I'd like to merge this rather sooner than later. We can add the docs link as a follow up. @shawkins WDYT?
|
|
||
| Log.debugf("--- Reconciling Keycloak: %s in namespace: %s", kcName, namespace); | ||
|
|
||
| // TODO - these modifications to the resource belong in a webhook because dependents run first |
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.
Isn't this essentially an Operator SDK bug? We're not doing anything special here...
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.
@vmuzikar I don't think it's a bug, just how the operator sdk works by default.
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.
Then how are we supposed to update spec?
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.
We can update it here, but not in a way that will cause a race condition. The pr initially didn't assume a default in the deployment dependent logic which lead to the initial creation of the statefulset without bootstrap env variables.
It's not a hard reqirement for this feature that the spec is populated with the defaults.
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.
Ok, I see. Thanks for clarifying!
Sounds good. |
* enhance: add bootstrap admin handling to the operator closes: keycloak#30004 Signed-off-by: Steve Hawkins <[email protected]> * Update docs/guides/operator/advanced-configuration.adoc Co-authored-by: Václav Muzikář <[email protected]> Signed-off-by: Steven Hawkins <[email protected]> * enhance: add bootstrap admin handling to the operator closes: keycloak#30004 Signed-off-by: Steve Hawkins <[email protected]> --------- Signed-off-by: Steve Hawkins <[email protected]> Signed-off-by: Steven Hawkins <[email protected]> Co-authored-by: Václav Muzikář <[email protected]>
This reverts commit 3139b82.
This is layered on the other bootstrap changes. After looking at the implementation possiblities a little more, I think it makes more sense to manage things at a secret level - giving us 2 secrets to worry about instead of 4 - and just assume the keys by convention.
To minimize the number of api server interactions per reconciliation we also won't attempt to write back values into user provided secrets - if the user specifies the secret, then we expect it to exist and the fields be present. We can of course add optional handling if that seems warrented.
@vmuzikar WDYT?