-
Notifications
You must be signed in to change notification settings - Fork 162
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
Ingress hostname collision check at Tenant level #358
Comments
I think we can try to address this with a fine grained control, at multiple levels. We could do a change to the apiVersion: capsule.clastix.io/v1alpha1
kind: CapsuleConfiguration
spec:
hostnameCollision:
enabled: # boolean
scope: # enum=Cluster;Tenant;Namespace
strict: # bool The The change could be considered breaking but we haven't yet released the CRD, so we can plan this for the upcoming v0.1.0 release. We should also consider if this must be a global configuration or if this could be implemented at Tenant level, keeping the actual |
A Tenant level check is more powerful. +1 In addition, we should consider to review the meaning of Proposal is: prevent hostname collision across tenants during Ingress provisioning not during tenant provisioning. Tenant provisioning is matter of cluster admin and it should not be managed by Capsule. |
Couldn't agree more. This means we're going to deprecate this option in the CapsuleConfiguration CRD and moving this to the Tenant specification. I'd suggest also a refactoring on how structuring the API, something as a new parameter, eg. |
Problem statement
Going to think about how to refactor the ingress hostname collision checks in Capsule since it looks there is still a grey area there
Capsule in
v1beta1
implements two different kinds of check for hostname collisionOption
allowTenantIngressHostnamesCollision
This implement is a check on the Tenant custom resource creation about the allowed list of
tenant.spec.ingressHostnames.allowed
preventing the cluster admin to create two tenants using the same allowed hostname list:Only the first tenant is created. However, the
allowTenantIngressHostnamesCollision
check does not apply to regexBoth the
gold
andsilver
tenants above can now use the same domainclastix.io
.Option
allowIngressHostnameCollision
As tenant admin, let's to create a couple of namespaces in each tenant:
Working on both the tenants
Good job! Capsule prevents the same
webapp.clastix.io
hostname across namespaces because of theallowIngressHostnameCollision=false
.Working on the
gold-production
tenant onlyHowever, if we have to cordon the
https://goldapp.clastix.io/testpath
from public accessThe second ingress is denied because of the same
goldapp.clastix.io
across namespaces andallowIngressHostnameCollision=false
. This is very common as pointed out by @MaxFedotov.As cluster admin, let's to allow hostname collision by putting
allowIngressHostnameCollision=true
in Capsule configuration.As tenant admin, now it's possible to create two ingresses in the same namespace with the same hostname
goldapp.clastix.io
but different pathsNow there are no checks to prevent tenant owner to:
Proposal
Long story here to say we have to address three common scenarios, from high to low priority
Unfortunately, the current implementation of
allowTenantIngressHostnamesCollision
does not help here and, in general, it has a limited utility (imho).allowTenantIngressHostnamesCollision
to prevent hostname collision across tenants at runtime (first scenario)allowIngressHostnameCollision
to prevent hostname collision across namespaces of the same tenant (second scenario)@prometherion @MaxFedotov please, comment.
The text was updated successfully, but these errors were encountered: