4.9. Managing Modifications and Customizations

4.9.1. What it is

In previous versions of SSL Orchestrator (5.0+), if any configuration object is taken out of strictness mode, that object’s UI configuration becomes read-only. The SSL Orchestrator configuration naturally attempts to solve for the “majority” of TLS visibility use cases but cannot solve for them all. The ability to “tweak” data flow configurations and properties on an F5 BIG-IP is an important characteristic, thus the concept of configuration “strictness” can sometimes be too restrictive for many environments. Starting in SSL Orchestrator 7.1 is the concept of strict updates modification. Essentially, the SSL Orchestrator configuration allows non-strict changes to the configuration – changes made outside of the SSL Orchestrator UI – to persist through object deployments. When an object is re-deployed after non-strict updates, a new UI screen provides the option to keep (“Merge Changes”) any non-strict changes to the object. Leaving the Merge Changes option unchecked overwrites any non-strict updates.


Figure 80: Configuration Merge

The strict updates modification option, however, presents a set of caveats:

  • When the Merge Changes option is not selected, any non-strict changes are overwritten, and the object is re-locked (strictness enabled).

  • Security policies do not benefit from the new strict updates modification feature. The security policy UI represents the necessary settings to build effective SSL Orchestrator traffic rules. Those settings are translated to an Access per-request policy, which itself can possess an enormous set of options beyond those needed by SSL Orchestrator. As the security policy represents a finite set of options, and the underlying visual policy represents a near infinite set of use cases, it would not be possible to convert a modified visual policy back to a security policy. All other “strict” object types (topologies, services, and SSL configurations) can employ the Merge Changes feature.

  • Any non-strict updates that are in diresct conflict with SSL Orchestrator-managed object changes (ex. SSL ciphers) are reset to the SSL Orchestrator-configured setting.

4.9.2. How to build it

To use this feature:

  • Deploy a typical SSL Orchestrator topology, then take one of the object types of strictness mode by unlocking its respective object (ex. SSL Configuration).

  • Make an out-of-band change to that object, for example disable the Generic Alerts option in the respective client SSL profile.

  • Go back to the SSL Orchestrator UI, make a change somewhere, and re-deploy. When the above message appears, click the Merge Changes option and click Deploy. Notice in the LTM object settings that the non-strict change persists.