Overview

The next step in vSphere extensibility evolution is focused on the technological updates necessary to maintain the stability and security of customer workloads. With the current announcement we are setting the long term standards our partners need to follow in order to provide our customers with the best quality vSphere enhancements.

The mentioned technological updates encompass the following areas:

• Deprecation of the legacy local plugins and transition to the remote architecture.
• Contemporary technological standards local plugins must comply with.
• Updates targeting security hardening of vCenter Server Appliance and the plugins running on it.

For more details on each of the subjects please check the sections below.

Local plugin deprecation

End of the legacy local plugins

The remote plugin architecture was introduced with vSphere 6.7U1 and is compatible with any subsequent version. This is the only architecture that will be supported in the future vSphere releases. Starting from version 7.0U1 remote plugins have full feature parity with the legacy (a.k.a. local) plugins and with vSphere 7.0U3 the capabilities they offer already surpass those of the legacy local plugins.

The legacy local plugin architecture was introduced with vSphere 6.5 and is compatible with versions 6.7, 7.0 and relevant updates. Since vSphere 7.0 VMware is not investing in new features for the local plugins as their evolution is completed. 

In the next major release of vSphere the local plugins will be deprecated and they will no longer be included in the VMware certification program.

The support for local plugins will be ended from the subsequent major release. 

Advantages of the remote plugins

The remote plugins are compatible with VMware cloud on AWS and the emerging VMware-supported clouds. They are the technology VMware will invest in to broaden the extensibility options of vSphere and increase plugin adoption on premise and in the cloud.

The remote plugin architecture supports multiple plugin versions allowing to accommodate widely differing vCenter instances across SSO domains in Hybrid Linked Mode.

Compared to the legacy (local) plugins, the interaction between vSphere and the remote plugins is on a different level from security, performance and compatibility perspective:

• The remote plugins operate with limited set of privileges in the vSphere environment and provide better auditing capabilities.
• They are compatible with the upgrade process of vSphere solving one of the major pain points for the customers and main obstacle for plugin adoption.
• The impact of remote plugins on vSphere performance is dramatically reduced ensuring much improved user experience with the UI.
• The remote plugins are running in their own appliance and do not get installed on the vCenter Server Appliance therefore do not need to comply with all technological boundaries and limitations vSphere must meet (more on that in the next sections).

The remote plugins are the long-term focus of VMware SDK certification program. They open a wide range of possibilities for new features and optimisations from the perspective of security, lifecycle management and multi-cloud support.

Transition path to remote plugins

VMware strongly recommends for all partners to migrate their solutions to the remote architecture and abandon the local plugins before the latter get deprecated. Local plugins will still be supported in the next major version of vSphere, but there will be multiple technological changes and restrictions the local plugins will have to comply with in order to remain available as vSphere extensions. VMware imposes these changes in order to ensure the security, stability and supportability of customers' vSphere environments. The sensible approach to meet those changes would be for partners to speed-up the transition to remote plugins, instead of investing in legacy technology that is on the verge of deprecation.

There are multiple paths for each partner to transition their solution to the remote architecture, depending on the technological specifics of each plugin. The following options are available:

• Build a remote plugin based on partner's existing standalone UI, reusing the full feature set, GUI and backend.
• Migrate the local plugin to remote architecture and leverage API migration tools. This approach is recommended when the local plugin is not heavily dependant on the Java services running on the vCenter Server Appliance.
• Build a remote plugin from scratch and design the solution based on the technological stack preferred by the partner.

vSphere Client extensibility team will provide the necessary support for partners in the transition to remote architecture: to select the right migration option and to overcome potential technological difficulties. 

Local plugin certification and support

The consequences from local plugin deprecation in the next major release of vSphere will be the following:

• Local plugins will no longer be part of vSphere Client plugin certification program. VMware will not certify and therefore recommend the usage of deprecated technology.
• Local plugins will still be supported. Although no new features will be delivered for the local architecture the customers will still be able to use their local plugins. 
• VMware will be addressing potential critical issues and security problems related to local plugins as for any other supported technology or feature. VMware may incidentally impose changes in the local plugins in case critical security issues are identified.

The consequences from local plugins being not supported in the subsequent major release will be the following:

• Local plugins will not be available for use in vSphere. Relevant APIs will no longer be supported and customers will not be able to install local plugins. 

Note: remote plugins will be fully supported and available.

Compliance and technological changes affecting local plugins

FIPS compliance

In a future release of vSphere, VMware will require all vSphere Client local plugins, both partner-supplied and VMware-supplied, to comply with the United States government Federal Information Processing Standard (FIPS) Publication 140-2, Level 1, Security Requirements for Cryptographic Modules. That standard assures up-to-date data communication security by mandating the use of highly secure encryption algorithms.

The article Preparing Local Plug-ins for FIPS Compliance in VMware code explains how you can upgrade your local plugin to use conformant encryption libraries correctly for interprocess communications.  The instructions assume the use of Bouncy Castle FIPS libraries. By coding your plug-in to use default encryption providers, you enable your code to operate either with standard JVM encryption or with Bouncy Castle FIPS encryption.

Note: The FIPS security requirement will not take effect in the vSphere 7.0 release generation. However, the customers will be able to configure vCenter Server to operate with or without FIPS providers in these releases. VMware is already upgrading its internal plug-ins, and we recommend that partners act soon to upgrade and test their own plug-ins with the new libraries.

One of the requirements for FIPS compliance is for all Java services (and vsphere-ui in particular) in the vCenter Server Appliance to move to a FIPS-compliant version of BouncyCastle for TLS/cryptography or use the Envoy Sidecar service to handle the TLS for them. The partners must consider that the vsphere-ui service is used to host vSphere Client local plugins, therefore any changes done to the vsphere-ui Java Virtual Machine could affect and possibly break the installed local plugins.

The plugins have the option to become FIPS-compliant and not break when deploying in the vsphere-ui JVM by using the new BouncyCastle security providers for TLS connections and crypto.

This process would require minimal changes to the plugin code since it keeps running against the same Java security interfaces. There are, however, a couple of breaking changes in the BouncyCastle implementation that should be handled. All the changes are backward compatible and the plugin will work both when deployed on FIPS switched ON (BouncyCastle implementation) and FIPS switched OFF (SUN implementation) environments. This should save the plugin from having to check any feature flags.

Transition to SHA-256

The use of SHA-1 hash algorithm is being gradually deprecated in vSphere, starting from version 7.0U2. It will be incrementally replaced by SHA-256. 

Potential issues with SHA-1 have been known for years, but these were mostly theoretical and impractical. In 2020 practical attacks have been demonstrated that can be carried out with fairly limited resources and time. This situation effectively forces VMware to remove all vulnerable uses of SHA-1 in vSphere as soon as possible and instead use SHA-256 (see Wikipedia entry for SHA-1). 

In a future major release of vSphere, SHA-1 will be removed as supported hashing algorithm and replaced by SHA-256.

We strongly recommend all partners to consider adding support for SHA-256 for the upcoming versions of their plugins (both local and remote) to be ready for the end of support of SHA-1 in a future major release of vSphere.

Upgrade to Spring 5

Considering the official end of support for Spring 4 at the end of 2020 and the common vulnerabilities and exposures associated with version 4, VMware is upgrading vSphere Client to use Spring 5 starting from the release of vSphere 7.0U3. 

Spring 5 is not fully backward compatible which may lead to failure or malfunctioning of some vSphere Client plugins. A typical problematic situation could be the use of APIs deprecated in Spring 4, which are no longer supported in Spring 5. In case of such problems, we strongly recommend to modify the code of the affected plugin to make it compatible with Spring 5. We're providing however a fallback option, which is not recommended by VMware to make it possible for the plugin to continue working with vSphere 7.0U3 - that is to downgrade the vSphere Client to use Spring 4 through the following steps.

1. Open  /etc/vmware/vmware-vmon/svcCfgfiles/vsphere-ui.json for edit.
2. Uncomment this line: //“-DuseOldSpring=true”.
3. Restart vSphere Client service.

Please be aware that the fallback option to downgrade to Spring 4 will not be available in the next major release.

Third-party library isolation

Third-party libraries deployed and utilised by the vCenter Server appliance (VCSA) for its own needs that are currently exposed to partner plugins will be restricted and no longer available effectively from the next major release of vSphere.

In the versions of vSphere up to 7.0, the vSphere Client platform is not isolated. The local plugins have the possibility to import packages coming from third-party libraries deployed for the needs of vSphere Client platform. This is problematic for multiple reasons, such as:

• Changes to internal vSphere Client APIs could break plugin compatibility.
• Changes to a particular vSphere Client dependency (e.g. to consume security updates) could impact plugin compatibility.
• Historically, plugins have been commonly required to use third-party library dependencies from the vSphere Client (e.g. Spring).

Plugins using vSphere Client internal dependencies present a serious risk from security and supportability POV, since VMware must be able to:

• Update libraries quickly if there is a notice about security vulnerability in the supported vSphere Client versions.
• Support each version of the Client for multiple years and therefore obliged to avoid unsupported libraries.

These are the essential reasons forcing VMware to make a step further in maintaining the reliability of the plugin integration model and make sure plugin developers are providing their own OSGi Java dependencies. Any logging implementation/facade, JSON/XML serialisation, Apache utilities, etc. will have to be provided as part of the plugin: either as separate OSGi bundles or included in an existing plugin bundle's class path.

The library isolation of local plugins will take effect in two steps, starting with the release vSphere 7.0U3, when it will be turned off by default. 

The library isolation will be turned on from the next major release of vSphere. 

For more information about the third-party libraries which availability will be restricted and for technical guidance please contact vSphere Client SDK team.

Security hardening for local plugins

SSPI, CAC, RSA SecurID

In a future major vSphere release, VMware plans to discontinue support for Windows Session Authentication (SSPI) used as part of the Enhanced Authentication Plug-in, Smart Card support, and RSA SecurID for vCenter Server. In place of SSPI, Smart Card, or RSA SecurID, users and administrators can configure and use Identity Federation with a supported Identity Provider to sign in to their vCenter Server system.

More information in the dedicated VMware Tech Zone announcement. 

IWA

Integrated Windows Authentication (IWA) is deprecated in vSphere 7.0 and will be removed in a future release. For more information, see VMware Knowledge Base article 78506.

DCUI smartcard

In a future vSphere release, support for Smart Card Authentication in DCUI will be discontinued. In place of accessing DCUI using Personal Identity Verification (PIV), Common Access Card (CAC), or SC650 smart card, users will be encouraged to perform operations through vCenter, PowerCLI, API calls, or by logging in with a username and password.

TPM 1.2

vSphere will continue to support legacy PCR usage with TPM 1.2, but will not support the new D/A PCR usage model introduced with “Ice Lake” platforms. More information in the dedicated VMware Technology Partner Hub message.

32-bit userworld

Support for 32-bit userworld (used for partner drivers, plugins, extensions, etc.) is deprecated in favour of 64-bit userworld and will be permanently removed in the next major ESXi version.

In vSphere 7.0, 32-bit userworld support has been deprecated. Userworlds are the components of ESXi used by partners to provide drivers, plugins, and other system extensions (distributed as VIBs). Userworlds are not customer accessible.

vSphere 7.0 provides 64-bit userworld support through partner devkits and will retain 32-bit userworld support through this major release. Support for 32-bit userworlds will be permanently removed in the next major ESXi release. To avoid loss of functionality, customers should ensure any vendor-supplied VIBs in use are migrated to 64-bit before upgrading beyond the vSphere 7.0 release.

More information in vSphere 7.0 release notes.

vMON API service

VMware plans to deprecate the VMware Service Lifecycle Manager API (vmonapi service) in a future release. For more information, see the dedicated VMware knowledge base article.