Fleet versions
- Discovered: v4.84.0
- Reproduced: Not yet reproduced
Web browser and operating system: N/A
💥 Actual behavior
An API-only user with the gitops role receives 403 Forbidden when calling GET /api/latest/fleet/software/titles.
The endpoint handler ListSoftwareTitles in server/service/software_titles.go authorizes against AuthzSoftwareInventory with ActionRead:
if err := svc.authz.Authorize(ctx, &fleet.AuthzSoftwareInventory{
TeamID: opt.TeamID,
}, fleet.ActionRead); err != nil {
return nil, 0, nil, err
}
The rego policy in server/authz/policy.rego only grants read on software_inventory to admin, maintainer, technician, observer, and observer_plus. gitops is not in the list, so the request is denied.
🛠️ Expected behavior
The gitops role should be able to read software_inventory (list software titles).
The fix is to add gitops to the allowed roles for software_inventory read in server/authz/policy.rego, both at the global and team scope, and update the role-based access guide to reflect the new permission.
🧑💻 Steps to reproduce
These steps:
- Create an API-only user with the
gitops global role
- Generate an API token for that user via
fleetctl
- Call
GET /api/latest/fleet/software/titles with the GitOps token in the Authorization: Bearer <token> header.
- Observe a
403 Forbidden response instead of the expected list of software titles.
🕯️ More info (optional)
Cross-check against the role-based access guide confirms the documented behavior matches the policy: the "View all software" row in the user permissions table has no checkmark for GitOps. So the docs and code agree — but the design itself is the problem, since it leaves GitOps unable to reconcile software state.
Related authz code:
Fleet versions
Web browser and operating system: N/A
💥 Actual behavior
An API-only user with the
gitopsrole receives403 Forbiddenwhen callingGET /api/latest/fleet/software/titles.The endpoint handler
ListSoftwareTitlesinserver/service/software_titles.goauthorizes againstAuthzSoftwareInventorywithActionRead:The rego policy in
server/authz/policy.regoonly grantsreadonsoftware_inventorytoadmin,maintainer,technician,observer, andobserver_plus.gitopsis not in the list, so the request is denied.🛠️ Expected behavior
The
gitopsrole should be able to readsoftware_inventory(list software titles).The fix is to add
gitopsto the allowed roles forsoftware_inventoryread inserver/authz/policy.rego, both at the global and team scope, and update the role-based access guide to reflect the new permission.🧑💻 Steps to reproduce
These steps:
gitopsglobal rolefleetctlGET /api/latest/fleet/software/titleswith the GitOps token in theAuthorization: Bearer <token>header.403 Forbiddenresponse instead of the expected list of software titles.🕯️ More info (optional)
Cross-check against the role-based access guide confirms the documented behavior matches the policy: the "View all software" row in the user permissions table has no checkmark for GitOps. So the docs and code agree — but the design itself is the problem, since it leaves GitOps unable to reconcile software state.
Related authz code:
server/service/software_titles.go— endpoint handler with theAuthzSoftwareInventory+ActionReadcheckserver/authz/policy.rego—software_inventoryblock, lines under## Software