From a8f87101b96fdd969da18b45486f4fbf67427b5e Mon Sep 17 00:00:00 2001 From: Sami Alajrami Date: Wed, 14 Oct 2026 15:08:07 +0200 Subject: [PATCH] Say that a snapshotter can tag environments The server now lets a snapshotter API key set and remove tags on an environment (kosli-dev/server#7416), so the role pages said less than the role can do. The permissions matrix splits tagging into a row for environments, open to snapshotters, and one for flows, repos and controls, which stays with members and above. The Snapshotter section, the overview table, the API footnote and the two one-line role summaries say the same. Co-Authored-By: Claude Fable 5.1 --- administration/authentication/service_accounts.md | 2 +- administration/managing_users/roles_in_kosli.md | 12 +++++++----- .../phase_1/roles_and_responsibilities/overview.md | 2 +- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/administration/authentication/service_accounts.md b/administration/authentication/service_accounts.md index 9ea4890f..cb5632d6 100644 --- a/administration/authentication/service_accounts.md +++ b/administration/authentication/service_accounts.md @@ -35,7 +35,7 @@ Service accounts have the same role model as users: **Admin**, **Member**, **Sna See [Roles in Kosli](/administration/managing_users/roles_in_kosli) for the full permissions matrix. As a starting point: - **Member** — CI/CD systems that report attestations, manage flows, and create resources. -- **Snapshotter** — runtime reporters that record environment snapshots and create environments (for example, CLI callers using `--auto-environment`). +- **Snapshotter** — runtime reporters that record environment snapshots and create and tag environments (for example, CLI callers using `--auto-environment`). - **Reader** — read-only systems such as dashboards or query tooling. - **Admin** — rarely needed; reserve for automation that manages users, roles, or organization-wide settings (for example, Terraform-driven org bootstrap). diff --git a/administration/managing_users/roles_in_kosli.md b/administration/managing_users/roles_in_kosli.md index f53e9289..4dd50899 100644 --- a/administration/managing_users/roles_in_kosli.md +++ b/administration/managing_users/roles_in_kosli.md @@ -14,7 +14,7 @@ Roles apply to service accounts the same way they apply to users. Wherever this |------|-------------|----------| | **Admin** | Full control over the organization | Organization owners, security leads, platform engineering leads | | **Member** | Can create and modify resources | Developers, platform engineers, CI/CD systems | -| **Snapshotter** | Can report snapshots and create environments, and create service accounts in the web UI | Environment and operations teams | +| **Snapshotter** | Can report snapshots, create and tag environments, and create service accounts in the web UI | Environment and operations teams | | **Reader** | Read-only access to view data | Auditors, compliance officers, stakeholders, reporting systems | ## Permissions Matrix @@ -46,7 +46,8 @@ Roles apply to service accounts the same way they apply to users. Wherever this | Update attestation types | ✅ | ✅ | ❌ | ❌ | | Archive attestation types | ✅ | Own only\* | ❌ | ❌ | | Manage repos | ✅ | ✅ | ❌ | ❌ | -| Tag flows, environments, repos, and controls | ✅ | ✅ | ❌ | ❌ | +| Tag environments | ✅ | ✅ | ✅ | ❌ | +| Tag flows, repos, and controls | ✅ | ✅ | ❌ | ❌ | | Add to and revoke from the allowlist | ✅ | ✅ | ❌ | ❌ | | **Attestations & Snapshots** | | | | | Report attestations | ✅ | ✅ | ❌ | ❌ | @@ -67,7 +68,7 @@ Roles apply to service accounts the same way they apply to users. Wherever this \* Admins can act on any service account or attestation type. Other roles can act only on the ones they created themselves. -† Snapshotters can create and manage service accounts in the web UI only. The API allows a snapshotter no writes beyond reporting environment snapshots and creating environments. +† Snapshotters can create and manage service accounts in the web UI only. The API allows a snapshotter no writes beyond reporting environment snapshots, creating environments and tagging them. ‡ Creating an environment that already exists succeeds as long as the request would not change it, so CI pipelines that create the same environment at the same time don't fail. A request that would change an existing environment needs the Member or Admin role. @@ -143,7 +144,7 @@ The following sections provide more details about each Kosli user role, includin - Snapshotters can create environments, report environment snapshots, and create service accounts in the web UI, but cannot modify other resources, manage users, configure integrations, or change organization-wide settings. + Snapshotters can create and tag environments, report environment snapshots, and create service accounts in the web UI, but cannot modify other resources, manage users, configure integrations, or change organization-wide settings. ### Permissions @@ -151,6 +152,7 @@ The following sections provide more details about each Kosli user role, includin - **Service Accounts**: In the web UI only, create service accounts and manage the ones they created and those accounts' API keys. The API does not allow a snapshotter to do this. - **Environments**: Create new environments (needed so CLI flows like `--auto-environment` work with a snapshotter token). Creating an environment that already exists succeeds as long as the request would not change it. + - **Tags**: Set and remove tags on environments (`kosli tag environment`). - **Snapshots**: Report environment snapshots. - **View Data**: Access trails, artifacts, attestations, and snapshots. - **Query Information**: Search and filter data across flows and environments. @@ -158,7 +160,7 @@ The following sections provide more details about each Kosli user role, includin - **View Configurations**: See flow definitions, policies, attestation types, and actions (but cannot modify them). Snapshotters cannot: - - Change an existing environment, whether through the update endpoints or by re-creating it with different settings. + - Change an existing environment other than its tags, whether through the update endpoints or by re-creating it with different settings. - Archive environments. - Create, update, or delete flows, policies, attestation types, or other resources. - Report attestations. diff --git a/implementation_guide/phase_1/roles_and_responsibilities/overview.md b/implementation_guide/phase_1/roles_and_responsibilities/overview.md index cc30634d..fd96fc4e 100644 --- a/implementation_guide/phase_1/roles_and_responsibilities/overview.md +++ b/implementation_guide/phase_1/roles_and_responsibilities/overview.md @@ -73,7 +73,7 @@ The RACI matrix above describes responsibilities during Kosli implementation. To Kosli user roles control what actions someone can perform in the Kosli system: - **Admin**: Full control, including user management and organization settings - **Member**: Can create and modify resources, manage service accounts, and configure integrations -- **Snapshotter**: Can report environment snapshots, create environments, and manage service accounts, with read-only access to other resources +- **Snapshotter**: Can report environment snapshots, create and tag environments, and manage service accounts, with read-only access to other resources - **Reader**: Read-only access to view data and compliance status For guidance on which Kosli user role to assign based on organizational responsibilities, see [Roles in Kosli](/administration/managing_users/roles_in_kosli) and [Mapping users to roles](/administration/managing_users/mapping_users_to_roles).