Skip to content
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

Closed
jon-shanks opened this issue Jul 24, 2017 · 5 comments
Closed

tie domains to namespaces #1008

jon-shanks opened this issue Jul 24, 2017 · 5 comments

Comments

@jon-shanks
Copy link

jon-shanks commented Jul 24, 2017

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.

@kfox1111
Copy link

needs to be optional though.

@jon-shanks
Copy link
Author

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).

@pieterlange
Copy link
Contributor

This will (probably) eventually be solved with Ingress claims (like volume claims). Until then you can use Ingress classes. Some more context:

@jon-shanks
Copy link
Author

jon-shanks commented Jul 25, 2017

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.

@aledbf
Copy link
Member

aledbf commented Nov 4, 2017

Closing. This must be defined in the ingress spec. There is nothing we can do in a particular ingress controller.
Please check the loadbalancer claim https://docs.google.com/document/d/1Kj9OcTQdERZgNkZhdDxnQeT-TI4DLqqg62lShnboT6s/edit?usp=sharing

@aledbf aledbf closed this as completed Nov 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants