Project: Gloo (Orchestration & Management / API Gateway)
File: external_options.proto.sk.md

title: "external_options.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Top-Level Resource Top-Level Resource The VirtualHostOption holds `options` configuration for a VirtualHost. VirtualHosts can inherit `options` config from `VirtualHostOption` objects by delegating to them. When a VirtualHost delegates to an external VirtualHostOptions object, any options config defined on the VirtualHost will override the external options config. Similarly, `VirtualHostOption`s which are delegated to first will get priority over following `VirtualHostOption`s. An example configuration with a VirtualService with its own options config and delegating to two VirtualHostOption objects: ```yaml apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: http namespace: gloo-system spec: virtualHost: domains: '*' options: headerManipulation: requestHeadersToRemove: ["header-from-vhost"] optionsConfigRefs: delegateOptions: name: virtualhost-external-options-1 namespace: opt-namespace name: virtualhost-external-options-2 namespace: opt-namespace ``` ```yaml apiVersion: gateway.solo.io/v1 kind: VirtualHostOption metadata: name: virtualhost-external-options-1 namespace: opt-namespace spec: options: headerManipulation: requestHeadersToRemove: ["header-from-external-options1"] cors: exposeHeaders: header-from-extopt1 allowOrigin: 'https://solo.io' ``` ```yaml apiVersion: gateway.solo.io/v1 kind: VirtualHostOption metadata: name: virtualhost-external-options-2 namespace: opt-namespace spec: options: headerManipulation: requestHeadersToRemove: ["header-from-external-options2"] cors: exposeHeaders: header-from-extopt2 maxAge: 2s allowOrigin: 'https://solo.io' transformations: requestTransformation: transformationTemplate: headers: x-header-added-in-opt2: text: this header was added in the VirtualHostOption object - #2 ``` The final virtual host options (visible in the Proxy CR) would be: ```yaml spec: virtualHost: domains: '*' options: headerManipulation: requestHeadersToRemove: ["header-from-vhost"] cors: exposeHeaders: header-from-extopt1 allowOrigin: 'https://solo.io' transformations: requestTransformation: transformationTemplate: headers: x-header-added-in-opt2: text: this header was added in the VirtualHostOption object - #2 ``` Notice how the order of VirtualHostOption delegations matters, and that the VirtualHost-level config overrides all delegated configs. ```yaml "namespacedStatuses": .core.solo.io.NamespacedStatuses "metadata": .core.solo.io.Metadata "options": .gloo.solo.io.VirtualHostOptions "targetRef": .core.skv2.solo.io.PolicyTargetReferenceWithSectionName ``` | Field | Type | Description | | -- | - | -- | | `namespacedStatuses` | | NamespacedStatuses indicates the validation status of this resource. NamespacedStatuses is read-only by clients, and set by gateway during validation. | | `metadata` | | Metadata contains the object metadata for this resource. | | `options` | | VirtualHost options. See VirtualHost for delegation behavior. | | `targetRef` | | When using Kubernetes Gateway API mode, targetRef can be used to attach this VirtualHostOption to a gateway.networking.k8s.io/Gateway object. The `options` specified will then be used for all `Listeners` in the `Gateway` unless `targetRef.sectionName` is

| The RouteOption holds `options` configuration for a Route. Routes can inherit `options` config from `RouteOption` objects by delegating to them. When a Route delegates to an external RouteOptions object, any options config defined on the Route will override the external options config. Similarly, `RouteOption`s which are delegated to first will get priority over following `RouteOption`s. An example configuration with a Route with its own options config and delegating to two RouteOption objects: ```yaml apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: http namespace: gloo-system spec: virtualHost: domains: '*' routes: matchers: prefix: / options: headerManipulation: requestHeadersToRemove: ["header-from-route"] optionsConfigRefs: delegateOptions: name: route-external-options-1 namespace: opt-namespace name: route-external-options-2 namespace: opt-namespace ``` ```yaml apiVersion: gateway.solo.io/v1 kind: RouteOption metadata: name: route-external-options-1 namespace: opt-namespace spec: options: headerManipulation: requestHeadersToRemove: ["header-from-external-options1"] cors: exposeHeaders: header-from-extopt1 allowOrigin: 'https://solo.io' ``` ```yaml apiVersion: gateway.solo.io/v1 kind: RouteOption metadata: name: route-external-options-2 namespace: opt-namespace spec: options: headerManipulation: requestHeadersToRemove: ["header-from-external-options2"] cors: exposeHeaders: header-from-extopt2 maxAge: 2s allowOrigin: 'https://solo.io' transformations: requestTransformation: transformationTemplate: headers: x-header-added-in-opt2: text: this header was added in the RouteOption object - #2 ``` The final route options would bewould be: ```yaml routes: matchers: prefix: / options: headerManipulation: requestHeadersToRemove: ["header-from-route"] cors: exposeHeaders: header-from-extopt1 allowOrigin: 'https://solo.io' transformations: requestTransformation: transformationTemplate: headers: x-header-added-in-opt2: text: this header was added in the Route object - #2 ``` Notice how the order of RouteOption delegations matters, and that the Route-level option config overrides all delegated option configs. ```yaml "namespacedStatuses": .core.solo.io.NamespacedStatuses "metadata": .core.solo.io.Metadata "options": .gloo.solo.io.RouteOptions "targetRef": .core.skv2.solo.io.PolicyTargetReference ``` | Field | Type | Description | | -- | - | -- | | `namespacedStatuses` | | NamespacedStatuses indicates the validation status of this resource. NamespacedStatuses is read-only by clients, and set by gateway during validation. | | `metadata` | | Metadata contains the object metadata for this resource. | | `options` | | Route options. See Route for delegation behavior. | | `targetRef` | | When using Kubernetes Gateway API mode, targetRef can be used to attach this RouteOption to a gateway.networking.k8s.io/HTTPRoute object. The `options` specified will then be used for all `Rules` in the `HTTPRoute`. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->