In a private cloud built on VMware Cloud Foundation (VCF), identity serves as the first line of defense. Access to vCenter, NSX, SDDC Manager, and VCF Operations is provided through an enterprise identity provider, while network policies are tied to specific users and services.
The entire topic of “identity security in VCF” can be divided into three layers:
- IAM (Identity and Access Management) — single sign-on (SSO), federation with a corporate IdP, multi-factor authentication (MFA), and role-based access control (RBAC).
- PAM (Privileged Access Management) — elimination of “standing” administrative passwords, just-in-time (JIT) privilege elevation, secret rotation, and session recording.
- Zero Trust — continuous verification, NSX Distributed Firewall (DFW) microsegmentation, and a “deny by default unless explicitly allowed” security model.
These layers operate together: the IdP determines who you are, RBAC defines what you are allowed to do, PAM controls privileged operations, and NSX DFW enforces policies at the network level. All events are consolidated into centralized auditing. According to NIST SP 800-207, Zero Trust assumes that being inside the network does not provide any implicit trust — every session requires explicit authentication and authorization.
VCF Architecture and Attack Surface
VCF is an integrated platform that automates deployment and lifecycle management of the entire software-defined data center (SDDC). It includes a single Management Domain for infrastructure management components and separate Workload Domains for tenant and application workloads. The Management Domain is deployed through Cloud Builder and contains SDDC Manager, vCenter Server, and NSX Manager. Workload Domains are created and managed through SDDC Manager, following the VMware VCF Reference Architecture.
From a security perspective, VCF consists of four key operational planes:
- Virtualization layer — vCenter and ESXi, including direct hypervisor access.
- Network security layer — NSX Manager, Distributed Firewall, and East-West traffic control.
- Orchestration layer — SDDC Manager and VCF Operations for fleet management and lifecycle management (LCM).
- Operational layer — auditing, logging, and compliance validation.
VCF 5.2.1 introduced three SSO deployment models:
- Shared SSO domain through Enhanced Link Mode (ELM)
- Isolated SSO domains for Workload Domains in multi-tenant environments
- Federation with external Identity Providers (IdPs)
VCF Operations can centrally enable federated SSO across all vCenter instances and NSX Local Managers.
VCF 9.0 introduced the VCF Identity Broker (VIDB), a component that provides unified SSO for vSphere Client, NSX Manager, VCF Operations, and other management interfaces. VIDB supports modern identity providers such as Entra ID, Okta, Ping, ADFS, and generic SAML implementations, along with JIT and SCIM provisioning methods. Deployment can be performed either in embedded mode or on a dedicated appliance cluster.
VMware positions VCF as a “hardened out-of-the-box” platform with built-in RBAC, Identity Federation (Entra ID, Okta), and lateral security enforcement through vDefend and NSX.
IAM: SSO, Federation, RBAC, and Auditing
Within VCF, IAM functions as an end-to-end identity control plane for accessing vCenter, NSX, SDDC Manager, and VCF Operations. It consists of three key components: authentication (SSO/IdP), authorization (RBAC), and observability (auditing).
- vCenter SSO and Identity Sources – vCenter SSO provides centralized authentication for vSphere components through token exchange mechanisms, eliminating the need for separate authentication between services. Two identity models are supported: federation with an external IdP and built-in identity provider (vsphere.local) with integration to Active Directory via LDAP/LDAPS or Integrated Windows Authentication (now considered legacy).
- Federation with Enterprise Identity Providers – the primary advantage of federation is that MFA and Conditional Access policies are enforced directly by the IdP, while vCenter and NSX sessions inherit those security decisions, including geographic restrictions, device posture validation, and risk-based authentication. VCF Operations supports integration with AD FS, Azure AD / Entra ID, Okta, Ping Identity, and OAuth 2.0 providers. This enables centralized identity management across the entire VCF fleet.
- RBAC and least privilege – VMware recommends the following RBAC best practices: use named administrative accounts; assign the Administrator role only where strictly necessary; create custom roles instead of relying on global administrative access; use dedicated service accounts for applications and integrations. An important operational detail is that vCenter automatically rotates the vpxuser account password every 30 days, which must be considered when integrating with PAM solutions (discussed in more detail here).
- Identity Lifecycle Management – in VCF 9, Identity Broker supports JIT provisioning (automatic account creation during first login) and SCIM provisioning (automated synchronization of users and groups from external directories). Directory groups can be automatically mapped to roles across VCF components (for more details, see here).
- Auditing and visibility – VCF Operations includes Security Operations dashboards, user authentication monitoring, permission auditing, event auditing, and compliance checks.
Summary of IAM capabilities in VCF:
| Area | Mechanism | Protocol / Approach | Benefits |
|---|---|---|---|
| vCenter | vCenter SSO | Token exchange, embedded or federated IdP | Unified vSphere authentication, AD/LDAP integration, IdP federation |
| VCF fleet management | SSO and Identity Management | AD FS, Azure AD, Okta, Ping, OAuth 2.0 | Unified login across multiple VCF components |
| VCF 9 | VCF Identity Broker (VIDB) | SAML/OIDC, JIT/SCIM | Unified SSO across management consoles, modern IdP support |
| Authorization | RBAC and custom roles | Least privilege, named accounts, group-based access | Reduced blast radius during credential compromise |
In practice, a reference IAM implementation for VCF typically looks like this:
- An external IdP provides MFA and Conditional Access enforcement.
- Roles in vCenter and NSX are assigned to IdP groups rather than individual users.
- Local accounts remain only as break-glass accounts and are protected through PAM.
- All administrative activity is forwarded into centralized auditing and SIEM platforms.
Example declarative group and role model (GitOps-style):
# Declarative group and role model for VCF (pseudo-YAML) identity: idp: "entra-id" # or okta / ping / adfs groups: - name: "vcf-platform-admins" description: "Full administrative access to VCF infrastructure" - name: "vcf-vcenter-ops" description: "vCenter operators with limited privileges" - name: "vcf-nsx-secops" description: "Network security operations: NSX DFW and segmentation" - name: "vcf-audit-readonly" description: "Auditors with read-only access" rbac: vcenter: - group: "vcf-platform-admins" role: "Administrator" scope: "global" - group: "vcf-vcenter-ops" role: "CustomRole-VirtualInfraOps" scope: "Management-Domain" nsx: - group: "vcf-nsx-secops" role: "Enterprise Admin" scope: "default-space" operations: - group: "vcf-audit-readonly" role: "ReadOnly-Audit"
PAM: JIT Access, Secret Rotation, and Session Recording
PAM is required in VMware Cloud Foundation for two main reasons. First, many operational tasks require superuser privileges, including domain creation, Distributed Firewall (DFW) policy management, certificate operations, and lifecycle management (LCM). Permanent administrative passwords create a direct path to compromise. Second, even in environments using federated identity providers, local and service accounts still exist — including break-glass accounts, bootstrap accounts, and integration credentials — and these must remain under strict control.
The four core PAM capabilities are:
- Secret management – secure storage and controlled issuance of passwords, keys, and tokens on demand.
- Credential rotation – automated password rotation on schedule or after every use.
- Session recording – proxying and recording of SSH, RDP, and web sessions.
- Just-In-Time (JIT) access — temporary privilege elevation granted through approval workflows.
The following technologies are used to implement PAM in VCF:
- CyberArk PSM – privileged session recording. CyberArk Privileged Session Manager (PSM) proxies and records privileged administrative sessions, including access to the vSphere Client. A dedicated web connector supports vSphere platforms 7.0, 8.0, and 9.0, allowing administrators to work through a monitored proxy session without ever seeing the actual password. Session recordings are temporarily stored locally before being uploaded into the CyberArk vault, while operators receive visible notification that session recording is active.
- HashiCorp Vault – one-time SSH passwords. HashiCorp Vault can generate one-time passwords (OTP) for every SSH session. A helper utility on the target host validates the OTP and immediately invalidates it after use. Every login attempt is logged through the Vault audit device. An intercepted OTP is useless because it has already been consumed.
- BeyondTrust – policy-based credential rotation. BeyondTrust supports both manual and automated credential rotation, including rotation after every use, scheduled rotation policies, and account-level rotation controls. An important consideration is that certain service accounts — such as run-as accounts in failover clusters — may have operational limitations related to password rotation. These scenarios must be validated during testing.
Comparison of PAM approaches:
| Solution | Strengths | Limitations | Primary VCF use case |
|---|---|---|---|
| CyberArk PSM | Session recording, vSphere web connector, vault-based recording storage | Requires PSM/PVWA infrastructure; scalability planning is important | Recording administrator actions in vSphere and NSX, break-glass access control |
| HashiCorp Vault | Dynamic and one-time secrets, TTL-based leases, audit devices | Does not replace session recording; requires policy design | JIT SSH access, CI/CD and automation secrets |
| BeyondTrust | Post-use and scheduled rotation, account-level policies | Limitations for certain service accounts | Password rotation for management components |
In practice, PAM in VCF environments typically operates as follows:
- All local accounts (vCenter, NSX, SDDC Manager, ESX) are stored and rotated through the PAM platform.
- Interactive administrative access is performed through PAM proxies with session recording enabled, especially for web consoles.
- Automation uses minimally privileged service accounts with password rotation, or ephemeral secrets issued through Vault.
Example Vault commands for SSH OTP:
# Enable auditing (all access attempts are logged) vault audit enable file file_path=/var/log/vault_audit.log # Enable the SSH secrets engine vault secrets enable ssh # Configure an OTP role (adjust cidr_list for your network) vault write ssh/roles/vcf-ops-ssh-otp \ key_type=otp \ default_user=vcfops \ cidr_list=10.10.0.0/16 # Generate an OTP for a specific host vault write ssh/creds/vcf-ops-ssh-otp ip=10.10.20.15
Zero Trust: NSX DFW and Microsegmentation
Zero Trust is not a product — it is an architectural discipline. According to NIST SP 800-207, Zero Trust assumes that presence inside the corporate network grants no implicit privilege. Every request to a resource requires explicit authentication and authorization.
For VCF, this translates into four core principles:
- Administrative access is allowed only through federated identity with MFA.
- East-west traffic between virtual machines is inspected and controlled rather than implicitly trusted.
- Security policies are application-centric rather than VLAN-centric.
- All entities — users, services, and devices — must remain continuously observable and verifiable.
NSX Distributed Firewall
The NSX Distributed Firewall (DFW) operates directly in the hypervisor kernel. Security policies move together with workloads during vMotion and DRS operations, remain independent from the guest operating system, and scale linearly across the environment. This provides high-performance Layer 4 filtering directly at the kernel level.
VMware describes the Zero Trust journey with DFW in three stages:
- Zonal segmentation — separation of Production, Development, DMZ, and Shared Services.
- Application segmentation — defining Frontend → Application → Database policies for each business application.
- Microsegmentation — VM-to-VM policies with a deny-by-default model.
DFW rule categories. DFW processes rules in the following order: Ethernet > Emergency > Infrastructure > Environment > Application. VMware recommends designing policies based on traffic type, using tags and dynamic groups extensively, and minimizing the Applied To scope to reduce processing overhead.
vDefend and lateral security. vDefend extends VCF security capabilities through vDefend Firewall and vDefend Firewall with ATP. These services provide comprehensive Zero Trust lateral security capabilities. Within this architecture, DFW acts as the scalable enforcement engine for microsegmentation.
Zero Trust controls in VCF:
| Control | VCF implementation | IAM/PAM integration | ||
|---|---|---|---|---|
| Explicit authentication and MFA | Federated SSO for vCenter, NSX, and VCF Operations | IdP groups mapped to roles; break-glass accounts managed through PAM | ||
| Trust zone minimization | DFW with deny-by-default policies |
|
||
| Application-level segmentation | DFW categories, tags, and dynamic groups | Unified tag taxonomy and audited policy changes | ||
| Observability | Event Auditing and Security Operations in VCF Operations | Correlation with IdP identities and PAM session recordings |
Example NSX policy for application microsegmentation:
# Pseudo-JSON for the NSX Policy API: application microsegmentation
{
"resource_type": "SecurityPolicy",
"display_name": "APP1-Application-Segmentation",
"category": "Application",
"sequence_number": 1000,
"stateful": true,
"rules": [
{
"display_name": "APP1-Allow-Frontend-to-App",
"action": "ALLOW",
"services": [{"destination_ports": ["8443"], "l4_protocol": "TCP"}],
"source_groups": ["/infra/domains/default/groups/APP1-FRONTEND"],
"destination_groups": ["/infra/domains/default/groups/APP1-APP"],
"scope": ["/infra/domains/default/groups/APP1-APP"]
},
{
"display_name": "APP1-Allow-App-to-DB",
"action": "ALLOW",
"services": [{"destination_ports": ["5432"], "l4_protocol": "TCP"}],
"source_groups": ["/infra/domains/default/groups/APP1-APP"],
"destination_groups": ["/infra/domains/default/groups/APP1-DB"],
"scope": ["/infra/domains/default/groups/APP1-DB"]
}
]
}
When validating segmentation policies, VMware recommends using Traceflow and monitoring hit counts before transitioning to a full deny-by-default enforcement model.
Integration Scenarios: IAM + PAM + Zero Trust
These three disciplines are effective only when implemented together. Federation without microsegmentation still allows lateral movement after a single host compromise. Microsegmentation without PAM leaves “standing” passwords available for abuse. PAM without federation results in dozens of unmanaged local accounts operating without MFA protection.
Scenario 1: Multi-Tenancy with isolated SSO domains.
In VCF, it is possible to combine Enhanced Link Mode (ELM) for some domains with Isolated SSO Workload Domains for others, enabling administrative separation between tenants. The VCF FAQ describes Isolated Workload Domains (WLDs) and the ability to centrally enable federated SSO. Key design principles include separate IdP groups for each domain, DFW microsegmentation based on environment and application policies, and administrative isolation that prevents any single administrator from having visibility into all tenant resources.
Scenario 2: VCF 9 Identity Broker with MFA across all consoles
VCF 9 Identity Broker provides unified SSO across all management consoles with support for Entra ID, Okta, Ping, and generic SAML providers.
The recommended security model is:
- MFA enforced at the IdP layer
- Local logins prohibited except for break-glass scenarios
- Roles assigned only to groups, never directly to users
- Privileged sessions allowed exclusively through PAM proxies with session recording enabled
This creates a centralized authentication and authorization boundary for the entire SDDC management plane.
Scenario 3: Secure Day-2 automation with Vault
CI/CD pipelines and automation systems should never store persistent passwords. SSH access to jump hosts is provided through Vault-issued one-time passwords.
DFW policies are managed as code:
- Pull request submission
- JSON/YAML validation
- Deployment through the NSX API using minimally privileged service accounts
- Full audit logging of policy changes
Scenario 4: Responding to credential compromise
When compromise of an administrative account is suspected, the combined IAM + PAM + Zero Trust architecture enables rapid containment:
- IdP — disable the account, enforce step-up MFA, and revoke active sessions.
- PAM — terminate active privileged sessions and rotate local administrative credentials.
- NSX — apply quarantine microsegmentation and block East-West propagation of malicious activity.
- Auditing — reconstruct the sequence of events using PAM session recordings and Event Auditing data in VCF Operations.
Deployment Roadmap and Common Mistakes
Phase 1: IAM
- Select the SSO model: ELM or Isolated Workload Domains.
- Integrate the enterprise IdP and configure MFA/Conditional Access. VCF Operations supports AD FS, Azure AD, Okta, Ping, and OAuth 2.0 providers.
- Create IdP groups and assign roles to those groups in vCenter and NSX.
- Connect vCenter to the corporate identity source using either federation with an external IdP or Active Directory integration through LDAP or IWA.
Phase 2: PAM
- Inventory all local and service accounts across (vCenter, NSX, SDDC Manager, ESX).
- Define a rotation policy (on a schedule or after use). BeyondTrust documents the available options and limitations.
- Enable session recording for high-risk operations. CyberArk PSM provides a connector for vSphere.
Phase 3: Zero Trust Through NSX and vDefend
- Start with zonal segmentation (Prod/Dev/Shared Services), then move to application-level segmentation and microsegmentation. This approach is described in the Well-Architected DFW framework.
- Standardize tags and dynamic groups.
- Enable rule logging for investigations (DFW logging is disabled by default).
Phase 4: Operations and Compliance
- Configure Event Auditing and Compliance Checks in VCF Operations.
- In VCF 9 – use TLS 1.3 by default and adopt desired-state configuration management (VCF 9 Security Blog).
- Test credential rotation procedures in non-production environments
- Document operational runbooks.
Common Mistakes:
- Federation without RBAC. If all federated administrators receive the global Administrator role, the security risk has simply been transferred into the IdP. VMware recommends minimizing use of the Administrator role and creating custom roles instead.
- Forgotten service accounts. The vpxuser account is automatically rotated every 30 days — this must be taken into account when integrating with PAM.
- Deny-all policies without observability. Microsegmentation without monitoring and Traceflow validation frequently causes outages. VMware recommends an iterative implementation model: zones > applications > microsegmentation.
- Credential rotation without testing. Certain service accounts may not support aggressive rotation policies and require validation before production deployment.
- PAM without microsegmentation. Compromise of a jump host (a host used to connect to infrastructure management tools) without DFW enables lateral movement across the entire SDDC.
The end goal is a closed security loop: IdP and RBAC define access, PAM controls privileges, NSX/DFW enforces policies at the resource level, and VCF Operations provides continuous validation and auditability.
Conclusion
Identity Security in VMware Cloud Foundation is not three separate projects — it is a single architectural discipline. IAM eliminates anonymity by binding every action to a verified identity through federation and MFA. PAM secures the unavoidable local and service accounts: credential rotation, JIT access, and session recording transform the “permanent password” from a persistent liability into a controlled operational mechanism. NSX DFW extends the Zero Trust model down to the virtual machine level — even if credentials are compromised, lateral movement is constrained by microsegmentation. The integration works as a unified system: the IdP determines who the user is; RBAC defines what they are allowed to do; PAM controls how privileged access is performed; DFW enforces policy where the actual resource resides.
In practice, the most important principle is to avoid deploying everything simultaneously. Start with federation and strict group-based RBAC. Then bring privileged accounts under PAM control. Introduce microsegmentation gradually: zones, applications, VM-to-VM enforcement. At every stage, observability is critical. Without auditing and logging, security policies become a source of outages rather than a source of protection. VCF 9 — with Identity Broker, TLS 1.3 enabled by default, and built-in compliance checks — simplifies this journey considerably. However, the architectural decisions remain the responsibility of the organization implementing the platform.
from StarWind Blog https://ift.tt/Z81WyJM
via IFTTT
console. Activated with a single click.
