Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@shawkins
Copy link
Contributor

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?

Copy link
Contributor

@vmuzikar vmuzikar left a 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.

@vmuzikar
Copy link
Contributor

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.

This works for me. We just populate the default Secret.

We probably should also add some docs and reflect it there.

@vmuzikar vmuzikar linked an issue Jul 4, 2024 that may be closed by this pull request
@shawkins shawkins changed the title draft of operator bootstrap admin handling operator bootstrap admin handling Jul 5, 2024
@shawkins
Copy link
Contributor Author

shawkins commented Jul 5, 2024

We probably should also add some docs and reflect it there.

Added some docs to the advanced guide, see if that works for you.

Copy link
Contributor

@vmuzikar vmuzikar left a 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.

Copy link
Contributor

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).

Copy link
Contributor Author

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

Co-authored-by: Václav Muzikář <[email protected]>
Signed-off-by: Steven Hawkins <[email protected]>
@shawkins
Copy link
Contributor Author

shawkins commented Jul 9, 2024

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.

Copy link

@keycloak-github-bot keycloak-github-bot bot left a 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

@keycloak-github-bot
Copy link

Unreported flaky test detected

If 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

Keycloak CI - Base IT (6)

java.net.UnknownHostException: 127.0.0.1.nip.io: Temporary failure in name resolution
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
	at java.base/java.net.InetAddress$PlatformResolver.lookupByName(InetAddress.java:1211)
	at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1828)
...

Report flaky test

Copy link
Contributor

@vmuzikar vmuzikar left a 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
Copy link
Contributor

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...

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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!

@shawkins
Copy link
Contributor Author

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?

Sounds good.

@vmuzikar vmuzikar merged commit 3139b82 into keycloak:main Jul 24, 2024
stianst pushed a commit to stianst/keycloak that referenced this pull request Jul 25, 2024
* 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]>
vmuzikar added a commit to vmuzikar/keycloak that referenced this pull request Jul 26, 2024
ahus1 pushed a commit that referenced this pull request Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bootstrapping an admin user or service account using the Operator

2 participants