Skip to content

Admission webhook did not detect host/path overlap with multiple ingress rules #13161

Open
@rkevin-arch

Description

@rkevin-arch

What happened:

The validation webhook when checking for host/path overlap between objects will exit prematurely if the first rule doesn't have any issues, even if subsequent rules have issues. See below repro case for an example.

What you expected to happen:

The new object with overlapping rules should be rejected

NGINX Ingress controller version (exec into the pod and run /nginx-ingress-controller --version): 1.12.1

Kubernetes version (use kubectl version): v1.32.2

Environment: Self-hosted onprem, but the issue has nothing to do with the environment and can be replicated in a fresh minikube environment.

How to reproduce this issue:

Create the following ingress object:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: first-ingress
spec:
  rules:
  - host: conflict.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: whatever
            port:
              number: 80

Then try creating this ingress object:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: second-ingress
spec:
  rules:
  - host: safe.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: whatever
            port:
              number: 80
  - host: conflict.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: whatever
            port:
              number: 80

This will create successfully despite the second rule being in conflict with the other object. If you reverse the order of the two rules in this second object, the validation controller fails with admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: host "conflict.example.com" and path "/" is already defined in ingress default/first-ingress as expected.

Anything else we need to know:

This ultimately stems from stray return nils here. I'll make a PR to fix this

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/supportCategorizes issue or PR as a support question.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.needs-prioritytriage/needs-informationIndicates an issue needs more information in order to work on it.

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions