-
Notifications
You must be signed in to change notification settings - Fork 163
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
fix(controller): copy ownerreference from oldNs on namespace UPDATE admission requests #768
Conversation
✅ Deploy Preview for capsule-documentation canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I would like just to have as a sort of double-check a review from @MaxFedotov.
@oliverbaehler Hey! And why use And the other thing I'm thinking about is that we are breaking a bit an idea of @prometherion, and do we actually need this check at all: What if we add here: https://github.com/clastix/capsule/blob/7becdbaf799582426e4b5c5bc06753e7ae867a7b/pkg/webhook/ownerreference/patching.go#L51-L55 The code to set |
It seems Max is correct here.
Same here, although wondering why Flux started misbehaving correctly. @oliverbaehler it would be helpful to understand what's going on before getting this merged. I'm gonna remove this from the v0.3.2 milestone since we have to release some security fixes. |
@MaxFedotov Thanks for your inputs. I wasn't sure on sideEffects, what it really meant. The dynamic admission controller doc seemed a bit vague to me. But you are right, since the webhook only operates on the admission request, the side-effect of Regarding the behaviour, my assumption would be that somehow ownerreferences do not resolve the same way (if they do, when executing a dry-run). That's at least why the code blocked any update. I will have to do some testing and dig some code to verify that suspicion. Kustomize-Controller: Here the Apply is made (differs based on resources to create). For namespace the apply is made here: The apply operation is from the common pkg ssa, this invokes at some point a dryRun Operation before the actual apply: |
@oliverbaehler @MaxFedotov it seems to me this issue is stale. Please, share if we should refactor this PR or if it can be closed. |
@prometherion one of our production clusters only works with that fix. However we are currently redesgning flux etc with the tenancy. Lets just kept open. Maybe we will discover the same issues. If so we ll build the suggested fix from max |
The current approach would patch all Ownerreferences from the oldObject to the newObject. From my point of view this prevents ownerreferences from being removed or tampered (except if you are not part of capsule-users, which is now also the case). What we noticed, even with the DryRun patch, the flux kustomize/helm controller kept failing. The reconciles which would attempt to UPDATE namespaces, would always fail here: https://github.com/clastix/capsule/blob/master/pkg/webhook/namespace/owner_reference.go#L54 While i can't make an accurate statement about what's happening, one thing is sure: On Reconcile Operations these two controllers try to apply the namespaces without ownerreferences. Anyway with this patch everything works fine for. What do you guys think? @prometherion @MaxFedotov |
I reviewed it, and it looks safe to me. The proposed handler was primarily implemented to prevent privilege escalation, which has been then covered with a specific e2e feature test and it's not failing, besides the flakiness we're used to with GH actions. @MaxFedotov I'm for merging it, please, let me know if it's ok for you too. |
✅ Deploy Preview for capsule-documentation canceled.
|
…dmission requests Signed-off-by: Oliver Bähler <[email protected]>
Fixes behaviour mentioned in thread:
Since the flux
kustomize-controller
runs a dry-run operation with it's server-side apply, we can skip these. Since Dry-Run operations are not persisted into etcd.I have change the
sideEffect
of the hook because it matches it's description:NoneOnDryRun
: calling the webhook will possibly have side effects, but if a request with dryRun: true is sent to the webhook, the webhook will suppress the side effects (the webhook is dryRun-aware).Not really sure what that even does, but the hook is now dry-run aware.