Feature Overview

vSphere Multi-Account Credential Management enables the OpenShift Installer to utilize distinct VMware vCenter accounts for different phases of the cluster lifecycle. By separating high-privileged "Provisioning" credentials (used for infrastructure creation) from "Day 2" operational credentials, we significantly reduce the security blast radius and simplify compliance for enterprise environments.

Goals

• Privilege Separation: Allow users to provide one set of credentials for cluster creation and a different, restricted set for ongoing cluster operations.
• Migration Path: Provide a supported mechanism to transition existing "single-account" clusters to a "multi-account" configuration without downtime.
• User Persona: Cloud Architects and Security Administrators who require strict IAM (Identity and Access Management) policies within vSphere.

Requirements

Functional

• Dual-Credential Support in install-config.yaml: The installer must support a new schema allowing the definition of a provisioning user and an operational user.
• Automated Secret Provisioning: The installer must correctly populate the vsphere-cloud-credentials secret in the kube-system namespace using the specified "Day 2" account.
• Credential Migration Tooling: Provide a method (via oc or openshift-install) to update an existing cluster's secret and CCO configuration to move to a multi-account model.
• Validation Logic: The installer must validate that the provisioning account has permissions for resource creation (Folder, Resource Pool, Network) while the operational account has the minimum permissions required.
• UI Integration: The Assisted Installer (AI) and OpenShift Console must provide fields to input both sets of credentials during the "Infrastructure Provider" configuration step.

Non-Functional

• Security: High-privileged provisioning credentials must not be stored in the cluster's permanent configuration unless explicitly requested.
• Reliability: The transition from provisioning to operational credentials must be atomic to prevent "orphaned" infrastructure during installation.
• Auditability: Actions performed by the installer vs. actions performed by the in-cluster operators must be distinguishable in vCenter events via the separate usernames.

User Scenarios

• Scenario 1: New Secure Installation
  "As a Security Administrator, I want to provide the OpenShift Installer with a temporary high-privilege account to build the environment, but ensure the running cluster only has access to a restricted 'Day 2' account so that a compromised cluster cannot delete the entire datacenter."
• Scenario 2: Brownfield Migration
  "As a Cloud Architect, I want to update my existing vSphere IPI cluster—which currently uses a 'root-level' service account—to use a restricted operational account instead, so that I can meet the company's new hardened security standards."

Out of Scope

• Automatic Account Creation: This feature will not automatically create the users in vCenter; they must exist prior to installation.
• Cross-vCenter Management: Managing a single cluster across two different vCenter instances (vCenter-A for provisioning, vCenter-B for Day 2) is not supported.
• Non-vSphere Providers: This enhancement is strictly limited to the vSphere provider logic.

Questions to Answer

Links

• Reference Enhancement:[ vSphere Multi-Account Credentials|https://github.com/rvanderp3/enhancements/blob/9e5c28ffd653e2b75f95ab58f76bb6edddcd5247/enhancements/installer/vsphere-multi-account-credentials-enhancement.md]
• Existing Documentation:[ Installing OpenShift on vSphere|https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html-single/installing_on_vmware_vsphere/index]