Controller: Retain default backend service information.

[chessman]

What this PR does / why we need it:

When the default backend is used as upstream, the information about its service is lost. As a consequence, if the default backend is an ExternalName service, it is used as a non-ExternalName service in the Lua part.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• CVE Report (Scanner found CVE and adding report)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation only

Which issue/s this PR fixes

fixes #12158

How Has This Been Tested?

The test case is described in #12158.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added unit and/or e2e tests to cover my changes.
• All new and existing tests passed.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: chessman / name: Eugene Apollonsky (d3cc0a8)

[k8s-ci-robot]

Hi @chessman. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: chessman
Once this PR has been reviewed and has the lgtm label, please assign cpanato for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[netlify]

✅ Deploy Preview for kubernetes-ingress-nginx canceled.

Name	Link
🔨 Latest commit	d3cc0a8
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-ingress-nginx/deploys/6708fe9fc786aa000829afd3

[longwuyuan]

@chessman thanks for your contribution.

I would like to comment in a way that everyone gets on the same page.

• If a backend is in the same cluster as the ingress, the convention is to use service --type ClusterIP. But you are presenting a unconventional use-case that has no benefit for other community users of the controller. Summary of what you want is

  • first create a service --type NodePort in the same cluster as the ingress resource
  • then you want to configure the cluster internal dns name of the NodePort service, in the service.spec.externalName field, of another service of --type ExternalName, in the same cluster
  • then you want to configure a default-backend in a ingress, in the same cluster
  • and you want to use this service of --type ExternalName as the default-backend, also in the same cluster

• You must be having a valid reason, that is a requirement for you, for complicating matters like this But expecting a community project to change its code just because you want to use the controller in a non-conventional way, is not a fair or a reasonable expectation.

• You can fork the project and maintain your fork with the capability you are expecting. Its not possible for this project to triage, debug, identify, create & maintain new capabilities, using lua code, that only you need to use. The use of resources here will not be justified.

• The upstream K8S Ingress-API KEP defines specs and ingress-controllers implement the specs as per resources. But we are trying to get away from the Lua based implementations (of several features). We are also actually deprecating multiple currently stable features, that are popular, but have no future. This is because the available resources are required for security & Gateway-API.

Please wait and see if any other comments are made here or if a developer wants to triage, debug & work on this.

[longwuyuan]

/retitle use a url outside the cluster as service type ExternalName for default-backend

[longwuyuan]

/retitle use a NodePort service as ExternalName in another service type ExternalName for configuring default-backend

[chessman]

@longwuyuan

• No, my goal is to use a ClusterIP service in the same cluster but it is in another namespace.
• From my point of view, it is not a feature, it is a bug. The documentation says that default backend is a service. I don't see any mentions that it cannot be an external name. If a service used in Ingress can be, then why the default one cannot? The one-line fix is not in the lua part, so I guess it will work as long as you don't deprecate external services in Ingress.
• Currently Backend object is used for default backend with a wrong Service, so this code is incorrect regardless of whether you support this feature or not.

[longwuyuan]

@chessman thanks for your comments. Using data to discuss helps everyone get on the same page.

• Use the data that you provided in the issue.

• As per the data in the issue you have the echo-service(default-backend) and the hello-app ingress in the same namespace(default)

• So you can just do kubectl expose deployment echo --port=8080 instead of creating service --type NodePort

• Then you can set the default backend in the ingress you showed there simply like this "nginx.ingress.kubernetes.io/default-backend: echo"

  • Note the the expose command without --name will create a service of --type ClusterIP with same name as deploment "echo"

• You also have options to set the global default-backend https://kubernetes.github.io/ingress-nginx/examples/customization/custom-errors/

[longwuyuan]

@chessman Please continue discussion in the issue as its not a easy task to track issue discussions in multiple places

[strongjz]

/ok-to-test
/triage accepted
/priority backlog

[Gacko]

I'd like to test this locally and therefore

/hold

this PR for now.

[longwuyuan]

@strongjz and @Gacko , its possible that this PR creates yet another CVE for the project.
A user can potentially configure a ingress to connect to a service in another namespace, and thus get past RBAC.