Appendix: Design Decisions on Private Cloud Automation for VMware Cloud Foundation

The design decisions determine the deployment configuration, resource sizing, and automation support of vRealize Automation in the SDDC.

Deployment Specification

Table 1. Design Decisions on Deployment of vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CFG-001	Deploy vRealize Automation as a cluster of three nodes in the default management vSphere cluster.	vRealize Automation can manage one or more VMware Cloud Foundation instances from a single implementation. The vRealize Automation deployment can also manage VMware Cloud on AWS and public cloud instances, if network access is permitted.	You must deploy the clustered Workspace ONE Access nodes as medium-size appliances to support the scalability of the vRealize Automation cluster deployment.​ You must maintainvRealize Automation within its scalability and concurrency maximums.
PCA-VRA-CFG-002	Deploy vRealize Automation in a vRealize Suite Lifecycle Manager logical environment in VMware Cloud Foundation mode.	The vRealize Automation cluster is added to the SDDC Manager inventory for life cycle management. SDDC Manager automates the configuration of the NSX load balancer on a dedicated NSX Tier-1 gateway in the management domain to load balance the connections across the vRealize Automation cluster nodes.	You must deploy vRealize Automation in a cluster configuration. You must use NSX-T Data Center for vRealize Automation cluster load-balancing services. Only a single vRealize Automation deployment can be deployed in VMware Cloud Foundation mode and imported into the SDDC Manager inventory.
PCA-VRA-CFG-003	Protect the vRealize Automation cluster virtual machines by using vSphere High Availability.	Supports the availability objectives for vRealize Automation without requiring manual intervention during an ESXi host failure event.	None.
PCA-VRA-CFG-004	Apply vSphere Distributed Resource Scheduler anti-affinity rules for the vRealize Automation cluster virtual machines.	vSphere Distributed Resource Scheduler prevents the vRealize Automation cluster virtual machines from residing on the same ESXi host and risking the high availability of the deployment.	You must perform an additional configuration to set up an anti-affinity rule. For a default management vSphere cluster that consists of four ESXi hosts, you can put in maintenance mode only a single ESXi host at a time.
PCA-VRA-CFG-005	Add a VM group for the vRealize Automation cluster virtual machines and set a VM rule to restart the Workspace ONE Access VM group before the vRealize Automation VM group.	You can define the startup order of virtual machines regarding the service dependency. The startup order ensures that vSphere High Availability powers on the virtual machines for vRealize Automation in an order that respects product dependencies.	You must manage the VM group and VM rules for the vRealize Automation cluster virtual machines.
PCA-VRA-CFG-006	Place the vRealize Automation cluster virtual machines in a designated virtual machine folder.	Provides the organization of the vRealize Automation cluster virtual machines in the management domain vSphere inventory.	You must create the virtual machine folder during or after the deployment.

Table 2. Design Decisions on Deployment of vRealize Automation in Multiple Availability Zones

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CFG-007	When using two availability zones, add the vRealize Automation cluster virtual machines to the VM group for the first availability zone.	Ensures that, by default, the vRealize Automation cluster virtual machines are powered on in the primary availability zone hosts group.	After the implementation of the second availability zone for the management domain, you must update the VM group for the primary availability zone virtual machines to include the vRealize Automation cluster virtual machines. You must update the VM group for the primary availability zone virtual machines to also include the Workspace ONE Access cluster virtual machines, which are a dependency.

Table 3. Design Decisions on Sizing of vRealize Automation Sizing

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CFG-008	Deploy the vRealize Automation cluster nodes as medium-size or larger appliances.	A medium-size vRealize Automation appliance is typically sufficient, but can be scaled-up for increased workload scalability.	The ESXi hosts in the default management vSphere cluster must have physical CPUs with a minimum of 8 cores per socket. In total, the vRealize Automation cluster uses 36 vCPUs and 126 GB of memory in the default management vSphere cluster. When you exceed the scalability and concurrency of the medium-size profile, scale up the cluster nodes size by using vRealize Suite Lifecycle Manager.

Network Design

Table 4. Design Decisions on the Network Segment for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-001	Place the vRealize Automation cluster nodes on the cross-instance NSX network segment.	Provides a consistent deployment model for management applications and a potential to extend to a second VMware Cloud Foundation instance for disaster recovery.	You must use an implementation of NSX-T Data Center to support this networking configuration.

Table 5. Design Decisions on the IP Addressing for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-002	Allocate statically assigned IP addresses from the cross-instance NSX segment to the vRealize Automation cluster nodes and the NSX load balancer virtual server.	Using statically assigned IP addresses ensures stability of the deployment and makes it simpler to maintain and easier to track.	Requires precise IP address management.

Table 6. Design Decisions on Name Resolution for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-003	Configure forward and reverse DNS records for each vRealize Automation cluster node IP address and for the NSX load balancer virtual server IP address.	vRealize Automation is accessible by using a fully qualified domain name instead of by using IP addresses only.	You must provide DNS records for each vRealize Automation cluster node and the NSX load balancer virtual server IP address. Firewalls between the vRealize Automation cluster nodes and the DNS servers must allow DNS traffic.
PCA-VRA-NET-004	Configure DNS servers for each vRealize Automation cluster node.	Ensures that vRealize Automation has accurate name resolution on which its services are dependent.	DNS infrastructure services should be highly-available in the environment. Firewalls between the vRealize Automation cluster nodes and the DNS servers must allow DNS traffic. You must provide two or more DNS servers unless a DNS geographic load balancing is activated.

Table 7. Design Decisions on Load Balancing for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-005	Use the small-size NSX load balancer that is configured by SDDC Manager on the dedicated NSX Tier-1 gateway in the management domain to load balance the clustered Workspace ONE Access deployment, to also load balance the connections across the vRealize Automation cluster nodes.	Required to deploy vRealize Automation as a cluster deployment type. The vRealize Automation cluster can handle a greater load and obtain a higher level of service availability. During the deployment of vRealize Automation by using vRealize Suite Lifecycle Manager, SDDC Manager automates the configuration of the NSX load balancer for the vRealize Automation cluster on a standalone NSX Tier-1 gateway.	You must use the NSX load balancer that is configured by SDDC Manager and the integration with vRealize Suite Lifecycle Manager to support this network configuration.

Table 8. Design Decisions on Time Synchronization for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-NET-006	Configure NTP servers for each vRealize Automation cluster node.	Ensures that vRealize Automation has accurate time synchronization on which its services are dependent. Assists in the prevention of time mismatch between the vRealize Automation nodes and dependencies.	NTP infrastructure services should be highly-available in the environment. Firewalls between the vRealize Automation cluster nodes and the NTP servers must allow NTP traffic. You must provide two or more NTP servers unless an NTP geographic load balancing is activated.

Life Cycle Management

Table 9. Design Decisions on the Life Cycle Management of vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-LCM-001	For VMware Cloud Foundation 4.4, use vRealize Suite Lifecycle Manager to perform the life cycle management of vRealize Automation. For VMware Cloud Foundation 4.3.1 and earlier, use SDDC Manager to apply vRealize Automation upgrades.	For VMware Cloud Foundation 4.4, vRealize Suite Lifecycle Manager manages the product binaries and vRealize Automation upgrades. For VMware Cloud Foundation 4.3.1 and earlier, SDDC Manager provides the upgrade bundles to vRealize Suite Lifecycle Manager and manages vRealize Log Insight upgrades through the integration with vRealize Suite Lifecycle Manager.	You must deploy vRealize Suite Lifecycle Manager by using SDDC Manager. vRealize Suite Lifecycle Manager manages patches, updates, and hot fixes for vRealize Automation.
PCA-VRA-LCM-002	Use vRealize Suite Lifecycle Manager to apply vRealize Automation patches and hot fixes.	Patches, updates, and hot fixes for vRealize Automation are not managed by SDDC Manager.	Before applying the updates to vRealize Automation, you must use vRealize Suite Lifecycle Manager to automate the download or manually upload the product binaries to vRealize Suite Lifecycle Manager.

Cloud Assembly Design

Table 10. Design Decisions on Tagging for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-001	Establish and publish a well-defined strategy, implementation, and taxonomy for the tagging of cloud resources.	With capability and constraint tags, you can organize and activate cloud resources and profiles for resource consumption by using the declarative nature of cloud templates to define deployment configurations.	Your strategy must account for external tags, for example, vSphere and NSX-T Data Center tags, and internal user-defined tags managed through Cloud Assembly.
PCA-VRA-CA-CFG-002	Apply constraint tags to the cloud template YAML structure.	During a provisioning operation, capabilities are matched with constraints, each expressed as tags, in cloud templates and images to determine the deployment configuration.	You must manage the capability tags on your cloud resources, such as cloud zones, storage and storage profiles, networks and network profiles.

Table 11. Design Decisions on Cloud Accounts for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-003	Add a cloud account for the vCenter Server instance for each VI workload domain in each VMware Cloud Foundation instance.	You can integrate the vCenter Server instance for each VI workload domains with vRealize Automation for provisioning.	You must manage the cloud account credentials and the life cycle management of the related service accounts. You must manage capability tags for the cloud account.
PCA-VRA-CA-CFG-004	Add a cloud account for the NSX Manager cluster for each VI workload domain in each VMware Cloud Foundation instance. Note: For an environment with NSX Federation, add a cloud account for each VI workload domain NSX Local Manager cluster.	You can integrate the NSX Manager cluster for one or more VI workload domains with vRealize Automation for provisioning.	You must manage the cloud account credentials and the life cycle management of the related service accounts. vRealize Automation supports adding more than one vCenter Server cloud account that shares an NSX Manager cluster. If using an NSX Manager cluster for more than one vCenter Server cloud account, you must manage the NSX Manager-to-vCenter Server associations in the NSX Manager cloud accounts. You must manage capability tags for the cloud account. Each member of an NSX Manager cluster has a certain scalability - the main limit is 199 concurrent API sessions. An NSX Manager cluster assigns the cluster VIP to a single NSX Manager cluster member at any given time. All API requests from vRealize Automation are directed to this cluster member through the NSX-T cloud account. For environments that require a higher concurrent API session count, an external load balancer is required to distribute the API sessions across all NSX Manager cluster members for the workload domain.
PCA-VRA-CA-CFG-005	Use the default POLICY mode for each NSX-T Manager cloud account.	Ensures that all NSX-T Data Center entities created by vRealize Automation use the Policy API instead of the legacy Manager API. There is no migration path from MANAGER mode to POLICY mode.	None.

Table 12. Design Decisions on Cloud Zones for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-006	Create a cloud zone for each VI workload domain.	Provides provisioning on a specific workload domain.	None.
PCA-VRA-CA-CFG-007	Add tags to each cloud zone.	Ensures that deployments can be targeted for a designated cloud account region.	You must ensure that you manage the tagging of cloud zones. You must ensure that constraint tags are included in the cloud template YAML if a cloud account region-specific targeting is required.
PCA-VRA-CA-CFG-008	For each cluster added to a VI workload domain, add tags to the vSphere cluster.	Ensures that, as you add new vSphere clusters to a VI workload domain, you can dynamically include compute resources for workload provisioning by adding the appropriate tags. Ensures that deployments can be targeted for designated clusters of the VI workload domain.	You must ensure that you manage the tagging of compute resources as you add clusters to a VI workload domain. You must ensure that constraint tags are included in the cloud template YAML. If resource pools must be activated in a VI workload domain, add tags only to the required resource pools in the VI workload domain clusters for cloud zones.
PCA-VRA-CA-CFG-009	Add a workload folder in the vCenter Server data center for each VI workload domain.	Ensures that cloud templates that do not include the folderName value are deployed in a default workload folder.	You must add the default workload folder to all VI workload domains. To override the default folder, you must add logic in your cloud template YAML code to deploy cloud templates in alternative folders. Note: The destination folder, where the cloud templates are deployed, must exist. The destination folder cannot be created by Cloud Assembly without extensibility.
PCA-VRA-CA-CFG-010	Use the DEFAULT placement policy for each cloud zone, by default.	All vSphere clusters have the vSphere Distributed Resource Scheduler activated to optimize initial and ongoing workload placement within a cluster. The ADVANCED option is supported only when vRealize Automation is integrated to vRealize Operations Manager and is monitoring the VI workload domain vCenter Server.	Does not provide advanced workload placement across cloud zones and the related cloud accounts.

Table 13. Design Decisions on Integrations for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-011	Use the default integration to the vRealize Orchestrator cluster that is embedded in vRealize Automation.	The use of the embedded vRealize Orchestrator cluster has the following advantages over the use of an external vRealize Orchestrator instance: Operates in cluster mode. Provides a faster time to value. Reduces the number of appliances to manage. Provides an easier upgrade path and better supportability. Improves performance. Removes the requirement for an external database. Using the embedded instance of vRealize Orchestrator is applicable in most use cases. For information about the use cases for using the external vRealize Orchestrator, refer to the product documentation.	It might be less efficient to run a workflow in a multi-instance deployment from a centralized cluster. However, it is simpler to manage.

Table 14. Design Decisions on Projects for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-012	For each project, add one or more cloud zones based on the project requirements and allowed cloud resources.	Provides one or more cloud zones and their resources for project consumption.	None.
PCA-VRA-CA-CFG-013	For each project, set a provisioning priority for each cloud zone based on your deployment prioritization.	Prioritizes one cloud zone over another within a project. The default priority is 0 (highest priority).	You must manage the provisioning priority for each cloud zone in each project.
PCA-VRA-CA-CFG-014	For each project, set limits for the project cloud zones as required.	Sets the maximum number of workload instances and resources provisioned in the cloud zone for the project. The default limit is 0 (unlimited).	If a value greater than 0 (unlimited) is used for the instance or resource limit, you must manage the limit for each cloud zone in each project when requirements change.
PCA-VRA-CA-CFG-015	For each project, specify network, storage, and extensibility constraints that must be applied to all requests in the project.	Ensures proper placement of the workloads in a project and its cloud zones.	If the same constraint or the same constraint category is specified in both the project, for example, region:us-west-1, and the cloud template, for example, region:us-east-1, the constraint specified in the project takes precedence, for example, region:us-west-1.
PCA-VRA-CA-CFG-016	For each project, add one or more custom properties, for example, project:foo.	Custom properties can be used for provisioning or capturing additional metadata. For example, for reporting or extensibility actions.	If the same custom property is specified in both the project, for example, project:foo, and the cloud template, for example, project:bar, the property value specified in the project takes precedence, for example, project:foo.
PCA-VRA-CA-CFG-017	For each project, add a custom naming template to be used for virtual machine names provisioned in the project.	The template provides a custom virtual machine name and does not affect the host name of the virtual machine. Note: Custom naming can also be managed using extensibility.	The template substitutes auto-generated virtual machine names by using available properties, such as resource properties, custom properties, endpoint properties, project properties, and a random number with a specified number of digits. You must ensure that the template generates unique names for this project and between other projects.

Table 15. Design Decisions on Flavor Mappings for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-018	Create standardized flavor mappings based on a common taxonomy and deployment intent.	Provides a simple, natural language naming to define common deployment size specifications.	You must publish and communicate the updates to cloud template developers and consumers.
PCA-VRA-CA-CFG-019	For each flavor mapping, add all applicable account regions.	Provides a simple, natural language naming to define common deployment size specifications when used in a specific account region.	You must maintain the mapping for any image mapping create or update operation.

Table 16. Design Decisions on Image Mappings for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-020	Use the vSphere content library to synchronize machine images across VI workload domains and VMware Cloud Foundation instances.	The vSphere content library is built into vSphere and meets all the requirements to synchronize machine images across VI workload domains and VMware Cloud Foundation instances. vRealize Automation can consume both Open Virtual Format (OVF) images or virtual machine templates from the vSphere content library. Open source solutions, such as HashiCorp Packer, can be use to build machine images in the virtual machine template and OVA formats.	The vSphere content library permissions are connected to global permissions in the permissions hierarchy. To allow Cloud Assembly to synchronize and use images in the content library, the user and role must be applied at the global permissions level. You must provide storage space for machine images. You must ensure that the service account used for the cloud account for vCenter Server has the minimum required permissions to consume machine images from the vSphere content library. You must ensure that the number, size, and structure of the machine images are kept within the vSphere content library configuration maximums. You must ensure HTTPS communications between all VI workload domain vCenter Server instances. Deployment of OVF-based machine images from the vSphere content library might be slower than cloning of native vSphere templates. Deployment of VM template-based machine images from the vSphere content library might be impacted during host maintenance/failure or until ownership update and vRealize Automation image collection updates.
PCA-VRA-CA-CFG-021	Create standardized image mappings based on similar operating systems, functional deployment intent, and cloud zone availability.	You can create a simple taxonomy to map images to cloud templates.	You must publish and communicate the image-mapping standards and updates to cloud template developers.
PCA-VRA-CA-CFG-022	For each machine image in an image mapping, add a constraint tag, if applicable.	Refines the machine image selection in an image mapping by matching constraints.	You must manage multiple machine images in each account region based on the use of constraint tags in your organization.

Table 17. Design Decisions on Network Profiles for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-023	For each account region, add one or more network profiles based on network characteristics available for consumption.	You can add networks with predefined characteristics that can be consumed during a deployment process.	You must manage network profiles for each account region as updated across VMware Cloud Foundation instances.
PCA-VRA-CA-CFG-024	For each network in a network profile, add one or more capability tags.	You use capability tags to manage the workload network placement logic during the deployment process.	You must manage capability tagging on each network profile for workflow placement selection during a deployment process.

Table 18. Design Decisions on Storage Profiles for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-025	For each account region, add one or more storage profiles based on storage characteristics available for consumption.	You can add storage with defined characteristics that can be consumed during a deployment process.	You must manage storage profiles for each account region as storage is added, removed, and updated across VMware Cloud Foundation instances.
PCA-VRA-CA-CFG-026	For each storage profile, add one or more capability tags.	You use capability tags to manage the workload storage placement logic during the deployment process.	You must manage capability tagging on each storage profile for the workflow placement logic during a deployment process.

Table 19. Design Decisions on Action-Based Extensibility for Cloud Assembly in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-CA-CFG-027	Use the embedded on-premises functions-as-a-service (FaaS) provider in vRealize Automation for action-based extensibility.	You can use the native vRealize Automation functions-as-a-service provider for the execution of lightweight actions through event subscriptions without the requirement for a public cloud account provider, such as Amazon Web Services Lambda or Microsoft Azure Functions.	The use of action-based extensibility requires the vRealize Automation instance to have outbound access to the Internet to pull container images from publicly available Internet repositories, for example, to resolve any dependencies included in the actions. If vRealize Automation is deployed on an isolated network that does not allow outbound traffic to the Internet, an HTTP proxy must be configured and applied using the vracli proxy command option.

Service Broker Design

Table 20. Design Decisions on Content Sources for Service Broker in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SB-CFG-001	Add a cloud template content source for each Cloud Assembly project where cloud templates are authored and released.	Provides the ability to share released cloud templates with project members or other projects.	None.
PCA-VRA-SB-CFG-002	Add an extensibility actions content source for each Cloud Assembly project where actions are authored and released.	Provides the ability to share released actions with project members.	None.
PCA-VRA-SB-CFG-003	Add a vRealize Orchestrator workflows content source for each Cloud Assembly project, as required.	Provides the ability to share specific workflows with project members.	None.

Table 21. Design Decisions on Content Customization for Service Broker in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SB-CFG-004	For each shared content item, customize the form based on the catalog item and user experience requirements.	You can create an intuitive user experience by using simple and discoverable forms that capture additional user inputs and in-form validations.	Requires customization of request forms per catalog item.

Table 22. Design Decisions on Policies for Service Broker in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SB-CFG-005	Identify and apply goals for your organization and each project based on the applicability of available policy types.	By understanding how the policies are processed, you can meet organizational goals without creating an excessive and unmanageable number of policies.	For each policy type, you must determine the applicability and your organizational goals to design policy enforcement and scope that results in the desired effective policy.

Table 23. Design Decisions on Notifications for Service Broker in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SB-CFG-006	Configure Service Broker to use an outbound (SMTP) mail server to route notifications for system events.	vRealize Automation event notifications are provided by email for an enhanced user experience.	You must configure an SMTP server to relay messages from vRealize Automation.

vRealize Orchestrator Design

Table 24. Design Decisions on vCenter Server Plug-In for vRealize Orchestrator in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-VRO-CFG-001	Register each VI workload domain vCenter Server instance with the embedded vRealize Orchestrator instance. Do not use per session authentication.	Required for communication from the embedded vRealize Orchestrator to the VI workload domain vCenter Server instances.	You cannot use per-session authentication for vRealize Orchestratorr communication to vSphere, because vCenter Server does not accept the token from vRealize Automation and the registration. When VI workload domains are added or removed, you must add or remove the vCenter Server instance in vRealize Orchestrator. When the service account password changes during its life cycle, you must run the Update a vCenter Server Instance workflow with updated credentials.

Information Security and Access Control Design

Table 25. Design Decisions on Identity Management for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SEC-001	Limit the use of the local accounts for both interactive or API access and solution integration.	Local accounts are not specific to user identity and do not offer complete auditing from an endpoint back to the user identity.	You must define and manage service accounts, security groups, group membership, and security controls in Active Directory.
PCA-VRA-SEC-002	Limit the scope and privileges for accounts used for both interactive or API access and solution integration.	The principle of least privilege is a critical aspect of access management and must be part of a comprehensive defense-in-depth security strategy.	You might need to define and manage custom roles and security controls to limit the scope and privileges used for interactive access or solution integration.
PCA-VRA-SEC-003	Assign Active Directory user accounts to security groups following your organization's access policies	Allows Active Directory security groups to be assigned to roles in SDDC components for streamlined management of access and administrative privileges.	You must define and manage security groups, group membership, and security controls in Active Directory.
PCA-VRA-SEC-004	Assign Active Directory security groups to default or custom roles, as applicable, for interactive or API access to solution components based on your organization's business and security requirements.	Using Active Directory security group membership provides greater flexibility in granting access to roles across solution components. Ensuring that each user logs in with a unique Active Directory user account provides greater visibility for auditing. Each organization has its own internal processes. Evaluate the needs for additional role separation in your organization and implement mapping from Active Directory users to Active Directory security groups and default or custom roles.	You must manage the privileges assigned to custom roles. You must manage the assignment and scope of the based on the business and security requirements. Additional Active Directory security groups must be created in advance to assigning roles. You must maintain the life cycle and availability of Active Directory security groups outside of the SDDC stack. The principle of least privilege is only one aspect of access management and should be part of a comprehensive defense-in-depth security strategy that's aligned with organization personas.
PCA-VRA-SEC-005	Activate vRealize Automation integration with Active Directory by using the clustered Workspace ONE Access deployment.	Allows authentication for vRealize Automation using Active Directory as the identity provider. Allows authorization through the assignment of both vRealize Automation organization and service roles to users and security groups defined in Active Directory.	You must deploy and configure the clustered Workspace ONE Access nodes to establish the integration between vRealize Automation and Active Directory. The clustered Workspace ONE Access deployment must be sized and scaled to support the vRealize Automation size and scale.
PCA-VRA-SEC-006	Assign vRealize Automation organization service and project roles to designated Active Directory. security groups synchronized to the clustered Workspace ONE Access deployment.	By assigning Active Directory security groups to organization and service roles, you can simplify and manage user access to vRealize Automation based on the Active Directory security group membership.	You must define and manage the security groups, group membership, and security controls in Active Directory for those directory services objects used by vRealize Automation.

Table 26. Design Decisions on Service Accounts for Cloud Assembly Cloud Accounts in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SEC-007	Define a custom vCenter Server role for vRealize Automation that has minimum privileges required to support a vCenter Server cloud account.	vRealize Automation integrates with VI workload domain vCenter Server instances in VMware Cloud Foundation instances using the minimum set of privileges and permissions scope required to support the cloud account.	You must maintain the privileges required by the custom vSphere role. If additional VMware Cloud Foundation instances are not in the same vCenter Single Sign-On domain, the custom role must be applied to each vCenter Single Sign-On domain.
PCA-VRA-SEC-008	For each VMware Cloud Foundation instance, use an Active Directory user account as a service account for each vCenter Server for application-to-application communication from vRealize Automation to vCenter Server.	Provides the following access control features: vRealize Automation services, such as Cloud Assembly, access VI workload domain vCenter Server instances with the minimum set of required permissions. If there is a compromised account, the accessibility to the destination cloud account remains restricted. You can introduce an improved accountability in tracking request-response interactions between the vRealize Automation and the vCenter Server endpoint in the cloud account.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. You must maintain the scope of permissions assigned to the service account across the VMware Cloud Foundation instances. To reduce the potential fault domain for a cloud account, you can create a service account per VI workload domain for the vCenter Server cloud account.
PCA-VRA-SEC-009	Assign vCenter Server global permissions for the vRealize Automation-to-vCenter Server integration accounts for each VMware Cloud Foundation instance.	vRealize Automation accesses VI workload domain vCenter Server instances with the minimum set of permissions that are required to support a vCenter Server cloud account.	You must set the permissions scope for the service account used by the vCenter Server cloud account to the default No access vSphere role for the management domain vCenter Server instances or other VI workload domains not used by vRealize Automation, to ensure that service account access to the workload domains is restricted. You must set the permissions scope for the service account used by the vCenter Server cloud account to the default No access vSphere role for vSphere inventory objects that should be excluded from vRealize Automation workload placement or on-boarding. To reduce the potential fault domain for a cloud account, you can create a service account per VI workload domain for the vCenter Server cloud account.
PCA-VRA-SEC-010	Use an Active Directory user account as an integration account for each NSX Manager cluster for application-to-application communication from vRealize Automation to NSX-T Data Center.	Provides the following access control features: vRealize Automation services, such as Cloud Assembly, accesses NSX Manager with the minimum set of required permission. If there is a compromised account, the accessibility to the destination cloud account remains restricted. You can introduce an improved accountability in tracking request-response interactions between the vRealize Automation and the NSX Manager endpoint in the cloud account.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. To reduce the potential fault domain for a cloud account, you can create a service account per VI workload domain for the NSX-T cloud account. Important: This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for NSX Manager, vRealize Automation cannot authenticate to an NSX Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The username and password cannot be sent over SAML to the identity provider for authentication.
PCA-VRA-SEC-011	Assign the NSX Manager Enterprise admin role to the vRealize Automation-to-NSX-T Data Center integration accounts for VI workload domains.	vRealize Automation accesses designated VI workload domain NSX Manager clusters in VMware Cloud Foundation instances with the minimum set of permissions that are required to support NSX-T Data Center in the NSX Manager cloud accounts.	You must configure and manage the integration of Workspace ONE Access with NSX-T Data Center. Important: This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for NSX Manager, vRealize Automation cannot authenticate to NSX Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The user name and password cannot be sent over SAML to the identity provider for authentication.

Table 27. Design Decisions on Service Accounts for vRealize Orchestrator in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SEC-012	For each VMware Cloud Foundation instance, use an Active Directory user account as a service account for each VI workload domain vCenter Server for application-to-application communication from vRealize Orchestrator to vCenter Server.	Provides the following access control features: vRealize Orchestrator services access VI workload domain vCenter Server instances with the minimum set of required permissions. If there is a compromised account, the accessibility to the destination integration remains restricted. You can introduce an improved accountability in tracking request-response interactions between the vRealize Orchestrator and the vCenter Server instances.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. You must maintain the scope of permissions assigned to the service account across VMware Cloud Foundation instances. To reduce the potential fault domain for the integration, you can create a service account per VI workload domain for the vRealize Orchestrator integration.
PCA-VRA-SEC-013	Add the integration account used for application-to-application communication between vRealize Orchestrator and vCenter Server to an Active Directory security group. Add any named users to the Active Directory security group.	Allows only accounts defined in the Active Directory security group membership to administer the vRealize Orchestrator instance.	You must define and manage security groups, group membership, and security controls in Active Directory.
PCA-VRA-SEC-014	Create and apply a custom vSphere role for the service account used to add VI workload domain vCenter Server instances to the vRealize Orchestrator configuration.	vRealize Orchestrator integrates with VI workload domain vCenter Servers instances using the minimum set of privileges required to support the vCenter Server registration.	You must maintain the privileges required by the custom vSphere role. If additional VMware Cloud Foundation instances are not in the same vCenter Single Sign-On domain, the custom role must be applied to each vCenter Single Sign-On domain. vRealize Orchestrator requires Administrator-level privileges to register a vCenter Server instance with vRealize Orchestrator and can not be restricted based a registration account and another with the privileges required by workflows executed against VI workload domain vCenter Server instances. After the addition of VI workload domain, you can decide to update and reduce the privileges for the custom role.
PCA-VRA-SEC-015	Assign vCenter Server global permissions for the vRealize Orchestrator-to-vCenter Server integration accounts for VMware Cloud Foundation instance workload domains.	vRealize Orchestrator registers VI workload domain vCenter Servers instances with the required set of permissions. vRealize Orchestrator can register a VI workload domain vCenter Server when added to a VMware Cloud Foundation instance.	You must set the permissions scope for the service account used by vRealize Orchestrator to the default No access vSphere role for the management domain vCenter Server instances to ensure that service account access to the management domains is restricted. You should set the permissions scope for the service account used by the vRealize Orchestrator to the default No access vSphere role for vSphere inventory objects that should be excluded from vRealize Orchestrator scope. If additional VMware Cloud Foundation instances are not in the same vCenter Single Sign-On domain, the service account scope must be applied to each VMware Cloud Foundation instance.

Table 28. Design Decisions on Password Management for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SEC-016	Change the vRealize Automationroot password on a recurring or event-initiated schedule by using the SDDC Manager user interface or API.	By default, the password for the vRealize Automationroot account expires every 365 days. When vRealize Automation is deployed into a VMware Cloud Foundation environment in vRealize Suite Lifecycle Manager, the root password is managed from the SDDC Manager user interface or API, not vRealize Suite Lifecycle Manager.	By using SDDC Manager, you manage the password change or automation password rotation schedule for the vRealize Automationroot account in accordance with your organizational policies and regulatory standards.

Table 29. Design Decisions on Certificates for vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SEC-017	Use a certificate authority signed certificate containing the FQDNs of the vRealize Automation cluster nodes and the virtual server FQDN in the SAN attributes, when deploying vRealize Automation.	Ensures that all communications to the externally facing vRealize Automation browser-based UI and API, and between the components, are encrypted.	Using certificates signed by a certificate authority might increase the deployment preparation time as certificate requests are generated and delivered. You must manage the life cycle of the certificate replacement by using vRealize Suite Lifecycle Manager. If multi-tenancy is activated for vRealize Automation, the on-boarding of tenants requires a service interruption for all tenants during certificate replacement.
PCA-VRA-SEC-018	Use a SHA-2 or higher algorithm for certificate signing.	The SHA-1 algorithm is considered less secure and has been deprecated.	Not all certificate authorities support SHA-2 or higher.

Table 30. Design Decisions on Trusted Certificates for vRealize Orchestrator in vRealize Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-SEC-019	Import the certificate authority root certificate to the embedded vRealize Orchestrator instance in vRealize Automation.	Ensures that the certificate for each VI workload domain vCenter Server instance is trusted by the embedded vRealize Orchestrator instance in vRealize Automation. Ensures that other endpoints with certificates issued from the same certificate authority, for example, NSX Manager and vRealize Operations Manager, are trusted.	If the certificate authority certificate is reissued, you must import an updated certificate to the embedded vRealize Orchestrator instance in vRealize Automation.

Solution Interoperability Design

Table 31. Design Decisions on Monitoring and Alerting for Private Cloud Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-MON-001	Configure the vRealize Automation integration in vRealize Operations Manager.	Provides the ability to share common constructs, such as cloud accounts, cloud zones, and projects, across vRealize Operations Manager and vRealize Automation. Provides the ability to understand the deployment cost. Evaluate upfront costs on vRealize Automation. Monitor ongoing costs per virtual machine, deployment, or project.	You must manage the password life cycle of this endpoint.
PCA-VRA-MON-002	Configure the vRealize Automation integration in vRealize Operations Manager to use the default collector group.	Cross-instance components are configured to use the default collector group.	The load on the analytics cluster, though minimal, increases.
PCA-VRA-MON-003	Add an integration in Cloud Assembly for vRealize Operations Manager deployment.	You can use data from vRealize Operations Manager in vRealize Automation to display live vSphere-based virtual machine metrics for CPU, memory, storage IOPS, and network MBps after placement. Metrics for the past day, week, or month are available. You can use data from vRealize Operations Manager in vRealize Automation to apply and display the cost estimation at the time of deployment and over time.	When configuring the integration, you must use a service account that is created for application-to-application integration for vRealize Automation to vRealize Operations Manager. When the service account password is updated, you must manage the service account password in the integration configuration. You must configure vRealize Operations Manager with vRealize Automation to ensure that both applications are set to the same time zone. vRealize Automation uses only UTC. You must configure vRealize Operations Manager with a currency setting to consume the vRealize Operations Manager cost engine for vRealize Automation cost estimation. The vRealize Operations Manager integration is not used for workload placement in this design. The integration does not support resource pools in vCenter Server or vSAN datastores for workload placement. Project costs include only the costs for private cloud workloads. If a project contains deployments that belong to public clouds, the costs for these deployments are not included in the project cost.
PCA-VRA-MON-004	Use the ADVANCED placement policy for each vRealize Automation cloud zone that is monitored by vRealize Operations Manager.	By default, the workload placement evaluation uses the vRealize Operations Manager recommendation.	You must integrate vRealize Automation with vRealize Operations Manager in Cloud Assembly. The ADVANCED option for vRealize Operations Manager does not support workload placement when resource pools in vCenter Server for workload placement are in use. If resource pools must be activated in a workload domain, the workload placement falls back to the DEFAULT placement policy. By default, all vSphere clusters have the vSphere Distributed Resource Scheduler activated to optimize initial and ongoing workload placement within a cluster.
PCA-VRA-MON-005	Add a Ping adapter for the vRealize Automation cluster nodes.	Provides metrics on the availability of vRealize Automation nodes.	You must add the adapter instances manually.

Table 32. Design Decision on Service Accounts for Monitoring and Alerting for Private Cloud Automation

Design Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-MON-006	Assign the Organization Owner default role and the Cloud Assembly administrator service role to an enterprise directory service account user for the application-to-application communication from vRealize Operations to vRealize Automation.	Provides the following access control features: vRealize Operations accesses vRealize Automation with the minimum set of required permissions for the integration. If there is a compromised account, the accessibility in the destination application remains restricted. You can introduce improved accountability in tracking request-response interactions between the vRealize Operations and vRealize Automation integration.	None.
PCA-VRA-MON-007	Assign the ReadOnly role to an Active Directory user account as an integration account for the application-to-application communication from vRealize Automation to vRealize Operations Manager.	Provides the following access control features: vRealize Automation integrates vRealize Operations Manager with the minimum set of required permissions. If there is a compromised account, the accessibility in the destination application remains restricted. You can introduce improved accountability in tracking request-response interactions between the vRealize Automation and vRealize Operations Manager.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. You must maintain the synchronization and availability of the service account in Workspace ONE Access and vRealize Operations Manager. You must use the format of user@domain@source when configuring the integration to use a service account backed by Workspace ONE Access. For example, [e-mail]@WorkspaceONE. Important: This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for vRealize Operations Manager, vRealize Automation cannot authenticate to vRealize Operations Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The user name and password cannot be sent over SAML to the identity provider for authentication.

Table 33. Design Decisions on Logging for Private Cloud Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VRA-LOG-001	Use the vRealize Log Insight content pack for vRealize Automation.	Provides an additional granular monitoring on the virtual infrastructure. The content pack is installed by SDDC Manager.	None.
PCA-VRA-LOG-002	Use the default configuration to transmit logs from vRealize Automation to the adjacent vRealize Log Insight in the VMware Cloud Foundation instance using the vRealize Log Insight ingestion API, cfapi, on port 9000.	Ensures the transmission of logs from the vRealize Automation services to be forwarded to the adjacent vRealize Log Insight using the vRealize Log Insight plugin for Fluentd. Provides the ability to configure a planned failover or disaster recovery of vRealize Automation to another VMware Cloud Foundation instance with minimal reconfiguration of vRealize Automation. VMware Cloud Foundation does not support the ability select the cfapi port used for the vRealize Automation integration with vRealize Log Insight.	The default configuration is unencrypted. To ensure that the transmission of logs between vRealize Automation and vRealize Log Insight is encrypted using SSL, you must update the default configuration for vRealize Automation to send logs to vRealize Log Insight using the ingestion API, cfapi, on port 9543 using the vRealize Automationvracli. For example, on the primary vRealize Automation cluster node, run the command vracli vrli set https://<vrli_ilb_fqdn>:9543 See Configuring Log Forwarding to vRealize Log Insight in the vRealize Automation documentation.
PCA-VRA-LOG-003	Use the vRealize Log Insight content pack for vRealize Orchestrator.	Provides an additional granular monitoring on the virtual infrastructure. Install the content pack manually as this installation is not yet automated by SDDC Manager.	None.
PCA-VRA-LOG-004	Configure a dedicated agent group in the vRealize Log Insight cluster to include all FQDNs of the vRealize Automation cluster nodes.	Provides a standardized configuration to all vRealize Log Insight agents in each of the groups. Defines the vRealize Log Insight agent configuration for log collection and parsing in the context of the SDDC components, such as specific log directories, files, and formats.	Adds minimal load to vRealize Log Insight.