Option to disable ingress validation webhook

[nickvanwegen]

Is your feature request related to a problem?

I am already using ingress-nginx for my ingress objects. Sometimes I encounter some issues where the LB-controller wants to validate ingress objects while its not even handling them

Describe the solution you'd like

I would like to be able to disable the ingress validating part of the lb-controller validating webhook

Describe alternatives you've considered

none just want to be able to disable lb-controller webhook from validating ingress objects. I also notived the feature-gate to let the LB-controller only look at service of type loadbalancer but i see that the webhook is installed via helm and there is no bool to enable or disable the ingress part so this would also not fix it.

[kishorj]

/kind feature

[lakshkeswani]

@kishorj I am interested on working on this and I am new to this repository, can you please guide me from where I should start ?

[jerryhe1999]

/assign

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[Angelin01]

/remove-lifecycle stale

[nuno-silva]

#3011 seems to be taking care of the disabling the webhook for ingresses.

However, another part of this issue, which I believe is what was #2939 was about, is being able to disable the ingress/ALB part of the controller completely.

This is currently possible for Service/NLB via the EnableServiceController feature gate, but not for Ingress/ALB. A new EnableIngressController feature gate would solve this. Is this being considered? If not, perhaps #2939 should be re-open.

A workaround for this is to use an ingress class that does not exist, such as --ingress-class=this-class-does-not-exist-on-purpose.

[samcannell]

I disagree; I'd really like the Helm chart to provide the selectively disable parts of the admission webhook configuration.

My use case is that I'm deploying aws-load-balancer-controller from Terraform using the Helm chart. I'm only using aws-load-balancer-controller to manipulate the members of an ALB target group; there are no Service or Ingress resources that it's responsible for looking after.

There is no reason that Terraform should need to manage ordering carefully here, however if I leave ordering up to Terraform I often run into issues where the ValidatingWebhookConfiguration resource is created before the Service backing it is ready to serve connections, which will cause any attempt to create an Ingress resource to fail.

My only option is to add dependencies onto every Terraform module that needs to create an Ingress resource, which absolutely tanks the performance of Terraform's plan phase. I can't stress this enough -- the time taken to run terraform plan drops from ~15 minutes to 30 seconds if I just remove the top-level inter-module dependencies referring to aws-load-balancer-controller.

Now, this is undoubtedly a deficiency with Terraform, but I don't think it negates my point that I don't need the AWS LB controller to manage Ingress resources, so it shouldn't ever interfere with my creation of them. Undoubtedly I'm probably using the AWS LB controller in a somewhat unconventional way, but I don't feel that makes my use case any less valid.

[emedvesApk]

Hi, I also have a use case where this feature is really needed. Basically we use Argocd, the gitops tool, to deploy everything in our clusters. We use HaProxy as Ingress Controller. The problem we are facing, during cluster startup, is that the AWS-lb validating webhook blocks the installation of some helm charts that use the HaProxy ingress class (which might not be applied yet). Since we are also using OPA-gatekeeper, we really don't want the aws-load-balancer-controller to apply unnecessary validations, out of our control.

[aceeric]

I created a very similar issue along these lines which addresses a variation of this issue: 11341. The common theme is - integrators are deploying workloads with automation tools and the ingress controller validation behavior doesn't support some of those use cases.