gateway-api icon indicating copy to clipboard operation
gateway-api copied to clipboard

Published 20 hours ago • verified publisher icon kubernetes-sigs

Explicitly define ExternalName expectations

Open howardjohn opened this issue 3 years ago • 8 comments

Currently, Service is a supported backendRef. A service can be of type ExternalName, which has non-obvious semantics.

In the Ingress world, I previously did some research into how different controllers handle differently; I don't think I was able to find two implementations doing the same thing.

It would be great to explicitly define how this should be treated. Depending on the answer, we may need to more broadly address how we access external sites.

howardjohn avatar Mar 24 '22 20:03 howardjohn

As I understand it, Ingress was never intended to be used to forward to Service of type ExternalName, but unfortunately that never made it to the spec. I think the comment in https://github.com/kubernetes/kubernetes/issues/103675 is highly relevant here:

A similar attack is possible using Ingress implementations that support forwarding to ExternalName Services. This can be used to forward to Services in other namespaces or, in some cases, sensitive endpoints within the Ingress implementation. If you are using the Ingress API, we recommend confirming that the implementation you’re using either does not support forwarding to ExternalName Services or supports disabling the functionality.

With that said, there may be safe ways to combine a BackendRef + ExternalName for other use cases such as mesh or egress.

robscott avatar Mar 24 '22 21:03 robscott

I think we should recommend pretty strongly against using a Service of type ExternalName as a backendRef.

It's just too easy to bypass namespace controls by using ExternalNames of service.namespace.svc.cluster.local, or to gain access to the localhost of network gear using an ExternalName of localhost. And that's aside from the stuff you can do with manipulating Endpoints on top of that.

I'd rather see the creation of an explicit redirect-to-external-site resource that can explicitly rule out localhost and cluster.local domains.

youngnick avatar Mar 25 '22 04:03 youngnick

I think we should recommend pretty strongly against using a Service of type ExternalName as a backendRef.

I can see someone trying to use Gateway API as an Egress Gateway which specializes in doing routing to ExternalName services. No?

hbagdi avatar Apr 01 '22 23:04 hbagdi

Yes, I agree that is a useful use case, but allowing Service of Type ExternalName in all cases still leaves us with the ability to use this functionality to bypass namespace security. That's why I recommend a different object that can be clear about the risks involved.

The alternative is to allow Service of Type ExternalName in some use cases, but then there's no way for a user to know if their service will work or not. They'd have to create one and see. That doesn't seem to mesh well with the goal of increasing portability.

youngnick avatar Apr 03 '22 22:04 youngnick

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Jul 02 '22 22:07 k8s-triage-robot

/remove-lifecycle stale

robscott avatar Jul 05 '22 17:07 robscott

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Oct 03 '22 17:10 k8s-triage-robot

This came up in https://github.com/kubernetes-sigs/gateway-api/pull/1426, but without any explicit plans to address it at this time.

/lifecycle frozen

mikemorris avatar Oct 04 '22 18:10 mikemorris