profile
viewpoint

Ask questionsMake programmable deny of wildcard hostnames

Let's assume that we had a big organization, having a domain bigorg.com and there are two tenants, gas and oil. Let's also assume, that we are using some type of automatization, in order to publish ingress hosts to DNS automatically (like https://github.com/kubernetes-sigs/external-dns/)

Ingresses supports wildcard hostnames (https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards)

As a tenant-owner of gas, I create ingress with the host like - host: "*.bigorg.com". That can lead to big problems for an oil tenant, which may create ingress with -host: oil.bigorg.com (and for other tenants in a cluster)

So maybe we had to think about a webhook, that can be enabled by cluster-admin in order to deny wildcard names in ingresses.

But on the other hand, guys from gas Tenant can buy a domain like mygas.com, which will be used only by them. And they want to create a single ingress in order to handle all requests to *.mygas.com.

So there should be a list of domains for Tenants, where wildcard ingress host may be created. All other wildcard ingress hosts should be denied by a webhook (if it is enabled)

Originally posted by @MaxFedotov in https://github.com/clastix/capsule/issues/214#issuecomment-790486783

clastix/capsule

Answer questions prometherion

For the v1beta1 (and deprecated v1alpha1) versions, this check can be put in place using the annotation capsule.clastix.io/deny-wildcard=true.

The default value, since annotation key is not available, is false.

useful!

Related questions

No questions were found.
source:https://uonfu.com/
answerer
Dario Tranchitella prometherion @HAProxyTech Turin (IT) https://stackoverflow.com/users/10104472/prometherion Former full stack developer, switched to the dark-side of DevOps!
Github User Rank List