Overview
With the upcoming major release of vSphere we are taking the next step in vSphere extensibility evolution. It is focused on the technological updates necessary to maintain the stability and security of customer workloads. With the changes in the mentioned release 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 local 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. It 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.
With the next major release of vSphere we are announcing the deprecation of the local plugins. As result the local plugins will no longer be included in 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 upcoming major release of vSphere, but there will be multiple technological changes and restrictions the local plugins must 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 upcoming 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.
Note: remote plugins will be fully supported and available.
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
With the upcoming major release of vSphere, VMware requires 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.
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 upcoming 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
Content-Security-Policy header in vSphere Client responses
In order to harden the vSphere Client’s security against XSS attacks, the loading of external resources inside local plugins iFrames is now forbidden. The vSphere Client now uses a new Content-Security-Policy header which is designed to prevent the loading of resources from URLs different than the original URL used to load the vSphere Client. Local plugins, which depend on loading external resources inside their iFrames, should bundle the resources inside their plugin package to continue using them. This change will only impact the local plugins.
