Repository navigation
fix: let resource readers read its status - #479
Merged
Merged
Conversation
Milo now authorizes subresource requests on their own permission, with no fallback to the parent resource's get. The compute roles never granted status.get, so anyone who could read a Workload, WorkloadDeployment, Instance, InstanceType, RuntimeClass, InstanceConsoleSession or AllowanceBucket was refused that object's status endpoint, even though a plain get already returns the same status. Key changes: - grant status.get next to every get in Compute Viewer and Instance Type Viewer, so admins and staff admins inherit it - leave status update and patch controller-only - leave the workloaddeployments scale subresource ungranted
scotwells
marked this pull request as ready for review
October 15, 2026 18:57
ecv
approved these changes
Oct 15, 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
2 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.
People who can view compute resources are refused their status, because the platform now checks a separate permission for status reads and no compute role grants it. The portal and CLI show permission errors where they should show workload, instance and catalog health. This grants status read to every role that can already read the resource, so viewing a resource includes viewing its status again. Status writes and scaling stay out of reach for users.
Changes
status.getfor workloads, workload deployments, instances, runtime classes, instance types, console sessions and quota allowance buckets, each placed directly after the matchingget.instancetypes/status.get.updateandpatchstay controller-only. Theworkloaddeployments/scalesubresource is deliberately not granted; that is a separate product decision.User-facing effect
A project member with Compute Viewer now gets the object back instead of a 403:
Before:
PUTorPATCHon the same/statuspath is still denied.Test plan
go test ./test/iam/...passes, including the guard that roles grant no subresource writeskustomize build config/components/iamrendersGETa workload's and an instance's/statusPATCHby the same user is still denied