finalizer doesnt works when deleting with service account
Closed this issue · 8 comments
Hello
Not sure if its HNC fault or something with openshift/kubernetes..
Im trying to creat UI for HNC using NodeJS.
So I delete and create the HNC objects using serviceAccount token.
Lets say I create the next namespaces tree:
test
---- [s] test1
---- [s] test2
when I try to delete subnamespace test1 with my user by running kubectl delete subns test1 -n test it gives me an error:
Error from server (Forbidden): qdmission webhook ..... subnamesoace test1 is not a leaf and doesn't allow cascading deletion. Please set allowCascadingDeletion flag or make it a leaf first.
which is good.
But when I login using the service account token, and then try to run the same command, it just deletes the subns, and test1 becomes a normal namespace with broken hierarchyconfiguration/hierarchy
I also tried deleting with curl using service account token and mentioning propagationPolicy 'Background' or 'Foreground',
nothing helps.
environment: openshift 4.10.26
kubernetes version: v1.23.5
@erikgb do you know anything?
maybe its something webhook related..
sorry i dont know how it works
well i see the problem now
checking the webhook i found thag it just passes any request from hnc service account:
https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/564b4a968ca2091f27cf0eb51d0cd99190e57db5/internal/anchor/validator.go#L48C24-L48C24
and looking here i see that if check if the service account is in the hnc-system namespace:
https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/internal/webhooks/webhooks.go#L24
so if i do my application in a separate namespace than hnc-system everything works as expected
i dont even know whats the right thing,
i guess i will put my hnc-ui in a separate namespace but i though its better if they are in the same namespace.
well i guess i have a solution, so imma close the case
Oh, you were using the HNC service account! Wild. Yes, HNC never blocks its own operation, and that test has always been good enough until now.
If you want to narrow the scope of that test, I suppose we could try that? We copied that code from Gatekeeper, I'm not sure why they didn't use an explicitly named service account.
Oh, you were using the HNC service account
no i created a separate service account for my application, it was just in the same namespace
We copied that code from Gatekeeper, I'm not sure why they didn't use an explicitly named service account.
yes i was also a bit confused at the start why hnc is running with the default service account, so i thought you know better
should i create a pr for: ?
- make a new service account instead of running with default
- change the webhook to also check for the service account name (not sure about my skills in go)
the tests will take a while tho
im really starting to consider installing a non airgapped kubernetes environment
Sorry, yes, you were using a service account in the HNC namespace. We'd never anticipated that.
Yes, you could make a PR that changed HNC to use a non-default SA, and then check specifically for that SA name.
@adrianludwin Sorry I think its actually better to separate my hnc-ui application to a different namespace, its more correct, and creating a PR is a lot of work for a small profit (lot of work because i dont know go)