Auth: Support externalname services in ExtensionService

[jpeach]

Please describe the problem you have

During the design review, we added the a ability for ExtensionServices to spread traffic across multiple Kubernetes services (they are aggregated in EDS with a cluster load assignment). However this approach won't work for external name services, because those have a different Envoy cluster type, and we can't generally mix and match intra-cluster services and external name services in the same EDS load assignment.

We should be able to support external name services as a special case when all of the specified services are external name services.

[jpeach]

@stevesloka WDYT? This should be workable?

[stevesloka]

What is your proposal @jpeach? To have externalName services be instead implemented as ExtensionServices? Or to have Contour create the ExtensionService in the background?

I always thought we should remove the need for the externalName service and just allow users to specify the url on the HTTPProxy.Spec.Route document.

[jpeach]

What is your proposal @jpeach?

This is the case where and ExtensionService references a Kubernetes external name Service. The use case for this is that you have an OIDC auth infrastructure but it lives outside the cluster.

My proposal is to require that all the Services references by a single ExtensionService should be external name or none of them should be. I'm assuming here that if more than one external name service is used we can weight traffic across them; if not then we will have to restrict it to using just one.

I always thought we should remove the need for the externalName service and just allow users to specify the url on the HTTPProxy.Spec.Route document.

This is for ExtensionService, not HTTPProxy.

[stevesloka]

I understand this is for ExtensionService & not HTTPProxy but the same semantics apply. The goal is to reference some external resource.

What's the value in adding another object type to manage when all we need is the value of the external dns name? That's my question in the design.

It makes sense for "Ingress" objects since the spec requires a reference to a service, but what if instead of ExtensionService referencing another k8s.externalName type service, the user entered the value directly (e.g. "auth.myco.com")? We now have that flexibility in our own CRDs to make this setup much simpler.

[jpeach]

I understand this is for ExtensionService & not HTTPProxy but the same semantics apply. The goal is to reference some external resource.

What's the value in adding another object type to manage when all we need is the value of the external dns name? That's my question in the design.

Oh I understand what you mean now. So your suggestion is something like adding an DNS name field to ExternalService that can be used instead of the current weighted services? Yep that's worth experimenting with.

[youngnick]

I think there is value in allowing people to use ExternalName services though - they're already present in Kubernetes, people are already using them, and they should work correctly.

[sidharthramesh]

Thank you for this wonderful project! I am running Contour with Knative and want to run a gRPC Authorization service (Open Policy Agent) as a Knative Service - so that it scales up and down with traffic.

Directly referencing the Service that Knative creates to the ExtensionService doesn't seem to work (since the domain names are probably used for internal routing).

I'm guessing using an externalName Service with the internal DNS <service>.<ns>.svc.cluster.local is the only viable option here to configure authorization when running it with Knative. Is there any other way to achieve this?

Any way I can contribute to this feature?

[BerGer23]

Got here via https://github.com/projectcontour/contour/issues/3373, researching whether Contour currently allows deploying Client Auth as sidecar.

1. Is there another (currently possible) way of achieving this?
2. Is this on the roadmap and/or can I contribute?

Cheers & thanks for the great work folks!

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack