Support External IP Addressing in SinkBinding for External Access to Kubernetes Services & Knative Service

[Leo6Leo]

Problem When using SinkBinding to bind a Kubernetes service of type Load Balancer as a sink or a Knative Service as a sink, Knative consistently resolves the service name to <service-name>.default.svc.cluster.local. However, for services that are exposed both internally and externally (having both a ClusterIP and an ExternalIP), this automatic resolution to a cluster-internal DNS name might not be ideal for some use case.

The current behavior limits the flexibility needed for scenarios where external access to the sink is required directly through its External IP.

Persona: This feature request primarily concerns the Operator persona, who manages cluster configurations and ensures that services are reachable as needed, both internally and externally.

Exit Criteria SinkBinding can use the external IP if its sink is a K8s service.

Time Estimate (optional): 3-4

Additional context (optional) A use case example: My use case involves a frontend application that needs to send events to a Kubernetes service. I utilize sinkBinding to relay the addressable endpoint of this service to the frontend, thus informing it of the destination for its requests.

Users access the frontend application through their web browser, which initiates communication external to the Kubernetes cluster. In this scenario, the requests fail because they are sent from the user's browser, an external source, and thus cannot resolve or reach the cluster-internal DNS address provided by the current sinkBinding configuration. This results in unsuccessful delivery of the requests to the Kubernetes service.

I understand that by implementing this might also raise security concern or violate the original design purpose of SinkBinding, so any feedback is welcome.

[Leo6Leo]

cc @creydr @Cali0707 @pierDipi

[Cali0707]

I think from the perspective of letting users run all types of workloads consistently on Knative, that this makes sense to me, so +1 on that

I understand that by implementing this might also raise security concern or violate the original design purpose of SinkBinding

Yeah, I am also not sure on this part

[Leo6Leo]

The only apparent solution in my mind for allowing a front-end application to send requests to a service in the Kubernetes cluster is to hardcode the external address in the front-end application.

[pierDipi]

The only apparent solution in my mind for allowing a front-end application to send requests to a service in the Kubernetes cluster is to hardcode the external address in the front-end application.

You can also hardcode it in the SinkBinding.sink.uri

[pierDipi]

I think if Serving starts using the addresses array and set both internal and external address, in your SinkBinding you could do something like:

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: <name>
spec:
  # ...
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: <sink>
      address: <public-address-name>

[pierDipi]

So, I would not complicate how we resolve the address for SinkBinding and instead modify the sink addressable to also expose the public address in the list that can be selected

[pierDipi]

I would recommend proposing that option to Serving vs changing how we resolve addressables in Eventing