Repository navigation
feat(cli): butleradm idp create/update + test/validate (P1 #6) - #55
Merged
Merged
Conversation
Add four verbs to the butleradm idp group, closing audit P1 #6 so an operator can stand up SSO from the CLI (previously list/get/delete only): - idp create NAME --from-file: create an IdentityProvider from a manifest. - idp update NAME --from-file: update the spec, preserving the existing status conditions and resourceVersion so a spec edit never clobbers the controller-managed status. - idp test --issuer-url URL: probe an OIDC issuer's discovery document before creating a provider. - idp validate NAME: probe an existing provider's configured issuer. create and update are CRD-direct and cluster-scoped, like the rest of the idp group and mirroring provider create/update. test and validate go through butler-server; both are read-only OIDC discovery probes (a fetch of the issuer's well-known document), so neither mutates anything and neither needs a confirmation guard. The client secret is supplied by reference: the manifest's spec.oidc.clientSecretRef points at a Secret created separately, consistent with provider create. This is a chosen v1 limitation; the console takes the secret inline and creates it server-side. In exchange, the manifest can set any spec field, including spec.oidc.insecureSkipVerify and spec.oidc.googleWorkspace, which neither client exposed before.
The idp get detail view and list ISSUER column read the pre-nesting paths spec.issuerURL/clientID/scopes/claims, which are always empty on the current CRD (fields live under spec.oidc). Read spec.oidc.* so issuer, client ID, scopes, and claim mappings render. Surfaced by the P1 #6 lifecycle E2E.
Contributor
Author
Live E2E validation (butler-beta, console.beta.butlerlabs.dev)Full IdP lifecycle exercised against the real butler-server + management apiserver, with a throwaway IdP (
Bug found and fixed in-branchThe E2E surfaced a pre-existing display bug: |
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
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.
P1 #6 — IdentityProvider create/update + discovery test
Maps to audit P1 #6. Closes the SSO-standup gap: today
butleradm idpis list/get/delete only, so an operator can't create or update an identity provider from the CLI. Adds the lifecycle verbs and completes console parity for the IdP surface.Verbs
idp create NAME --from-file f.yamlidp update NAME --from-file f.yamlidp test --issuer-url URL [-o table|json|yaml]idp validate NAME [-o ...]The split (mechanism)
-n), mirroringprovider create/provider update.updatedoes Get-then-merge-spec-then-Update, preserving the existing status conditions and resourceVersion so a spec edit never clobbers the controller-managed status.serverhttp). Both are read-only OIDC discovery probes (testOIDCDiscoveryfetches the issuer's.well-known/openid-configuration), so neither mutates anything and neither needs a confirmation guard.testtakes an issuer URL (pre-create);validateuses an existing provider's configured issuer (POST.../{name}/validate).Secret handling (chosen v1 limitation)
The client secret is supplied by reference: the manifest's
spec.oidc.clientSecretRefpoints at a Secret created separately (for examplekubectl create secret), consistent withprovider create --from-file. The console instead takes the secret inline and creates it server-side. Documented as a known v1 choice; a--client-secret-from-fileconvenience is queued for later. In exchange, the CRD-direct--from-filecan set any spec field, includingspec.oidc.insecureSkipVerifyandspec.oidc.googleWorkspace, which neither client exposed before (audit Section 7.3 gap).Tests
mergeIdPSpecpreserves status conditions + resourceVersion (mutation-checked: a clobbering merge fails).printDiscoveryrendering for valid + invalid results (non-vacuous).translateDiscoveryError403/404/400 mapping.Cross-track
No collision with the portal auth track:
test/validateride serverhttp on the device-flow session JWT, not header impersonation.Follows P1 #5 (provider get/update + discovery) in the CLI/console parity effort.