Repository navigation
fix: let resource readers read its status - #206
Merged
Merged
Conversation
Milo now authorizes subresources on their own, with no fallback to the parent verb. A request for a resource's /status endpoint needs an explicit status.get grant, and no role granted one, so anyone who can read a resource is denied its status even though a normal get already returns the same data. Grant status.get on ExportPolicies to the telemetry viewer role, next to the existing get grant. The admin role inherits it. Status update and patch stay controller-only.
scotwells
marked this pull request as ready for review
October 15, 2026 18:57
ecv
approved these changes
Oct 15, 2026
mattdjenkinson
approved these changes
Oct 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since Milo began enforcing subresource permissions in staging and production, people who can view export policies are refused when they ask for an export policy's status, even though the normal read already shows that status. Portals and command-line tools that read status this way fail with a permission error. After this change anyone who can read export policies can also read their status. Status writes stay with the controllers.
Changes
status.geton ExportPolicies, next to the existingget. The admin role inherits it.Status update and patch are not granted to any role, so only the controllers can change status.
User-facing effect
Before, for a member holding the viewer role:
After, the same request returns the object with its status, matching a plain
kubectl get.Test plan
go test ./queryapi/passes, including the check that the viewer grants only declared permissionskustomize build config/operator/iamrenders the new grant