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

Make programmable deny of wildcard hostnames #219

Closed
prometherion opened this issue Mar 6, 2021 · 7 comments · Fixed by #417 or #433
Closed

Make programmable deny of wildcard hostnames #219

prometherion opened this issue Mar 6, 2021 · 7 comments · Fixed by #417 or #433
Assignees
Labels
enhancement New feature or request medium-priority Feature Request with medium-priority
Milestone

Comments

@prometherion
Copy link
Member

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 #214 (comment)

@prometherion prometherion added enhancement New feature or request medium-priority Feature Request with medium-priority labels Mar 6, 2021
@MaxFedotov
Copy link
Collaborator

I thought one more time and basically, that's not an issue, as we can use negative lookahead in ingressHostnames.allowedRegex to achieve it. Something like ^(?!\*.(bigorg|org).*).*$

@prometherion what do you think? Should this work?

@prometherion
Copy link
Member Author

Negative lookahead regexes are not supported in Go 😞 (more context: here)

@MaxFedotov
Copy link
Collaborator

Damn, forgot about it :( Then we will have to add another field to CRD, like ingressHostnames.deniedRegex?

@prometherion
Copy link
Member Author

Regarding this, can we just put an additional field to the allowed hostnames specifying if we're accepting wildcards domain or not?

Something as follows:

apiVersion: capsule.clastix.io/v1alpha1
kind: Tenant
metadata:
  name: oil
spec:
  ingressHostnames:
    allowed:
      - my.oil.acmecorp.com
      - my.gas.acmecorp.com
    allowedRegex: "^.*acmecorp.com$"
    denyWildcard: <bool>

When denyWildcard is enabled, Ingresses hostnames must be FQDN, otherwise, we're not doing any kind of check.

@MaxFedotov
Copy link
Collaborator

@prometherion great idea! Let's do it after new spec be released :)

@prometherion
Copy link
Member Author

We missed this for v0.1.0, let's plan for v0.1.1

@prometherion
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request medium-priority Feature Request with medium-priority
Projects
None yet
3 participants