Feature gates

Review the required Gloo versions for gated features that you can optionally enable in the gloo-platform and gloo-platform-crds Helm charts.

In the featureGates Helm setting, you specify a key-value pair, in which the key is the feature name, and the value is a boolean to enable or disable the feature. For example, to onboard external workloads with Gloo Mesh Enterprise, you set --set featureGates.ExternalWorkloads=true in your helm install command, or set featureGates.ExternalWorkloads to true in your Helm values file. Note that the featureGates section replaces the deprecated experimental section in the gloo-platform Helm chart.

For more information about the Helm chart, see the Helm value reference. For more information about features that are in alpha or beta support, see Gloo feature maturity.

info

For some features, you must enable the feature gate in both the gloo-platform chart and the gloo-platform-crds Helm chart, because the feature requires a specific CRD that is not installed by default. Review the feature description in the following table to check whether the feature gate must be enabled in gloo-platform-crds too.

Feature	Default value	Maturity	Since	Until	Description	Used by
`EnableDefaultTcpKeepalive`	`false`	GA	2.7.0		When this flag is enabled, all VirtualDestinations are configured with TCPKeepalive by default, with the probes field set to 9 and the time and interval fields set to 180s. To override these values for a given VirtualDestination, configure a ConnectionPolicy.	Gloo management server
`GatewayDefaultDenyAllHTTPRequests`	`false`	GA	2.5.0		In Gloo Mesh Gateway, apply external auth or JWT policies to enable traffic for specific routes. This feature ensures ongoing security, even in the event of errors like policy deletion or Envoy filter issues. By default, all existing routes bypass this mechanism. To onboard routes to this new feature, you must label your HTTP routes with the reserved `'gateway.gloo.solo.io/require_auth': 'true'` label. Once labeled, routes become subject to the dynamic default deny behavior, reinforcing security.	Gloo management server
`ImportedVirtualDestinationPolicyLegacyMode`	`false`	GA	2.10.0		Legacy mode preserves a bug in which client-side policies are not properly applied to VirtualDestinations that are imported from one workspace to another, when no backing service for the VirtualDestination exists in the local cluster. This bug was fixed so that the importing behavior matches the expected behavior as described in the docs. The fix can impact the DestinationRules that are translated from the client-side policies as follows. Many environments get additional DestinationRules to enforce the client-side policies that are now imported to the workspace. Some environments might have modified or fewer translated DestinationRules from the client-side policies, such as if imported client-side policies result in fewer policies being applied from the importing workspace. As such, you might want to temporarily keep legacy mode to maintain the old behavior of DestinationRules. Legacy mode is enabled by default in version 2.9 and earlier. In version 2.10, legacy mode is disabled by default. To keep the legacy mode enabled in 2.10, set this feature flag to `true` before upgrading. Note that the legacy mode is deprecated and planned to be removed in version 2.11.	Gloo management server
`InsightsConfiguration`	`false`	Alpha	2.5.0	2.9.0	Configure settings for the insights engine.	Gloo management server
`ResolveEastWestHostConflicts`	`false`	GA	2.6.6		When this flag is enabled, additional strict validation and conflict resolution is performed on VirtualDestinations, ExternalWorkloads, and ExternalServices. This validation can detect whether two workspaces define the same destination hostname and port, and are exposed on the same east-west gateway at the same time. Normally, this is not considered a conflict. However, a bug was identified in Istio version 1.22 and lower where overlapping ServiceEntries are created that are rejected by Envoy. As a workaround, you can enable strict validation for east-west hostnames and ports to ensure that only one (the oldest) VirtualDestination, ExternalService, or ExternalWorkload can define a hostname and port that is exposed on the east-west gateway. If a conflict exists, the conflict is shown as a warning in the VirtualDestination, ExternalService, or ExternalWorkload resource that attempts to define the conflicting hostname and port.	Gloo management server
`SafeModeAutoSkipWarming`	`true`	Alpha	2.6.0		When this flag is enabled, the Gloo management server automatically excludes workload clusters that were never connected to the management server from Redis safe mode. This setting allows you to seamlessly onboard new clusters without setting the `skipWarming` field on the corresponding KubernetesCluster resource. NOTE: Enable this field only after you successfully upgraded to 2.6.0 and all workload clusters are reconnected to the Gloo management server and their input snapshots are present in Redis.	Gloo management server