Component Secret Generation via CCO (Story #5)#11
Open
rvanderp3 wants to merge 5 commits into
Open
Conversation
Component-specific credential management design addressing: - Separate provisioning vs operational credentials - Component-specific credentials (machineAPI, storage, cloudController) - Backward compatibility with single-credential mode - Hybrid mode with fallback resolution - Migration tooling for existing clusters Related: #10 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…ials Comprehensive design for dual-credential support in OpenShift vSphere installations. Key components: - Install config schema extension with backward compatibility - Credential validation for provisioning and operational accounts - Secret generation using Day 2 account - Migration tooling for brownfield clusters - UI integration for Assisted Installer and Console Security features: - Provisioning credentials never stored in cluster - Operational account with minimal required permissions - Distinct audit trail via separate usernames Ref: #2 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…cture Revision addresses PO feedback to align with reference enhancement document. Key changes: - Architecture: Per-component credentials (Machine API, CSI, CCM, Diagnostics) instead of dual-phase - Configuration: install-config.yaml componentCredentials + ~/.vsphere/credentials file support - CCO integration: Privilege validation via AuthorizationManager.FetchUserPrivilegeOnEntities() - Multi-vCenter support with credentials keyed by vCenter FQDN - Component-specific secrets in separate namespaces - Detailed privilege requirements per component (Installer: ~45, Machine API: ~35, CSI: ~10-15, CCM: ~10, Diagnostics: ~5) - Administrator automation scripts (govc/PowerCLI) for role creation - Fallback to passthrough mode for backward compatibility - Migration tooling for brownfield clusters Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Implement CreateComponentSecrets() method for generating 4 component-specific secrets - Support single vCenter mode (simple username/password keys) - Support multi-vCenter mode (vCenter FQDN-keyed credentials) - Support passthrough mode fallback when ComponentCredentials is nil - Support partial credentials with graceful degradation - Generate secrets in correct namespaces: - machine-api-vsphere-credentials in openshift-machine-api - vsphere-csi-credentials in openshift-cluster-csi-drivers - vsphere-ccm-credentials in openshift-cloud-controller-manager - vsphere-diagnostics-credentials in openshift-config Test Coverage: - TestCreateComponentSecrets_SingleVCenter (AC1) - TestCreateComponentSecrets_MultiVCenter (AC2) - TestComponentSecretIsolation (AC3) - TestCreateComponentSecrets_PassthroughMode (backward compatibility) - TestCreateComponentSecrets_PartialCredentials (partial fallback) - TestCreateComponentSecrets_MissingVCenterReference (error handling - skipped) - TestCreateComponentSecrets_NamespaceCreation (infrastructure validation) All tests pass (6 pass, 1 skip). Related: #5 (Component Secret Generation via CCO) Parent: #2 (vSphere Multi-Account Credentials) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
rvanderp3
added a commit
that referenced
this pull request
Apr 24, 2026
The monitor-active-prs skill was only checking for: - Reviews with state "CHANGES_REQUESTED" - PR-level comments But missed inline review comments (code-level feedback with state "COMMENTED"). Now also checks /pulls/:pull_number/comments API for inline review comments from non-bot users and emits dev.pr-feedback events when found. Fixes missed feedback like the "why do these tests have TODO?" comment on installer PR #11. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
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.
Summary
This PR implements Story #5: Component Secret Generation via CCO for the vSphere Multi-Account Credentials feature.
Changes
Implementation
File:
projects/cloud-credential-operator/pkg/vsphere/actuator/actuator.gousernameandpasswordkeysvcenter1.example.com.username)Generated Secrets
machine-api-vsphere-credentialsopenshift-machine-apivsphere-csi-credentialsopenshift-cluster-csi-driversvsphere-ccm-credentialsopenshift-cloud-controller-managervsphere-diagnostics-credentialsopenshift-configTest Coverage
File:
projects/cloud-credential-operator/pkg/vsphere/actuator/actuator_test.go7 test functions covering all 3 acceptance criteria:
Test Results: 6 pass, 1 skip
Acceptance Criteria
✅ AC1: Single vCenter secret generation
usernameandpasswordkeys with appropriate credentials✅ AC2: Multi-vCenter secret generation
vcenter1.example.com.username,vcenter1.example.com.password✅ AC3: Component credential isolation
Dependencies
Design Reference
Per-component credential architecture from epic-2.md:
Related Issues
Verification
Expected output: 6 tests pass, 1 skip