Description
The roles and permissions matrix on /administration/managing_users/roles_in_kosli has three cells in the Snapshotter column that do not match observed behaviour. In two of them the matrix promises more than a snapshotter can actually do, and in one it promises less.
The underlying reason is that the Snapshotter role has a different effective permission set in the web app than it does over /api/v2, and the matrix presents a single combined column. Anyone automating with the CLI, Terraform or direct API calls will read the current table and expect API behaviour that they do not get.
Discrepancies
1. "Create and manage service accounts" is marked ✅, but only holds in the web app
A snapshotter can create, update and delete service accounts from the organization settings page. The equivalent /api/v2/service-accounts calls are rejected with 403.
2. "Generate service account API keys" is marked ✅, same split
Creating and rotating keys works from the settings page but not through the API.
3. "Update environments (PATCH, archive, rename, attach/detach policies)" is marked ❌, but policies can in fact be attached
Archive and rename are genuinely unavailable to a snapshotter. Attaching and detaching policies is not: PUT /api/v2/environments/{org} is a create-or-update and accepts policies, description and included_environments, so re-PUTting an existing environment changes those fields. The prose under the matrix already describes this, so the table currently contradicts the paragraph directly beneath it.
Also stale
The Snapshotter notes list scaling among the fields a re-PUT can change. Scaling is deprecated and no longer recorded, so it should be dropped from that sentence.
Suggested fix
- For the two service-account rows, either split the Snapshotter cell into web app and API, or add a footnote that snapshotter service-account management is web app only.
- Change the environment-update row so policy attach/detach is shown as available to a snapshotter via the environment create/update endpoint, and keep archive and rename as unavailable. That makes the table agree with the prose below it.
- Remove scaling from the list of fields a re-PUT can change.
- Consider a short note at the top of the matrix stating that some capabilities differ between the web app and the API, since this is not the only role where that could bite.
Verified as correct
The rest of the Snapshotter column checks out, including creating environments, reporting environment snapshots, all the view/query/export rows, and the ❌ marks on flows, attestations, attestation types, actions, policies, integrations and user or organization administration.
Description
The roles and permissions matrix on
/administration/managing_users/roles_in_koslihas three cells in the Snapshotter column that do not match observed behaviour. In two of them the matrix promises more than a snapshotter can actually do, and in one it promises less.The underlying reason is that the Snapshotter role has a different effective permission set in the web app than it does over
/api/v2, and the matrix presents a single combined column. Anyone automating with the CLI, Terraform or direct API calls will read the current table and expect API behaviour that they do not get.Discrepancies
1. "Create and manage service accounts" is marked ✅, but only holds in the web app
A snapshotter can create, update and delete service accounts from the organization settings page. The equivalent
/api/v2/service-accountscalls are rejected with 403.2. "Generate service account API keys" is marked ✅, same split
Creating and rotating keys works from the settings page but not through the API.
3. "Update environments (PATCH, archive, rename, attach/detach policies)" is marked ❌, but policies can in fact be attached
Archive and rename are genuinely unavailable to a snapshotter. Attaching and detaching policies is not:
PUT /api/v2/environments/{org}is a create-or-update and acceptspolicies,descriptionandincluded_environments, so re-PUTting an existing environment changes those fields. The prose under the matrix already describes this, so the table currently contradicts the paragraph directly beneath it.Also stale
The Snapshotter notes list scaling among the fields a re-PUT can change. Scaling is deprecated and no longer recorded, so it should be dropped from that sentence.
Suggested fix
Verified as correct
The rest of the Snapshotter column checks out, including creating environments, reporting environment snapshots, all the view/query/export rows, and the ❌ marks on flows, attestations, attestation types, actions, policies, integrations and user or organization administration.