Abstraction for a hostname?

I’m wondering whether there is an abstraction, or plans for an abstraction, for concrete fqdns that are required in some Istio CRDs? In my use case, I’m proxying endpoints exposed by an Istio edge proxy to existing legacy services that are outside of the cluster.

Here is an edited snippet from a kustomization file for one of the deployed environments:

bases:
  - ../../../base/istio-ingress
patches:
- target:
    name: authenticator
    kind: ServiceEntry
    version: v1beta1
  patch: |-
    - op: replace
      path: /spec/hosts/0
      value: auth.alpha.example.com
- target:
    name: authenticator
    kind: WorkloadEntry
    version: v1beta1
  patch: |-
    - op: replace
      path: /spec/address
      value: auth.alpha.example.com
- target:
    name: ingress-authenticator
    kind: VirtualService
    version: v1beta1
  patch: |-
    - op: replace
      path: /spec/http/0/headers/request/set/Host
      value: auth.alpha.example.com
- target:
    name: authenticator-originate-tls-for-lb
    kind: DestinationRule
    version: v1beta1
  patch: |-
    - op: replace
      path: /spec/host
      value: auth.alpha.example.com

With this approach, I’ll need to reference <service>.<env>.example.com five times across each deployed environment across each service (perhaps ~ 10 services altogether), which will be a little fiddly to maintain. Is there a way to abstract out the fqdn in this case? That would allow me to specify the actual hostname once per service per deployed environment, with symbolic references everywhere else. If there is no way to do this at this time, are there plans to make this possible?

It’s also possible I’m doing this wrong, in which case I’m open to suggestions.

To answer my own question — not sure if this is the best approach, but what can be done here is to use a placeholder fqdn (e.g., “some-service.local”) to fill in for the external service that is being proxied, and then use the actual hostname at the last step, when the request exits the egress gateway and TLS is originated. In this approach, you only need to configure the actual hostname for the service, which will change from environment to environment, in one or two places, rather than five, as in the example above.