-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tie domains to namespaces #1008
Comments
needs to be optional though. |
yep, exactly, essentially if it was enabled, it would validate the domain used for that namespace, also has a corresponding annotation on the namespace itself. It's more to put constraints around the service really, (optionally). |
This will (probably) eventually be solved with Ingress claims (like volume claims). Until then you can use Ingress classes. Some more context: |
I'm not quite sure that achieves what we were looking for. This would mean we need to run multiple ingress controllers for each domain, defining a domain at the ingress.class level. What we really want is one ingress that is shared but to affiliate some logic to the namespace that the ingress can validate. Also if a project defines the claim, then they in theory could just claim that domain is theirs, you'd have no way of validating the authenticity of whether someone could or couldn't use that domain for that namespace in that multitenancy approach, once the DNS was pointing to the same cluster. |
Closing. This must be defined in the ingress spec. There is nothing we can do in a particular ingress controller. |
Not sure on others thoughts on this. But it would be good to be able to control somehow, (though may break the model and hence could be a feature flag), limiting what namespaces are responsible for which domains.
If your cluster is being used in some form of mult-tenancy way i.e. lots of projects self-serving, there is a risk that another service, could in theory, deploy an ingress for another service's domain. As the DNS is already pointing to the cluster.
Also it's possible to redirect a service location to your service, depending on the order i.e. /admin now goes to some pods that are not hosted in the namespace you'd expect for that service.
We are thinking of extending the ingress controller with a feature domain_validation, to check the annotations of a namespace to see if there are listed domains that namespace can use. This would prevent other services either accidentally or deliberately using domains they shouldn't.
The text was updated successfully, but these errors were encountered: