fix(sandboxcr): bind Sandbox mutations to the authorized incarnation - #823
AnshulPatil2005 wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #823 +/- ##
=======================================
Coverage 83.08% 83.08%
=======================================
Files 259 259
Lines 22555 22568 +13
=======================================
+ Hits 18739 18750 +11
- Misses 3093 3094 +1
- Partials 723 724 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
606b9e6 to
23d987a
Compare
Authorization resolves one specific Sandbox, but the re-reads and the delete below resolve by namespace and name only. A Sandbox recreated under the same name in that window is adopted and mutated in place of the one the caller was authorized for. An ordinary informer propagation delay is enough. InplaceRefresh and retryUpdate now reject a re-read whose UID differs from the object the caller holds, and deleteSandbox sends the UID as a delete precondition so the API server cannot resolve the name onto a replacement. A mismatch surfaces as NotFound: the Sandbox the caller was authorized for is gone, which is what the API layer should report rather than acting on its successor. An object with no UID was never read from the API server, so there is nothing to compare and the check is skipped. This covers the direct Sandbox writes in openkruise#792. The derived-resource boundaries, Snapshot and TrafficPolicy, are untouched. Refs openkruise#792 Signed-off-by: Anshul <anshulpatil1022@gmail.com>
23d987a to
d0da0d2
Compare
I. Describe what this PR does
Covers the direct Sandbox writes from #792, not the whole issue.
InplaceRefreshandretryUpdateboth re-read byObjectKeyand adopt whatever comes back, anddeleteSandboxwas a bareclient.Delete. So once a same-name Sandbox exists, an operation authorized against the old one can refresh onto the new one, update it, or delete it.Both re-reads now reject an object whose UID differs from the one the caller holds, and the delete sends the UID as a precondition so the API server cannot resolve the name onto a replacement.
A mismatch surfaces as
NotFound. From the caller's side the Sandbox it was authorized for really is gone, and the API layer already maps not-found to 404, so nothing new is needed there to stop the operation.An object with no UID was never read from the API server, so there is nothing to compare against and the check is skipped. That keeps synthetic wrappers working rather than failing them closed on a comparison that cannot be made.
II. Does this pull request fix one issue?
Refs #792. Direct Sandbox writes only.
III. Describe how to verify it
go test ./pkg/sandbox-manager/infra/sandboxcr/ -run TestSandbox_IncarnationBinding -count=1The table covers same UID, a replacement UID, and both synthetic cases. The delete case reads the applied
DeleteOptionsthrough an interceptor and asserts the precondition is present with a real UID and absent without one.IV. Special notes for reviews
Deliberately partial, and I would rather check the scope than guess at it. Snapshot and TrafficPolicy are the derived-resource half of the issue and they need a different shape of fix: binding the Pod incarnation, not just the Sandbox. If you would prefer this landed as one change covering all of it, say so and I will fold them in rather than split it.
The other thing worth a second opinion is
NotFoundas the mismatch error. It composes with the existingclient.IgnoreNotFoundcall sites, which is the reason I picked it, but that also means any caller already swallowing not-found will swallow this too. If you would rather it were a distinct typed error that cannot be ignored by accident, that is an easy change.TestInfra_ClaimSandbox,TestCloneSandbox_WithRateLimiterandTestCloneSandbox_TrafficAccessTokenfail for me on a clean master as well, and the failingTestInfra_ClaimSandboxsubtest changes between runs, so they look flaky rather than related.