Lateral Security for VMware Cloud Foundation with VMware vDefend

Decision: Deploy SSPI VMs and SSP instances in VCF management domain primary vSphere cluster, or dedicate a vSphere cluster.

Rationale: SSPI and SSP perform management/operational roles for VCF private cloud. Network latency between SSPI, SSP, and NSX Manager cluster must be 10 ms or less.

Implication: Each SSP reserves resources; must properly size mgmt domain.

Component: SSP

Decision: Deploy individual SSPI for each VCF domain (mgmt and workload).

Rationale: SSPI automates SSP deployment/config; single SSPI manages one SSP.

Implication: Individually deploy/manage SSPI per SSP.

Component: SSP

Decision: Deploy individual SSP instances for each NSX Manager domain.

Rationale: Single SSP onboards one NSX Manager cluster.

Implication: SSP per NSX Manager cluster; stay within SSP scalability/concurrency max.

Component: SSP

Decision: Protect SSPI and SSP nodes with vSphere HA.

Rationale: Supports availability objectives without manual intervention on ESX host failure.

Implication: No significant trade-offs identified for this decision.

Component: SSP

Decision: Do not apply vSphere DRS anti-affinity rules for SSP instance nodes.

Rationale: SSP has Machine Health Check (MHC) that monitors/redeploys unhealthy nodes - manual anti-affinity becomes ineffective.

Implication: vSphere DRS remains mandatory on the SSP cluster.

Component: SSP

Decision: When using two availability zones, add SSPI and SSP nodes to VM group for first AZ.

Rationale: Ensures SSP powered on in primary AZ hosts group by default.

Implication: After second AZ implementation, update VM group.

Component: SSP

Decision: Disable Machine Health Check (MHC) on SSP instance.

Rationale: MHC might dynamically redeploy SSP VMs to second AZ if still enabled.

Implication: SSP HA relies on vSphere HA (host health) only, not SSP VM health.

Component: SSP

Decision: Deploy SSP with minimum 5 worker nodes.

Rationale: vDefend license requires minimum 5 workers; more workers increase ingestion capability. Use Host Capacity Dashboard for brownfield sizing.

Implication: Impacts compute/storage requirements of target cluster.

Component: SSP

Decision: Utilize default vSphere resource pool for SSP.

Rationale: Essential to manage compute resources efficiently.

Implication: No significant trade-offs identified for this decision.

Component: SSP

Decision: Deploy SSP with resource reservation enabled.

Rationale: Allocates CPU/Memory for optimal SSP performance.

Implication: If demand exceeds, VM cannot get resources - degradation.

Component: SSP

Decision: Use vSAN Default Storage Policy for vSAN datastores.

Rationale: SSP deployment requires vSphere SPBM; thin provisioning optimizes storage; no need for custom policy.

Implication: No significant trade-offs identified for this decision.

Component: SSP

Decision: For non-vSAN datastores, create SPBM policy using vSphere tag.

Rationale: Tag-based SPBM policies supported by SSP.

Implication: Manual creation or automation needed.

Component: SSP

Decision: Deploy SSPI on VCF VM management network.

Rationale: Ease of management; single IP needed for SSPI.

Implication: VCF VM mgmt network must have sufficient CIDR block.

Component: SSP

Decision: Deploy SSP instances on dedicated network (DVPG, NSX Segment, or VPC Public subnet).

Rationale: Single SSP requires 23 IP addresses for max-scale deployment; allows proper IP space design.

Implication: Network created manually or via automation; physical fabric routes traffic.

Component: SSP

Decision: Configure A + PTR DNS records for SSPI and SSP.

Rationale: SSP accessible via FQDN.

Implication: DNS must be available; must manage DNS records.

Component: SSP

Decision: Configure SSP to use NTP servers.

Rationale: Time synchronization to avoid time mismatch with VCF.

Implication: NTP services must be available.

Component: SSP

Decision: Segment VCF mgmt domain components with vDefend DFW Environment-level protection aligned to VCF infrastructure boundaries.

Rationale: Attack surface reduction; isolation without deep app knowledge.

Implication: Create NSX security groups manually or via automation in advance.

Component: MD

Decision: For mgmt domain and each workload domain vCenter, create individual group with dynamic VM name membership.

Rationale: SDDC Manager performs Reduced Downtime Upgrade (RDU) by default - instantiates new vCenter VM, migrates DB, stops/deletes original. NSX tag lost during RDU.

Implication: Grouping based on VM names requires strict naming convention.

Component: MD

Decision: For mgmt + workload domains, create individual groups with dynamic NSX tag membership for NSX Managers, Avi Controllers, SSP Installer.

Rationale: Best flexibility for dynamic security posture; abstraction from underlying topology; facilitates dynamic DFW policy config.

Implication: Define and apply NSX tags manually/automation; tagging can be

Component: MD

Decision: For SSP instance, create groups using dynamic VM Name membership (Starts With SSP instance prefix).

Rationale: SSP instance name added as prefix to each node; dynamic addition during scale-out; rules auto-apply to new nodes.

Implication: More NSX groups to manage.

Component: MD

Decision: Create group using dynamic DVPG membership for VCF01_MGMT (VCF VM management network DVPG).

Rationale: Facilitates vCenter RDU.

Implication: More NSX groups to manage.

Component: MD

Decision: Use static IP membership for each VCF workload domain ESX hosts mgmt VMkernel, NSX Edge Nodes, IP-based Storage.

Rationale: These objects are outside mgmt domain DFW scope of enforcement.

Implication: Manual group creation is cumbersome.

Component: MD

Decision: For IP-based groups, use entire dedicated CIDR block instead of individual IPs.

Rationale: Simplifies DFW policy LCM for host commissioning, new workload domains/clusters, Edge node deployment.

Implication: VCF IP schema must be precisely architected in advance.

Component: MD

Decision: For each workload domain, create nested group of mgmt components + ESX + Edge + IP-storage using tag scope + child groups + static inclusion.

Rationale: Optimize DFW policy computation during publishing.

Implication: More NSX groups.

Component: MD

Decision: Lifecycle management of VMware vDefend DFW is via overall VCF lifecycle.

Rationale: Built into VCF; no separate LCM.

Implication: No significant trade-offs identified for this decision.

Component: MD

Decision: Lifecycle management of SSP via SSP Installer.

Rationale: SSPI hosts deployment packages and manages upgrades.

Implication: SSPI must be operational to perform LCM tasks.

Component: SSP

Decision: Replace default self-signed certificate in SSP with CA-signed certificate.

Rationale: Ensures encrypted communication for externally facing Web UI and cross-product integration.

Implication: Must have access to PKI.

Component: VDF

Decision: Use service accounts for SSP-to-NSX integration with least privilege.

Rationale: Application-to-application communication accountability; limits blast radius of compromise.

Implication: Maintain service account lifecycle outside VCF.

Component: VDF