Expanding Mutations

[whwalter]

Based on the spike on external-dns, it seems there are a number of annotations and fields on gateway objects that need to be set on gateway resources and only have meaning for administrators.

The following fields need to be set on a self-service, namespaced gateway but the values are largely meaningless to the namespace owners:

metadata
  annotations
    external-dns.alpha.kubernetes.io/hostname: *replication of the hosts slice*
    external-dns.alpha.kubernetes.io/target: *value of the user ingress-gateway vanity dns entry*
spec:
  selector: # this selects the appropriate ingressgateway for the Gateway resource but admins gate what this value is so we would need to restrict via OPA or inject via mutation
    istio: ingressgateway
    type: user
  tls:
    credentialName: # this is already handled by this controller

Do we want to expand thing controller to be able to inject the fields admins know the values?
Would adding additional mutating webhooks be the right way to handle that?
Do we know the latency cost of this controller?

[dskatz]

Do we know the latency cost of this controller?

These metrics are being worked on currently. It is following the best practices and not making any additional API calls to keep latency at a minimum.

Do we want to expand thing controller to be able to inject the fields admins know the values?

My answer here is a tentative yes, depending on where these external-dns values come from. Supporting external-dns here would mean giving this controller expanded scope for handling a multi-tenant namespaced routing setup.

Would adding additional mutating webhooks be the right way to handle that?

I think expanding the scope of this controller / mutation handler would be the best approach from a networking perspective.