From 1d368ad7050996805dd0cd04f9270591195cbcf1 Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Sat, 7 Nov 2026 10:13:15 +0000 Subject: [PATCH] fix: apply review follow-ups for service accounts, tags and audit log pages --- .../authentication/service_accounts.md | 13 +++++++++++-- administration/managing_tags.md | 18 ++++++++++++++---- .../managing_users/roles_in_kosli.md | 5 +++-- 3 files changed, 28 insertions(+), 8 deletions(-) diff --git a/administration/authentication/service_accounts.md b/administration/authentication/service_accounts.md index f6ec26c..b53c3fd 100644 --- a/administration/authentication/service_accounts.md +++ b/administration/authentication/service_accounts.md @@ -57,7 +57,7 @@ API keys are created separately. The key value is shown only once, so store it i kosli create api-key \ --service-account ci-github-actions \ --description "key for CI" \ - --expires-at 2027-06-30 + --expires-at ``` To inspect, change, or remove service accounts: @@ -69,9 +69,18 @@ kosli update service-account ci-github-actions --privilege reader kosli delete service-account ci-github-actions --assume-yes ``` +To list a service account's API keys, or revoke one: + +```shell +kosli list api-keys --service-account ci-github-actions +kosli delete api-key --service-account ci-github-actions --assume-yes +``` + +`kosli list api-keys` shows each active key's metadata, including its ID, but never the key value. `kosli delete api-key` revokes the key immediately and also deletes every key that was created with it. + `kosli update service-account` changes only the flags you pass. `kosli delete service-account` permanently deletes the service account and its API keys. It asks for confirmation, so pass `--assume-yes` in CI or other non-interactive shells. -See the reference pages for all flags: [`kosli create service-account`](/client_reference/kosli_create_service-account), [`kosli list service-accounts`](/client_reference/kosli_list_service-accounts), [`kosli get service-account`](/client_reference/kosli_get_service-account), [`kosli update service-account`](/client_reference/kosli_update_service-account), [`kosli delete service-account`](/client_reference/kosli_delete_service-account), and [`kosli create api-key`](/client_reference/kosli_create_api-key). +See the reference pages for all flags: [`kosli create service-account`](/client_reference/kosli_create_service-account), [`kosli list service-accounts`](/client_reference/kosli_list_service-accounts), [`kosli get service-account`](/client_reference/kosli_get_service-account), [`kosli update service-account`](/client_reference/kosli_update_service-account), [`kosli delete service-account`](/client_reference/kosli_delete_service-account), [`kosli create api-key`](/client_reference/kosli_create_api-key), [`kosli list api-keys`](/client_reference/kosli_list_api-keys), and [`kosli delete api-key`](/client_reference/kosli_delete_api-key). ## Manage service accounts with Terraform diff --git a/administration/managing_tags.md b/administration/managing_tags.md index 1b4ba8d..1a8120a 100644 --- a/administration/managing_tags.md +++ b/administration/managing_tags.md @@ -3,11 +3,11 @@ title: Managing tags description: Use tags to label and organize Kosli resources with custom key-value pairs via Terraform, CLI, or API. --- -Tags are custom key-value pairs you attach to Kosli resources. They let you categorize, filter, and add metadata to your flows and environments without changing the resources themselves. +Tags are custom key-value pairs you attach to Kosli resources. They let you categorize, filter, and add metadata to your flows, environments, controls, and repositories without changing the resources themselves. ## Why use tags -- **Organize resources** — group related flows or environments by team, project, region, or any other dimension. +- **Organize resources** — group related resources by team, project, region, or any other dimension. - **Drive policy behavior** — reference tags in [Environment Policy](/getting_started/policies) expressions to make attestation requirements conditional. For example, require security scans only for flows tagged `risk-level=high`. - **Add operational metadata** — store context such as cost center, service tier, or owner directly on the resource. @@ -19,6 +19,7 @@ You can tag the following Kosli resource types: | :--- | :--- | :--- | | Flow | [`kosli_flow`](/terraform-reference/resources/flow) | `flow` | | Environment | [`kosli_environment`](/terraform-reference/resources/environment) | `env` | +| [Control](/tutorials/working_with_controls) (beta) | [`kosli_control`](/terraform-reference/resources/control) | `control` | | [Repository](/tutorials/repositories) | Not supported | `repo` | ## Tag key and value rules @@ -31,7 +32,7 @@ You can tag the following Kosli resource types: - Add a `tags` map to any `kosli_environment` or `kosli_flow` resource. Tags are applied via a diff — only changed tags are sent to the API. + Add a `tags` map to any `kosli_environment`, `kosli_flow`, or `kosli_control` resource. Tags are applied via a diff — only changed tags are sent to the API. Tag an environment: @@ -175,8 +176,17 @@ You can tag the following Kosli resource types: } ``` + + `kosli get` prints a resource's tags in its `Tags` field: + + ```shell + kosli get repo my-org/my-repo + ``` + + `kosli get flow`, `kosli get env`, and `kosli get control` show tags the same way. [`kosli list repos`](/client_reference/kosli_list_repos) has a `TAGS` column. + - Tags are included in the resource response when you fetch an environment or flow via the API. + Tags are included in the resource response when you fetch a flow, environment, control, or repository via the API. diff --git a/administration/managing_users/roles_in_kosli.md b/administration/managing_users/roles_in_kosli.md index 93a071f..5c58378 100644 --- a/administration/managing_users/roles_in_kosli.md +++ b/administration/managing_users/roles_in_kosli.md @@ -219,7 +219,7 @@ To assign or change a user's role: 1. Log in to Kosli as an Admin 2. Navigate to your organization from the left navigation menu -3. Go to `Settings` > `Members` +3. Go to `Settings` > `User Management` 4. Find the user you want to modify 5. Select their new role from the dropdown menu @@ -241,7 +241,7 @@ For CI/CD pipelines and automated systems, create service accounts with the Memb ### Regular access reviews -Periodically review user roles and remove access for team members who no longer need it. This is especially important when people change roles or leave the organization. +Periodically review user roles and remove access for team members who no longer need it. This is especially important when people change roles or leave the organization. To see who changed membership or roles, and when, use the [Audit Log](/administration/managing_users/membership_audit_log). ### Separate concerns @@ -256,3 +256,4 @@ Periodically review user roles and remove access for team members who no longer - [Mapping users to roles](/administration/managing_users/mapping_users_to_roles) — recommended Kosli roles for common organizational roles. - [Service accounts](/administration/authentication/service_accounts) — assigning roles to machine users. +- [Review membership changes](/administration/managing_users/membership_audit_log): who was added, removed, or given a different role, and who made each change.