operator bootstrap admin handling#30711
Conversation
...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. |
| 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.
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.
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. |
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 |
|
|
||
| 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.
Isn't this essentially an Operator SDK bug? We're not doing anything special here...
There was a problem hiding this comment.
@vmuzikar I don't think it's a bug, just how the operator sdk works by default.
There was a problem hiding this comment.
Then how are we supposed to update spec?
There was a problem hiding this comment.
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.
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?