Implement multi-vCenter support for vSphere (Story #8)#7
Open
rvanderp3 wants to merge 7 commits into
Open
Conversation
This commit implements Story #3: Install Config Schema Extension for vSphere Multi-Account Credentials. It extends the install-config.yaml schema to support per-component credentials while maintaining backward compatibility with legacy single-account mode. Changes: - Add ComponentCredentials struct with fields for installer, machineAPI, csiDriver, cloudController, and diagnostics components - Add AccountCredentials struct supporting multi-vCenter topologies - Add platform field for optional ComponentCredentials - Create test stubs for schema validation (6 test scenarios) - Create test stubs for install-config integration tests Test Plan: - Unit tests in pkg/types/vsphere/validation_test.go - Default/fallback tests in pkg/types/vsphere/defaults_test.go - Integration tests in pkg/asset/installconfig/vsphere/validation_test.go All tests are currently stub implementations marked with t.Skip() and will be fully implemented in subsequent iterations. Related: openshift-splat-team/splat-team#3 Parent: openshift-splat-team/splat-team#2 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add vSphere privilege validation logic using component-specific privilege lists. Validates that each OpenShift component account (installer, machine-api, csi-driver, cloud-controller, diagnostics) has required vCenter permissions before installation proceeds. Implementation: - PrivilegeValidator struct with ValidateComponentPrivileges method - ValidationResult struct with Valid, MissingPrivileges, Scope fields - GetRequiredPrivileges() function with comprehensive privilege lists - Installer: ~45 privileges for infrastructure deployment - Machine API: ~35 privileges for VM lifecycle - CSI Driver: ~12 privileges for storage provisioning - Cloud Controller: ~10 read-only privileges for node discovery - Diagnostics: ~5 read-only privileges for troubleshooting Test coverage: - 9 test scenarios covering all acceptance criteria - Missing privilege detection (machine-api, csi-driver) - Successful validation for all components - Component-specific privilege sets - Error handling Foundation for Story #4: Privilege Validation Parent Epic: #2 - vSphere Multi-Account Credentials Depends on: Story #3 (schema extension) Related: openshift-splat-team/splat-team#4 Related: openshift-splat-team/splat-team#2 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit implements the greenfield installation flow for per-component vSphere credentials (Story #6), enabling distinct vCenter accounts for each OpenShift component to improve security posture through principle of least privilege. Implementation: - percomponent.go: Integration logic for credential validation and selection - ValidatePerComponentCredentials: Validates all 5 component credentials - GetInstallerCredentials: Returns installer credentials for infrastructure - IsPerComponentMode: Detects per-component vs legacy mode - Helper functions for vCenter/credential resolution - integration_test.go: 8 integration test scenarios - Happy path: All 5 accounts configured and validated - Validation failures: Missing privileges for installer, machine-api, csi-driver - Component secret isolation: RBAC verification - Runtime credential usage: Machine API, CSI, CCM, Diagnostics - vsphere_percomponent_test.go: 2 E2E test scenarios - Full installation flow with all components - vCenter audit log verification for distinct usernames Test Coverage: - 10 test scenarios covering all acceptance criteria - Integration with Stories #3 (schema), #4 (validation), #5 (CCO) - All tests compile successfully - Tests skip with "Implementation pending" (TDD approach) Acceptance Criteria: - AC1: Installer validates component credentials have required privileges - AC2: Installer uses installer account for infrastructure provisioning - AC3: CCO creates component-specific secrets - AC4-AC7: Components use their specific credentials at runtime - AC8: vCenter audit logs show distinct usernames Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Test coverage: - Single vCenter YAML credentials file reading - Multi-vCenter YAML credentials file reading - File permissions validation (reject 0644, 0777) - Precedence: install-config.yaml over credentials file - Partial precedence with fallback to credentials file - Missing credentials file fallback to legacy passthrough - Malformed YAML error handling - Empty credentials file handling - Partial component credentials with fallback All tests use t.Skip() for TDD approach. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implements Story #7: Credentials File Support (YAML Format) This commit adds support for reading per-component vSphere credentials from a YAML credentials file at ~/.vsphere/credentials. The file uses YAML format with vCenter servers as top-level keys, each containing component-specific credential mappings. Key features: - YAML file format with vCenter FQDN as top-level keys - File permissions validation (must be 0600) - Precedence: install-config.yaml > credentials file > legacy passthrough - Graceful fallback when file doesn't exist or is empty - Support for single and multi-vCenter topologies - Partial component credentials with mixed sources Implementation: - pkg/asset/installconfig/vsphere/credentialsfile.go: Core parser and validator - pkg/asset/installconfig/vsphere/credentialsfile_test.go: 10 test scenarios All acceptance criteria verified: - AC1: YAML credentials file with correct permissions (0600) - AC2: File permissions validation (reject 0644, 0777) - AC3: Precedence (install-config over credentials file) Test coverage: 10/10 tests passing - Single vCenter YAML file reading - Multi-vCenter YAML file reading - Permissions rejection (0644, 0777) - Precedence (full and partial) - Missing file fallback - Malformed YAML error handling - Empty file fallback - Partial component coverage Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Test Plan Coverage: - Configuration parsing for multi-vCenter install-config - Credential validation across multiple vCenter servers - FQDN-keyed secret format verification - Component-to-vCenter binding validation - Cross-vCenter operations testing - Mixed mode (default + override vCenters) - Error handling for missing credentials - Integration tests for full installation flow - Audit trail verification Test Files: - pkg/asset/installconfig/vsphere/multi_vcenter_test.go (5 unit tests) - pkg/asset/cluster/multi_vcenter_integration_test.go (4 integration tests) All tests currently skip with 'Implementation pending - Story #8'. Tests will be implemented as part of story development. Related: openshift-splat-team/splat-team#8 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add isMultiVCenterMode() helper to detect multi-vCenter topology - Add getComponentVCenter() to resolve component-specific vCenter - Add getAllReferencedVCenters() to collect all vCenter references - Add validateMultiVCenterCredentials() for credential validation - Implement 5 unit tests covering all acceptance criteria - All tests pass: TestMultiVCenter* suite Story #8: Multi-vCenter Support Epic #2: vSphere Multi-Account Credentials Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This was referenced Apr 14, 2026
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
Implements multi-vCenter support for vSphere per-component credentials, allowing different OpenShift components to connect to different vCenter servers.
Implementation Details
Multi-vCenter Detection
isMultiVCenterMode()helper that detects when any component specifies a vCenter overrideHelper Functions
getComponentVCenter(): Resolves effective vCenter for a component (override or default)getAllReferencedVCenters(): Collects all vCenter FQDNs referenced across componentsvalidateMultiVCenterCredentials(): Validates vCenter references are properly configuredTest Coverage
All 5 unit tests passing:
Acceptance Criteria Coverage
Dependencies
Integration Points
Test Plan
Unit tests verify:
Integration tests (in cluster-multi_vcenter_integration_test.go) document E2E scenarios but require multi-vCenter test infrastructure.
🤖 Generated with Claude Code