Kubernetes: Allow RegExp or wildcard for ingress domain and/or path

116

Is this a request for help?

No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

  • ingress wildcard
  • ingress regexp

Is this a BUG REPORT or FEATURE REQUEST?

Feature, although if it exists and I don't see it, then bug for docs


As far as I can tell, k8s ingress supports (in theory), subdomain wildcards for ingresses (supposing the given controller supports them, of course), such as *.mydomain.com. There appear to be confusing issues (re: https://github.com/kubernetes/kubernetes/issues/39622 ) but in theory it supports it.

  1. I cannot find this in official documentation anywhere?
  2. Is there support for general wildcards?

The specific use case is as follows. I have a set of k8s resources being deployed to multiple environments, e.g. prod, uat, qa. Each one has its own inbound root domain, e.g. prod.mydomain.com, qa.mydomain.com, uat.mydomain.com.

When I create my k8s resources, I want to use identical ones between all the environments. If I have 3 exposed services (e.g. web, api, magic) in each domain, routed by subdomain, I shouldn't require 3 separate ingresses, one for each environment, per exposed service. Instead, I want to do something like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web
spec:
  rules:
  - host: "web.*"
    http:
      paths:
      - path: /
        backend:
          serviceName: web-service
          servicePort: 80

(repeat for services api and magic)

This allows my to tell my devs

  1. Pick your environment with kubectl config set-context prod (or uat or qa)
    2.Deploy consistently with kubectl apply -f configs/

Did I miss that somewhere? Or is it not currently supported?

deitch picture deitch  ·  22 Feb 2017

Most helpful comment

23

Yep, this is somewhat essential for using minikube or kubernetes from dev-to-prod. We have dozens of developers using minikube and hosted/remote kubernetes VMs with IPs. Everyone cannot be given full domain names (/etc/hosts overrides and generally shoving this down the line into a DNS problem).

Almost all routers that I know of (haproxy, nginx, etc) allow routing based on trailing wildcards, i.e. only the subdomain matters, and the domain doesn't. But here, its reverse, the domain seems to matter and subdomain is allowed a wildcard, which I don't know but seems to be a not-so-common routing policy. I believe this is because Ingress was mostly designed with some specific limitations in mind - like the ambiguity around "how many trailing wildcards to allow", because wildcard in domains matches only up to a dot.

Would make a lot of sense to expose trailing wildcards, and allow the Ingress controller and/or application developer and/or cluster operator to take the final call, instead of having an unnecessary limitation.

rdsubhas picture rdsubhas  ·  2 May 2017

All comments

0

wildcard support is in kubernetes/ingress#8

cmluciano picture cmluciano  ·  22 Feb 2017
20

@cmluciano thanks. I saw that earlier, but didn't think it answers, because I thought:

  1. It mainly refers to the nginx implementation as an ingress controller, not the ingress spec.
  2. It allows wildcards as _sub_domain, but doesn't appear to allow for the _parent_ domain.

I want to be able to do

host: "web.*"

And thus have any request whose host header starts with web. match.

deitch picture deitch  ·  22 Feb 2017
0

@cmluciano and tried it, got an invalid spec error.

deitch picture deitch  ·  27 Feb 2017
0

I think the Ingress spec should clearly state how to treat wildcards/regexp. We have our own Ingress controller and HTTP proxy (Skipper), i.e. we would like to have a clear spec to implement (and not do our own potentially incompatible extension).

hjacobs picture hjacobs  ·  27 Feb 2017
10

@hjacobs I looked at the source code, and it seems only to allow it as the left-most element.

Personally, I would be content to have host: myhost and have the ingress controller know to append .mysub.mydomain.com. But I have yet to find a controller that supports that.

deitch picture deitch  ·  28 Feb 2017
3

+1 for this feature, although I don't need regex. I just want a way that I can specific multiple hosts for a ingress.

Like: https://github.com/kubernetes/ingress/issues/87

Nginx supports it, http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name would remove quite a bit of boilerplate in my app. I would make a PR but my competency is not Go.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
hosts:
- 1.myawesomesite.co
- 2.myawesomesite.co
http:
paths:
- path: /
backend:
serviceName: awesomesite-web
servicePort: 80

klausenbusk picture klausenbusk  ·  20 Mar 2017
0

No additional thoughts on this?

deitch picture deitch  ·  7 Apr 2017
23

Yep, this is somewhat essential for using minikube or kubernetes from dev-to-prod. We have dozens of developers using minikube and hosted/remote kubernetes VMs with IPs. Everyone cannot be given full domain names (/etc/hosts overrides and generally shoving this down the line into a DNS problem).

Almost all routers that I know of (haproxy, nginx, etc) allow routing based on trailing wildcards, i.e. only the subdomain matters, and the domain doesn't. But here, its reverse, the domain seems to matter and subdomain is allowed a wildcard, which I don't know but seems to be a not-so-common routing policy. I believe this is because Ingress was mostly designed with some specific limitations in mind - like the ambiguity around "how many trailing wildcards to allow", because wildcard in domains matches only up to a dot.

Would make a lot of sense to expose trailing wildcards, and allow the Ingress controller and/or application developer and/or cluster operator to take the final call, instead of having an unnecessary limitation.

rdsubhas picture rdsubhas  ·  2 May 2017
0

Thanks @rdsubhas ; well explained.

deitch picture deitch  ·  2 May 2017
3

@deitch until then if anyone needs to do thins in the official nginx ingress, here is a shortcut:

  • Set host: <just the subdomain> in Ingress rule, e.g. host: myapp
  • And then use an init container in the nginx deployment (or daemonset) to replace server_name {{$server.Hostname}}; in the default nginx template with server_name {{$server.Hostname}} {{$server.Hostname}}.*;
rdsubhas picture rdsubhas  ·  2 May 2017
0

@rdsubhas an init container where? In the nginx Deployment / DaemonSet (depending on your deployment preference)? I kind of did something similar with traefik, changing their template. Still, it shouldn't be _this_ hard.

deitch picture deitch  ·  3 May 2017
0

I used this container in the past with this purpose, and it did the job.

https://hub.docker.com/r/jwilder/nginx-proxy/

robermorales picture robermorales  ·  13 May 2017
0

/sig network

xiangpengzhao picture xiangpengzhao  ·  17 Jun 2017
0

Any updates here?

@rdsubhas I am using traefik in one use case (nginx in another), and I did something similar. Actually, since nginx uses go templates, I was able to make the transformation right in the template itself.

The problem I now have is trying to use letsencrypt, most plugins (like traefik's built-in acme support or kube-lego) pull the Host: right out of the Ingress resource (probably correctly). That does mean that any such transformation is going to be missed, since it happens later. Now I need to build support in for that.

Is there any way to create "automatic transform on demand" for resources? E.g. my cluster will transform the Ingress resource upon receipt to modify the Host: section?

deitch picture deitch  ·  25 Aug 2017
16

+1 for this

debianmaster picture debianmaster  ·  18 Oct 2017
8

I confirm this is a huge issue for us.
What is sad is that our ingress controller does support regex matching or wildcard at any position of the domain, but the configuration gets blocked because it doesn't pass validation at Kubernetes level.
Maybe there would be a flag like rawHost or bypassHostValidation to directly pass the value to the ingress controller without any kind of restrictions from Kubernetes ?

kedare picture kedare  ·  14 Nov 2017
0

Ours does as well. Well, we use traefik, and no big deal to change the config to support it.

As a workaround, we use a string that never would be used anywhere in out .yml files (anydomain123 for what it's worth), and then have our traefik config parse and replace that with a wildcard.

Maybe there would be a flag like rawHost or bypassHostValidation

Or, just let it go through no matter what.

deitch picture deitch  ·  14 Nov 2017
2

This is extremely important to us as well -- our user story goes something like this:

As an Application Engineer, I want ingress rules to match on the start of a host pattern (like foo.* so that I can use the same ingress definition across environments (foo.dev, foo.qa, etc.) without transformation so that the risk of error switching across environments is reduced significantly. Without this feature, I'm not deploying the same thing to every environment, which can lead to errors and confusion during cluster operations and deployments.

There's a talk about "the spec" and "the code" in this thread - I could probably figure out the code, but how does "the spec" get approved/changed/whatever'd so that we can update the code to match our desired behavior?

Preskton picture Preskton  ·  9 Feb 2018
4

I, too, would be happy to do a PR, but only if someone can point me into what is needed for the spec to change and then the code, and more importantly that it is supported in principle.

deitch picture deitch  ·  10 Feb 2018
3

This is a feature which allows ingress to be useful. Without it the yaml definition file for an app (ingress + deployment + service) cannot be environment independant. Without it you end up with a proxy application / loadbalancer infront of the ingress just to change the url to a common non routable value.

just supporting the * in the domain as a single part would be sufficient. ie
svc.*.domain

Or to support domain as a field. eg for x.y.com
Host x
Domain: y.com

With the ability to load the domain from config map. Then it would be handled in a simmilar way to the application config.

DavidWylie picture DavidWylie  ·  19 Feb 2018
1

I think, from a Spec perspective, having it as a FQDN helps a lot of "standard/kubernetes compliant" resources to happen. Although the API is called Ingress, this has a wider impact than just routing. Because if the domain is unspecified, then things like issuing letsencrypt certificates, or creating DNS names for services, etc. are going to become really hard. Different Kubernetes cloud providers would start interpreting the spec differently if its no longer a FQDN, which _could_ lead to fragmentation (wildcards vs regexes, PCRE regex vs POSIX regex, etc).

While its true that development is hard, supporting domain prefixes _could_ be done today. If we specify the host: foo - it is indeed considered a valid FQDN. We can instrument the ingress controller (or dns/ssl controllers) to automatically interpret the host as foo.<real-domain>. As a cluster admin, we presently patch the nginx ingress controller to add our production suffixes automatically if not present, and our engineers only use subdomains.

Just two cents, maybe pressuring downstream API controllers (like dns/ssl/ingress controllers, and maybe google cloud ingress ;) to support suffixes/prefixes to the host is a better/longer term solution, than making the spec itself widely open to interpretation and being stringly typed.

rdsubhas picture rdsubhas  ·  19 Feb 2018
1

@rdsubhas Looking into this in the issues form some of the implementors of the ingress controller spec. There almost standard response is its not in the spec so we dont want to differ from it.
Even just a standard field or annotation would be enough to get some of them moving in a shared direction. you seem to have hit the nail on the head with the foo. with that the real domain is a seperate piece of data which as an optional thing could be a string or loaded form a config map.

DavidWylie picture DavidWylie  ·  19 Feb 2018
11

Looks like I stirred up a bit of a hornet's nest with this one... which means it matters to people.

Perhaps the strongest sign is that every time I interact with someone who deploys to kubernetes clusters with an automated CD pipeline across multiple environments, we always end up discussing, "so how did you hack around the Ingress Host: limitation?" If so many people are doing it, then it already is fragmenting, but at a per-deployment level. Fragmenting across ingress controllers might be an improvement. :-)

If one of the key goals of kubernetes is making services easy to deploy and - "automating devops" like Kelsey's interview last week, if you will - then the goal is practical: how do I make deploying services config-driven, reliable, reproducible, scalable. Requiring the config on each exposed service to be different from one environment to another makes an automated CD pipeline brittle and extremely difficult (and hacked and fragmented). I need to maintain separate config files, when they differ only by the ending of the domain.

I am unclear is to why the spec for an FQDN must be the spec for specifying what service X should respond to? (I also just violated the spec of not ending a sentence with a preposition, oops :-) )

Agreed wholeheartedly, it needs a standard, and the current one is forcing people to break it in implementation. I _do_ think that using a standard that wasn't written for specifying services deployed and identified dynamically in multiple environments is the best one to use. If there isn't a better, let's define one. If you want to call it HostRegex:, that works, too. Call it HostPrefix, or anything you want.

maybe pressuring downstream API controllers

Isn't the way to pressure IngressController creators by defining a spec?

In any case, I much appreciate the feedback and time spent on this issue.

deitch picture deitch  ·  19 Feb 2018
1

I like all this discussion: this is fun. :)

As a newbie here, it feels like "changing the spec" is a really big deal, as I'm sure there are all kinds of downstream implications, like @rdsubhas implies. Outside the current discussion, I have a couple of more meta-questions:

  • Where is "the spec"? I assume there's something deeper than https://kubernetes.io/docs/concepts/services-networking/ingress/?
  • How would someone introduce a proposed change to "the spec"? Is it strictly via the SIGs?
  • Who are the "IngressController creators? How does a change to the "the spec" get voted on/ratified/whatever?
  • When is it preferable to split out a new annotation vs. a new property?

This is pretty offtopic, so happy to take it to DMs/Slack if that makes more sense.

Preskton picture Preskton  ·  19 Feb 2018
-5

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot  ·  20 May 2018
16

Are there any results or changes for this issue? We really need to use * to specify a set of subdomains. The approach with listing of all possible subdomains is not suitable for us, because the number of subdomains is too large. It was very nice to use *. We found an alternative implementation of IngressController, but we can not use this, because our entire infrastructure is already built on Nginx Ingress.

andrewtar picture andrewtar  ·  29 May 2018
2

Same here, we would love to see the wildcard in the path variable like /index-* ..

JannikZed picture JannikZed  ·  6 Jun 2018
0
  • 1
santiagopoli picture santiagopoli  ·  12 Jun 2018
3

/remove-lifecycle stale

olemarkus picture olemarkus  ·  22 Jun 2018
0

@rdsubhas Here is my implementation of what you suggested, with nginx-ingress helm chart :

values.yaml

controller:
  extraInitContainers:
    - name: custom-template
      image: "quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.15.0"
      command: ["/bin/sh","-c"]
      args: ["sed -e 's/server_name {{ \\$server.Hostname }}/server_name {{ $server.Hostname }} {{ $server.Hostname }}.*/g' /etc/nginx/template/nginx.tmpl > /templates/nginx.tmpl"]
      volumeMounts:
      - mountPath: /templates
        name: nginx-template-volume
  extraVolumeMounts: 
    - mountPath: /etc/nginx/template
      name: nginx-template-volume
      readOnly: true
  extraVolumes:
    - name: nginx-template-volume
      emptyDir: {}

then

helm upgrade --install nginx-ingress stable/nginx-ingress -f values.yaml

Although I'm not super happy that the docker image version is hardcoded there. If you have an idea about how to make that any better, happy to hear.

licarth picture licarth  ·  5 Jul 2018
-1

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot  ·  3 Oct 2018
0

Can please someone un-stale it?

haizaar picture haizaar  ·  5 Oct 2018
0

/remove-lifecycle stale

deitch picture deitch  ·  5 Oct 2018
3

Hello guys,

Any update ?

I want to configure my ingress rule with regex on host like this :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-site
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "route"
    nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"
    nginx.ingress.kubernetes.io/rewrite-target: /site
    ingress.kubernetes.io/configuration-snippet: |
    #This regex works very well
        if ($host = 'test.toto.[a-z]') {
          rewrite ^ test.toto.com/[a-z]$request_uri permanent;
        }  
spec:
  rules:
  - host: test.toto.com
    http:
      paths:
      - path: /
        backend:
          serviceName: hippocms
          servicePort: 8080
  - host: test.toto.[a-z]  #This regex doesn't work
    http:
      paths:
      - path: /
        backend:
          serviceName: hippocms
          servicePort: 8080

Thanks for your help.

MohamedKhelifi picture MohamedKhelifi  ·  10 Oct 2018
0

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot  ·  8 Jan 2019
13

/remove-lifecycle stale

deitch picture deitch  ·  8 Jan 2019
8

+1 for this... I'm trying to map *.*.domain and I can't :(

WoLfulus picture WoLfulus  ·  15 Apr 2019
0

Does https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/ reference the desired behaviour that this PR requests? (For paths, not domains)

swoldemi picture swoldemi  ·  26 Apr 2019
1

@swoldemi possibly, but:

  1. It doesn't support domains, which is the larger issue to handle deployment to multiple environments.
  2. it is specific to nginx, and thus not an official part of the Ingress api
deitch picture deitch  ·  28 Apr 2019
0

Any update?
I need Host: test-*.mydomain.com,but it doesn't work because it doesn't pass validation at Kubernetes level.
I'm use the traefik controller,or any other way?

himao picture himao  ·  5 May 2019
3

@himao it's not a 'supported' way but with traefik ingress controller I simply enabled the file backend and then manually created the following snippet/file:

[backends]
  [backends.gitlab-pages]
    [backends.gitlab-pages.servers]
      [backends.gitlab-pages.servers.server0]
        url = "http://gitlab.default:80"
        weight = 1

[frontends]
  [frontends.gitlab-pages]
    backend = "gitlab-pages"
    passHostHeader = true
  [frontends.gitlab-pages.routes]
    [frontends.gitlab-pages.routes.route0]
      rule = 'HostRegexp:{subdomain:[A-Za-z0-9\-]+}.pages.foodomain.com'

While I'm using a persistent volume to mount the folder containing my rules files you could easily use a ConfigMap volume and manage everything with cluster resources. I've been doing this for a couple years now and never had an issue with it. It's not super 'clean' but it works for me.

travisghansen picture travisghansen  ·  5 May 2019
0

@travisghansen thank u,i will try it.

himao picture himao  ·  5 May 2019
0

I like it @travisghansen . But as you said, "it's not super clean." This thing really should be.

deitch picture deitch  ·  5 May 2019
0

@travisghansen Does sticky session works when using this method?

shinebayar-g picture shinebayar-g  ·  5 May 2019
2

@deitch yeah, I unfortunately don't think it's going to happen with the Ingress spec. As some of the teams are working on IngressRoute as CRDs maybe some day the next-gen spec will support it.

travisghansen picture travisghansen  ·  5 May 2019
0

@shinebayar-g not really. The example has a single backend pointing to the kubernetes Service so as far a traefik is concerned it's a single endpoint. If you have stable pod names (ie: StatefulSet) you could do sticky sessions but otherwise that's one of the (several) downsides.

travisghansen picture travisghansen  ·  5 May 2019
-5

Ingress is sort of lowest-common-API. As such it will probably not get more than simple prefix matching. The KEP to move to GA details some places we can clean up the spec, but it wil not get much more featureful.

https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20190125-ingress-api-group.md

There will be a followup APi which has possibly more capabilities.

thockin picture thockin  ·  9 May 2019
16

There is an annotation for ingress object:
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-alias

nginx.ingress.kubernetes.io/server-alias: "<alias>"

So ingress object will be:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ some name }}
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/server-alias: "*.{{ domain }}"
spec:
  tls:
  - hosts: 
    - {{ domain }}
  rules:
  - host: {{ domain }}
    http:
      paths:
      - path: /
        backend:
          serviceName: {{ svc name }}
          servicePort: {{ svc port }}

And server name in the nginx.conf will be

server_name {{ domain }} *.{{ domain }};
desmatz picture desmatz  ·  4 Jun 2019
3

@desmatz that works well for nginx, but it is a specific implementation, not API standard, and thus won't work with other IngressControllers

deitch picture deitch  ·  4 Jun 2019
0

@thockin wrote:

There will be a followup API which has possibly more capabilities.

Is there information about it?

deitch picture deitch  ·  4 Jun 2019
0

Ingress is sort of lowest-common-API. As such it will probably not get more than simple prefix matching. The KEP to move to GA details some places we can clean up the spec, but it wil not get much more featureful.

I agree. But some regex in DNS is also lowest common API. It would be horrible to support stuff like
abc-*.foo.com. But host names like *.foo.com and supporting domain prefixes seem to be reasonable features.

https://www.ietf.org/rfc/rfc4592.txt

adgang picture adgang  ·  5 Jun 2019
8

IMHO, this issue should be reopened. We need support at least for listing multiple hosts or specifying glob-like wildcards, if regex is not feasible.

demisx picture demisx  ·  23 Jan 2020
0

/reopen

deitch picture deitch  ·  23 Jan 2020
0

@deitch: Reopened this issue.

In response to this:

/reopen

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/test-infra repository.

k8s-ci-robot picture k8s-ci-robot  ·  23 Jan 2020
0

/remove-triage unresolved
/assign @bowei for Ingress

caseydavenport picture caseydavenport  ·  19 Mar 2020
0

@caseydavenport: The label(s) kind/enhancement cannot be applied, because the repository doesn't have them

In response to this:

/kind enhancement
/remove-triage unresolved
/assign @bowei for Ingress

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/test-infra repository.

k8s-ci-robot picture k8s-ci-robot  ·  19 Mar 2020
1

/kind feature

caseydavenport picture caseydavenport  ·  19 Mar 2020
0

@caseydavenport: Those labels are not set on the issue: triage/unresolved

In response to this:

/remove-triage unresolved
/assign @bowei for Ingress

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/test-infra repository.

k8s-ci-robot picture k8s-ci-robot  ·  19 Mar 2020
4

@deitch Kubernetes 1.18 has been released with some enhancements, as you can see here: https://kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/

One of them is the support for wildcard in hostname, and a better handling of Path.

As a remember that this an API change and also needs some attention of each ingress controller implementation, do you think it's enough and the issue can be closed?

Thank you

rikatz picture rikatz  ·  3 Apr 2020
0

Hi @rikatz . Unless I misunderstood the release notes (thanks for referencing them here; I read the k8s 1.18 release notes in general, and missed the ingress part. Oops. :-) ), it doesn't do it.

The wildcard support listed there is *.foo.com, while this is looking for the exact opposite, api.*. However, if the wildcard support is more generalized and I misunderstood, such that api.* and web.* or even web.*.foo.com would work, then, yes, indeed, it solves it.

Do you mind clarifying?

deitch picture deitch  ·  5 Apr 2020
0

No, it does not work.

The idea of wildcard is to have a catchall for a specific domain like *.yoursite.com, so I don't think it covers the original case

rikatz picture rikatz  ·  6 Apr 2020
2

Then I think we should leave this open. Here was from the original issue:

The specific use case is as follows. I have a set of k8s resources being deployed to multiple environments, e.g. prod, uat, qa. Each one has its own inbound root domain, e.g. prod.mydomain.com, qa.mydomain.com, uat.mydomain.com.

When I create my k8s resources, I want to use identical ones between all the environments. If I have 3 exposed services (e.g. web, api, magic) in each domain, routed by subdomain, I shouldn't require 3 separate ingresses, one for each environment, per exposed service. Instead, I want to do something like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: web
spec:
  rules:
  - host: "web.*"
    http:
      paths:
      - path: /
        backend:
          serviceName: web-service
          servicePort: 80
deitch picture deitch  ·  6 Apr 2020
1

We've had requests for the suffix wildcard. Unfortunately, this doesn't seem to interact well with CertManager that interprets the Host field as domains to register certificates.

bowei picture bowei  ·  6 Apr 2020
0

It would be good to work through how those use case will work with the wildcard suffix. For example, DNS integrations look at the host field to register names. How will it work in that case, etc...

bowei picture bowei  ·  6 Apr 2020
0

I am quite aware that foo.* is not compliant with the RFC, which is probably the certmanager issue. Lots of code depends on that.

The issue is that what we are trying to do here is very much with the cloud-native philosophy. If I need to maintain different Ingress configs for 3 different clusters, solely because they are in different environments (prod, qa, dev1, etc.) but are otherwise identical, that is a lot of overhead and boilerplate. They became more "pet-like".

deitch picture deitch  ·  6 Apr 2020
2

That's a valid use case, but we need to be careful not to break existing integrations when we add functionality. For example, expanding the set of valid host paths requires a new API version. There is the issue with being able to be supported by all implementations. It requires some thought, that's why it cannot be done unilaterally.

bowei picture bowei  ·  6 Apr 2020
2

@rikatz would the related 1.18 enhancement allow for *-foo.bar.com match both a-foo.bar.com and b-foo.bar.com

This is what we need in one of the projects I am involved and this is why I have been following this ticket

gae123 picture gae123  ·  9 Apr 2020
0

@rikatz would the related 1.18 enhancement allow for *-foo.bar.com match both a-foo.bar.com and b-foo.bar.com

This is what we need in one of the projects I am involved and this is why I have been following this ticket

By my tests no. It supports *.domain.com or *.system.domain.com, but not a sub-registry wildcard (as *-a.example.com, *xpto.example.com).

rikatz picture rikatz  ·  9 Apr 2020
0

@deitch until then if anyone needs to do thins in the official nginx ingress, here is a shortcut:

* Set `host: <just the subdomain>` in Ingress rule, e.g. `host: myapp`

* And then use an init container in the nginx deployment (or daemonset) to replace `server_name {{$server.Hostname}};` in the default nginx template with `server_name {{$server.Hostname}} {{$server.Hostname}}.*;`

I was able to setup this patch in my controller deployment. It worked well for most cases, but the --enable-ssl-passthrough cases weren't responding the the shortened hostname ingress. I don't suppose anyone knows what else would need to be patched to make 'nginx.ingress.kubernetes.io/ssl-passthrough: "true"' cases react to an ingress using a hostname without a domain?

crfrase picture crfrase  ·  20 May 2020
0

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot  ·  18 Aug 2020
0

/remove-lifecycle stale

deitch picture deitch  ·  18 Aug 2020
0

Any update here?

volnei picture volnei  ·  24 Aug 2020
0

I was interested in this too, because I have many domains (and new ones added often) that will use the same site essentially, but they each one their own domain. But @bowei poses a critical problem. If certs were given out like this, web.somehacker.com could point to your site and get a cert and open you up for new types of security bugs.

kobenauf picture kobenauf  ·  21 Sep 2020
0

I would not expect that certs need to follow suit

On Mon, Sep 21, 2020, 3:16 PM Kip Obenauf notifications@github.com wrote:

I was interested in this too, because I have many domains (and new ones
added often) that will use the same site essentially, but they each one
their own domain. But @bowei https://github.com/bowei poses a critical
problem. If certs were given out like this, web.somehacker.com could
point to your site and get a cert and open you up for new types of security
bugs.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/kubernetes/issues/41881#issuecomment-696317230,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABLPYFGDJMTWGG6O3KQEWTSG6RCTANCNFSM4DBCGI5A
.

chrisjohnson picture chrisjohnson  ·  21 Sep 2020
0

@deitch Please take a look at the recent wildcard support that we added in 1.18 & 1.19 and let us know if this helps your use-case.

https://kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/#support-for-hostname-wildcards
https://opensource.googleblog.com/2020/09/kubernetes-ingress-goes-ga.html

cmluciano picture cmluciano  ·  6 Oct 2020
0

/assign

cmluciano picture cmluciano  ·  6 Oct 2020
-1

Checking the description it seems to imply that it's not a full wildcard, only a suffix match

Precise matches require that the http host header matches the Host setting. Wildcard matches require the http host header is equal to the suffix of the wildcard rule.

For my use case, where it's the domain itself that I want to be wildcarded (i.e. service-name.* will match service-name.dev.mysite.com or service-name.production.mysite.com). The intention is to let the ingress rule live with the service definition without hard-coupling it to the exact domain that I end up using within a given cluster.

Right now I'm working around this by using interpolation before I generate the yaml but it does create some ugly hurdles. It would be a lot nicer if the actual API supported real wildcards and not just suffix matching.

chrisjohnson picture chrisjohnson  ·  6 Oct 2020
1

We might need to rename the issue title because everyone here, me included, is requesting at least a support for wildcards as suffix, e.g.:

  • www.*
  • dev-www.*
  • dev.www.*
silverkorn picture silverkorn  ·  17 Oct 2020
0

I think the title and original issue body still imply what we are looking for, specifically full wildcard support (with the example given showing that it's not just suffix matching). I think @cmluciano was just pointing to a new feature that may help with some of the needs of some people here, not necessarily implying that the whole issue was now solved.

One thing that might need to be changed is updating the documentation and/or changelog/etc to rename "wildcard" to "suffix matching" since that's really all that was implemented

chrisjohnson picture chrisjohnson  ·  19 Oct 2020
1

I'm checking with others in the Ingress community to see if this is something that might be possible

cmluciano picture cmluciano  ·  19 Oct 2020
0

@cmluciano Were you able to find out if this was possible? It looks like both @johnreytanquinco & @deitch are looking for a wildcard capability on the "top-level-domain". I don't see this anywhere in the Ingress documentation for Kubernetes.
The docs say we can set a wildcard for the subdomain not not domain or TLD.

https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards

Example:
website.* could mean website.io, or website.org, website.com,

distributethe6ix picture distributethe6ix  ·  5 Nov 2020