fix: use fleetMembers actions for v2 fleet scope authorization checks #433
Conversation
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
PR kubeguard#432 fixed the namespace scope order for fleet member clusters but still used the original cluster type actions (e.g., managedClusters) when checking fleet scope authorization in the v2 API path. This fix ensures that when falling back to fleet scope checks, the v2 implementation generates fleet-specific actions using the fleetMembers cluster type, consistent with how v1 handles this scenario. For example, when a managedCluster fleet member needs to check fleet authorization, the action should be: Microsoft.ContainerService/fleets/members/pods/read instead of: Microsoft.ContainerService/managedClusters/pods/read This enables roles like "Azure Kubernetes Fleet Manager RBAC Cluster Admin for Member Clusters" to properly authorize requests to fleet member clusters through the v2 API. Also adds a test to verify the correct actions are used for each authorization check in the fallback chain. Signed-off-by: Artem Kolomeetc <akolomeetc@microsoft.com>
jwtty
reviewed
Jan 5, 2026
Signed-off-by: Artem Kolomeetc <akolomeetc@microsoft.com>
jwtty
approved these changes
Jan 5, 2026
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.
Summary
This PR fixes the remaining issue by ensuring that when falling back to fleet scope checks, the v2 implementation generates fleet-specific actions using the
fleetMemberscluster type, consistent with how v1 handles this scenario.The Problem
In the v2
checkAccessV2function, actions were computed once at the beginning usinga.clusterType:These same
actionswere then reused for fleet scope checks, which is incorrect. For a fleet member cluster withclusterType = managedClusters, this would send:Microsoft.ContainerService/managedClusters/pods/readInstead of the correct fleet member action:
Microsoft.ContainerService/fleets/members/pods/readThe Fix
Generate fleet-specific actions using
fleetMemberscluster type before performing fleet scope checks:This ensures roles like "Azure Kubernetes Fleet Manager RBAC Cluster Admin for Member Clusters" can properly authorize requests through the v2 API.
Changes
fleetMembersactions for fleet scope and fleet managed namespace checks in v2TestCheckAccessV2_FleetActionsUseCorrectClusterTypeto verify correct actions are used