Skip to content

docs: add Kosli Capture Managed Service page #380

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mintlify wants to merge 7 commits into from
Closed

docs: add Kosli Capture Managed Service page #380

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
193060c
feat: add Kosli Capture Managed Service page to Getting started
mintlify[bot] Sep 2, 2026
0d7fb53
Add more Kosli Capture IAM details
gsavage Sep 7, 2026
7afa53c
Update Capture docs to reflect recent decisions
gsavage Sep 14, 2026
b6dd574
Remove S3 from the Cloudformation Template
gsavage Sep 14, 2026
6e1d5c5
docs: move Kosli Capture pages into their own folder
gsavage Sep 14, 2026
0a1e3f9
Update Kosli Capture based on latest meeting
gsavage Sep 15, 2026
ce043e6
docs: add Kosli Capture getting started guide to navigation
gsavage Sep 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions administration/kosli_capture/getting_started.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
---
title: "Getting Started with Kosli Capture"
sidebarTitle: "Getting started"
description: "Learn how to configure Kosli Capture for your organization"
tag: "ALPHA"
---

<Warning>
Kosli Capture is still in active development. Its capabilities and configuration format may change, and onboarding is done together with Kosli's Customer Success team.
</Warning>

Kosli Capture is a managed service that runs on Kosli's infrastructure and connects to your cloud platform to observe the resources deployed there. To get set up with Kosli Capture you need to grant permissions to Kosli's cloud account and provide configuration details for how your tags should map to environments within Kosli.

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical — the first paragraph tells the reader to prepare something the page never asks for.

"provide configuration details for how your tags should map to environments within Kosli" is contradicted three ways at this branch head:

  • overview.md:20 says you configure Kosli Capture "by activating it for different AWS services", and that it "uses details about your infrastructure, such as the name of an ECS cluster, to build environments" — names, not a tag map.
  • This page's own two stages are an IAM role and a UI toggle (lines 27–39). There is no configuration stage.
  • The only reader-controlled tag left is the kosli.capture=false exclusion tag at line 43 — filtering, not mapping.

This is the tag-mapping configuration document that 0a1e3f9 removed; the intro was not updated with it. Being the opening sentence of the only how-to page in the group, it is the sentence most likely to be acted on.

Suggested change
Kosli Capture is a managed service that runs on Kosli's infrastructure and connects to your cloud platform to observe the resources deployed there. To get set up with Kosli Capture you need to grant permissions to Kosli's cloud account and provide configuration details for how your tags should map to environments within Kosli.
Kosli Capture is a managed service that runs on Kosli's infrastructure and connects to your cloud platform to observe the resources deployed there. To get set up with Kosli Capture you need to grant permissions to Kosli's cloud account, then enable Kosli Capture for your organization in the Kosli UI.


## Overview

Getting started with Kosli Capture involves two stages:

<Steps>
<Step title="Prepare your environment">
Create an IAM role in your AWS account specifically for Kosli Capture. Kosli provides a CloudFormation template to simplify this process. The template requires a shared secret, which Kosli provides to you.
</Step>
<Step title="Enable Kosli Capture">
Enable Kosli Capture for your Kosli org, and the regular snapshots appear in Kosli.
</Step>
</Steps>

## Prepare your environment

In order for Kosli Capture to reach into your cloud, to discover your ECS clusters and Lambdas, you need to grant permission to Kosli to do so. Within AWS this requires the creation of an IAM role that Kosli can assume; the role will exist within your AWS account.

To simplify this process, Kosli has created a CloudFormation template that contains a role with the minimum set of permissions needed by Kosli Capture. The role can be assumed by Kosli and is protected by an external Id; each organization within Kosli has its own external Id.

The CloudFormation template can be deployed within an AWS account, or can be attached to an AWS Organizational Unit (OU) as a StackSet; this latter option ensures the correct IAM permissions are rolled out to all AWS accounts within the OU.

When used, the CloudFormation template will send your AWS account id to Kosli, so that we are automatically notified that your account is ready to be included in Kosli Capture. Similarly, if you delete the CloudFormation stack we will be notified and know that the account is no longer to be included.

## Enable Kosli Capture

When you have created the IAM role, using the CloudFormation template, you can activate Kosli Capture within the Kosli user-interface. Kosli Capture runs on a five-minute schedule, and once you have enabled it, Kosli Capture will pick up your environment the next time it runs - you should see environments and snapshots appearing within a few minutes.

## Excluding resources

If there are resources you do not wish to include within a Kosli Capture Managed snapshot, for example an ECS cluster that you consider to be out of scope, you can add an AWS tag to it indicating that the item should be skipped. Adding a tag with the name `kosli.capture` and the value `false` will ensure that Kosli Capture skips over that resource.
54 changes: 54 additions & 0 deletions administration/kosli_capture/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
---
title: "Kosli Capture Managed Service"
sidebarTitle: "Kosli Capture"
description: "Learn how the Kosli Capture Managed Service snapshots your cloud environments from Kosli's infrastructure, with no software to install."
tag: "ALPHA"
---
Comment thread
gsavage marked this conversation as resolved.

<Warning>
Kosli Capture is still in active development. Its capabilities and configuration format may change, and onboarding is done together with Kosli's Customer Success team.
</Warning>

Kosli Capture is a managed service that runs on Kosli's infrastructure and connects to your cloud platform to observe the resources deployed there. You grant Kosli Capture a set of permissions, and it uses them to run a `kosli snapshot` every few minutes against the infrastructure you have allowed it to scan.

Kosli also supports reporting from your own cloud accounts by running the Kosli CLI on a schedule. Kosli Capture inverts this, with Kosli running the regular [snapshots](/getting_started/environments) so there is no software for you to install.

Comment thread
gsavage marked this conversation as resolved.
To set it up for your organization, see [Getting started with Kosli Capture](/administration/kosli_capture/getting_started).

## Overview

Kosli Capture connects to your cloud accounts using permissions that you manage. You configure Kosli Capture by activating it for different AWS services, and Kosli Capture uses the permissions to regularly reach into your estate and record snapshots, sending the data into your Kosli organization. Kosli Capture uses details about your infrastructure, such as the name of an ECS cluster, to build environments within Kosli.

## Security

The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. Kosli Capture runs as a shared, autoscaled service, but each job runs under a role that is scoped to one customer
Comment on lines +22 to +24

@claude claude Bot Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion — this section duplicates the dedicated security page without linking to it.

administration/kosli_capture_security.md is the sibling page in the new nav group, and its whole subject is this. The only link between the two pages is buried at line 69 under "IAM permissions" (and is relative — see the other comment). A reader who stops at this section never learns the deeper page exists.

A single forward pointer at the end of this section, e.g. "For the IAM role, trust policy and full permission list, see Kosli Capture security." — the security page has no link back to the overview either, so the pair is currently only navigable via the sidebar.


* A Kosli Capture worker picks up a job for your organization and assumes a Kosli-side role that exists only for your organization. Only that role is permitted to call AssumeRole into A's account with A's ExternalId.
* When the job finishes, those credentials are discarded. A worker holding credentials for your cloud account has no path to anyone else's account.
* The trust policy's ExternalId lives in Parameter Store and is readable only by the Kosli-side role for your organization. The shared task role cannot read any customer's ExternalId. Separation is enforced by IAM, not by application code.

Kosli Catpure itself does not hold any customer data. Snapshots taken by Kosli Catpure are immediately sent to Kosli through the same ingest path as your existing pipelines.
Comment on lines +24 to +30

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — this section still refers to an unnamed "customer A". Line 24 reads "Only that role is permitted to call AssumeRole into A's account with A's ExternalId." Nothing on the page defines "A" — it reads as a leftover from an internal design document where customers were labelled A and B. This is the section a reader is most likely to forward to their own security team, and it contains an unresolvable referent in its first bullet.

Three more defects in the same block:

  • Line 22 has no closing full stop ("...scoped to one customer").
  • Line 28 spells the product "Kosli Catpure" twice. Worth flagging because vale-spellcheck cannot catch it: .vale.ini sets BasedOnStyles = Kosli and styles/Kosli/ contains only AmericanSpelling.yml, so there is no general dictionary on this repo.
  • The page uses "ExternalId" here and "external ID" at lines 50–52; security.md:41 uses the YAML key sts:ExternalId. Reserve the camel-case form for the literal key and use "external ID" in prose.
Suggested change
The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. Kosli Capture runs as a shared, autoscaled service, but each job runs under a role that is scoped to one customer
* A Kosli Capture worker picks up a job for your organization and assumes a Kosli-side role that exists only for your organization. Only that role is permitted to call AssumeRole into A's account with A's ExternalId.
* When the job finishes, those credentials are discarded. A worker holding credentials for your cloud account has no path to anyone else's account.
* The trust policy's ExternalId lives in Parameter Store and is readable only by the Kosli-side role for your organization. The shared task role cannot read any customer's ExternalId. Separation is enforced by IAM, not by application code.
Kosli Catpure itself does not hold any customer data. Snapshots taken by Kosli Catpure are immediately sent to Kosli through the same ingest path as your existing pipelines.
The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. Kosli Capture runs as a shared, autoscaled service, but each job runs under a role that is scoped to a single customer.
* A Kosli Capture worker picks up a job for your organization and assumes a Kosli-side role that exists only for your organization. Only that role is permitted to call `AssumeRole` into your account, with your external ID.
* When the job finishes, those credentials are discarded. A worker holding credentials for your cloud account has no path to any other account.
* The trust policy's external ID lives in Parameter Store and is readable only by the Kosli-side role for your organization. The shared task role cannot read any customer's external ID. Separation is enforced by IAM, not by application code.
Kosli Capture itself does not hold any customer data. Snapshots taken by Kosli Capture are immediately sent to Kosli through the same ingest path as your existing pipelines.

Comment on lines +24 to +30

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — this section still refers to an unnamed "customer A".

Line 26 reads "Only that role is permitted to call AssumeRole into A's account with A's ExternalId". Nothing on the page defines "A" — it reads as a leftover from an internal design document where customers were labelled A and B. This is the section a reader is most likely to forward to their own security team, and the referent is unresolvable in its first bullet.

Also in this block: line 24 has no closing full stop, line 30 spells the product "Kosli Catpure" twice, and the page uses "ExternalId" here but "external ID" at lines 52–54 — worth reserving the camel-case form for the literal YAML key shown at security.md:41.

Suggested change
The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. Kosli Capture runs as a shared, autoscaled service, but each job runs under a role that is scoped to one customer
* A Kosli Capture worker picks up a job for your organization and assumes a Kosli-side role that exists only for your organization. Only that role is permitted to call AssumeRole into A's account with A's ExternalId.
* When the job finishes, those credentials are discarded. A worker holding credentials for your cloud account has no path to anyone else's account.
* The trust policy's ExternalId lives in Parameter Store and is readable only by the Kosli-side role for your organization. The shared task role cannot read any customer's ExternalId. Separation is enforced by IAM, not by application code.
Kosli Catpure itself does not hold any customer data. Snapshots taken by Kosli Catpure are immediately sent to Kosli through the same ingest path as your existing pipelines.
The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. Kosli Capture runs as a shared, autoscaled service, but each job runs under a role that is scoped to a single customer.
* A Kosli Capture worker picks up a job for your organization and assumes a Kosli-side role that exists only for your organization. Only that role is permitted to call `AssumeRole` into your account, with your external ID.
* When the job finishes, those credentials are discarded. A worker holding credentials for your cloud account has no path to anyone else's account.
* The trust policy's external ID lives in Parameter Store and is readable only by the Kosli-side role for your organization. The shared task role cannot read any customer's external ID. Separation is enforced by IAM, not by application code.
Kosli Capture itself does not hold any customer data. Snapshots taken by Kosli Capture are immediately sent to Kosli through the same ingest path as your existing pipelines.


## Hands-off operation

Kosli Capture has been designed to operate with no on-going support from you. Once the initial security permissions have been created, Kosli capture will continue to operate in a headless mode. Monitoring, maintenance and rotation of API keys is all handed automatically. As your cloud infrastructure changes over time, Kosli capture will continue to find resources without you needing to do anything; your application teams do not need to take any action in order to onboard their products and services into Kosli.

## Finding resources

Kosli Capture finds all supported resources within your AWS accounts, and determines which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.

Kosli Capture can [filter out resources based on AWS tags](/administration/kosli_capture/getting_started#excluding-resources).

As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required.

@claude claude Bot Sep 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — environment auto-creation is now stated twice. Line 38 ends with "Kosli Capture will create physical environments for you", and this sentence repeats it four lines later ("Because Kosli Capture creates physical environments as needed..."). The claim only needs to land once; here the useful new information is that evolving infrastructure is handled without reconfiguration.

Suggested change
As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required.
As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required.

If you take this, drop the trailing sentence on line 38 ("Kosli Capture will create physical environments for you.") so the claim appears once, in the paragraph that explains why it matters.

Comment on lines +38 to +42

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — "all supported resources" is undefined, and line 42 still points at a configuration that no longer exists.

Two stale references from the same removals:

  1. Supported resource types. 7afa53c dropped the Current status section, which was the only statement of what Kosli Capture can snapshot. Line 38 now says "all supported resources" without defining the set; line 42 uses ECS and Lambda only as incidental examples. The authoritative signal is the IAM policy on security.md (ECS + Lambda; S3 removed in b6dd574) and a passing mention at getting_started.md:29. A reader evaluating the service on the page meant for evaluating it cannot tell what it covers.
  2. "No changes to the configuration created during the initial setup are required." 0a1e3f9 removed the user-authored configuration document. Initial setup is now an IAM role plus a UI toggle — there is no configuration to leave unchanged. The sentence before it is also circular: it gives "Kosli Capture creates physical environments as needed" as the reason Kosli keeps up, having already asserted the same thing on line 38.
Suggested change
Kosli Capture finds all supported resources within your AWS accounts, and determines which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
Kosli Capture can [filter out resources based on AWS tags](/administration/kosli_capture/getting_started#excluding-resources).
As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required.
Kosli Capture currently snapshots ECS clusters and Lambda functions. It finds these resources within your AWS accounts and determines which Kosli environment should hold the snapshots.
Kosli Capture can [filter out resources based on AWS tags](/administration/kosli_capture/getting_started#excluding-resources).
As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. You do not need to change anything you set up when you enabled it.


## Multiple AWS accounts

Kosli Capture can operate across multiple AWS regions and accounts, allowing you to snapshot development, QA, pre-production, and production workloads with the same process.

## IAM permissions

For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](/administration/kosli_capture/security) page provides a deep-diver into the structure of the permissions needed.

The IAM role created in your environment includes a trust policy that allows Kosli Capture to assume the role. The trust policy limits access to the AWS account in which Kosli Capture is running. Furthermore, the trust policy includes an external ID that acts as a shared secret between Kosli and you, so that only access from Kosli Capture is permitted.

The external ID (shared secret) is securely stored with Kosli Capture. Kosli's internal IAM permissions ensure that the secret can only be accessed by the specific instance of Kosli Capture worker that is operating for you.
Comment on lines +48 to +54

@claude claude Bot Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — with the pages now split, this section and ## Security above duplicate the dedicated security page.

6e1d5c5 gave Kosli Capture its own folder with security.md as a sibling, but the overview still carries two sections on the same subject: ## Security (lines 25–33, the worker/role isolation model) and ## IAM permissions (this section, the trust policy and external ID). security.md covers the trust policy in full, including the actual AssumeRolePolicyDocument, so lines 71–73 are a prose restatement of a YAML block one click away — and the two will drift.

Worth deciding what each page owns. A reasonable split: the overview says what access is needed and why it is safe in two or three sentences, and the security page owns the mechanism. Right now the only link between them is buried at the end of line 69, and security.md has no link back — the pair is navigable only via the sidebar.

Two things on line 69 itself: "deep-diver" should be "deep dive", and there is a double space before "The".

Suggested change
## IAM permissions
For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](/administration/kosli_capture/security) page provides a deep-diver into the structure of the permissions needed.
The IAM role created in your environment includes a trust policy that allows Kosli Capture to assume the role. The trust policy limits access to the AWS account in which Kosli Capture is running. Furthermore, the trust policy includes an external ID that acts as a shared secret between Kosli and you, so that only access from Kosli Capture is permitted.
The external ID (shared secret) is securely stored with Kosli Capture. Kosli's internal IAM permissions ensure that the secret can only be accessed by the specific instance of Kosli Capture worker that is operating for you.
For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these, and they are typically "Describe" or "List" permissions.
The IAM role you create includes a trust policy that allows only Kosli Capture to assume it, using an external ID that acts as a shared secret between you and Kosli. The [Kosli Capture security](/administration/kosli_capture/security) page is a deep dive into the role, the trust policy, and the full permission list.

Comment on lines +48 to +54

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion — now that the pages are split, decide which one owns the trust policy. 6e1d5c5 gave Kosli Capture its own folder with security.md as a sibling, but this overview still carries two sections on the same subject: ## Security (lines 20–28, the worker/role isolation model) and this one. Lines 50–52 are a prose restatement of the AssumeRolePolicyDocument block that security.md:22–42 shows in full — the two will drift, and the external-ID storage claim is already worded differently in each.

A reasonable split: the overview says in two sentences what access is needed and why it is safe, and security.md owns the mechanism. Note also that security.md has no link back here, so the pair is navigable only via the sidebar.

Two things on line 48 itself: "deep-diver" should be "deep dive", and there is a double space before "The".

Suggested change
## IAM permissions
For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](/administration/kosli_capture/security) page provides a deep-diver into the structure of the permissions needed.
The IAM role created in your environment includes a trust policy that allows Kosli Capture to assume the role. The trust policy limits access to the AWS account in which Kosli Capture is running. Furthermore, the trust policy includes an external ID that acts as a shared secret between Kosli and you, so that only access from Kosli Capture is permitted.
The external ID (shared secret) is securely stored with Kosli Capture. Kosli's internal IAM permissions ensure that the secret can only be accessed by the specific instance of Kosli Capture worker that is operating for you.
## IAM permissions
For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these, and they are typically "Describe" or "List" permissions.
The IAM role you create includes a trust policy that allows only Kosli Capture to assume it, using an external ID that acts as a shared secret between you and Kosli. The [Kosli Capture security](/administration/kosli_capture/security) page is a deep dive into the role, the trust policy, and the full permission list.

Comment on lines +48 to +54

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — now that the pages are split, decide which one owns the trust policy.

6e1d5c5 gave Kosli Capture its own folder with security.md as a sibling, but this overview still carries two sections on the same subject: ## Security (lines 22–30, the worker/role isolation model) and this one. Lines 52–54 are a prose restatement of the AssumeRolePolicyDocument that security.md:22–42 shows in full, and the external-ID storage claim is already worded differently in the two places — they will drift.

A workable split: the overview says in two sentences what access is needed and why it is safe, and security.md owns the mechanism. Note security.md has no link back here either, so the pair is navigable only via the sidebar.

Line 50 also has "deep-diver" for "deep dive", and a double space before "The".

Suggested change
## IAM permissions
For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](/administration/kosli_capture/security) page provides a deep-diver into the structure of the permissions needed.
The IAM role created in your environment includes a trust policy that allows Kosli Capture to assume the role. The trust policy limits access to the AWS account in which Kosli Capture is running. Furthermore, the trust policy includes an external ID that acts as a shared secret between Kosli and you, so that only access from Kosli Capture is permitted.
The external ID (shared secret) is securely stored with Kosli Capture. Kosli's internal IAM permissions ensure that the secret can only be accessed by the specific instance of Kosli Capture worker that is operating for you.
## IAM permissions
For Kosli Capture to snapshot your environment, you must grant a set of read-only permissions. Kosli's CloudFormation template lists these, and they are typically "Describe" or "List" permissions.
The IAM role you create includes a trust policy that allows only Kosli Capture to assume it, using an external ID that acts as a shared secret between you and Kosli. The [Kosli Capture security](/administration/kosli_capture/security) page is a deep dive into the role, the trust policy, and the full permission list.

102 changes: 102 additions & 0 deletions administration/kosli_capture/security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
---
title: Kosli Capture - Security
sidebarTitle: Security
description: "Learn about the security of Kosli Capture"
tag: "ALPHA"
---

<Warning>
Kosli Capture is still in active development. Its capabilities and configuration format may change, and onboarding is done together with Kosli's Customer Success team.
</Warning>

## Kosli capture permissions

The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.

@claude claude Bot Sep 7, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — GCP and Azure are claimed here but nowhere else, and "supported resources" is now undefined.

This sentence says Kosli Capture "uses the public AWS, GCP and Azure APIs", but the rest of this page is AWS-only (IAM role, CloudFormation, ECS/Lambda/S3 statements), and administration/kosli_capture.md only ever talks about AWS accounts. A reader on GCP or Azure is told the service uses their provider's API and then given no mechanism to grant access.

This got worse when the "Current status" section was dropped from kosli_capture.md: line 52 there now says Kosli Capture "finds all supported resources within your AWS accounts" and nothing on either page says which resource types those are. The IAM policy below is the only signal (ECS, Lambda, S3).

Suggest scoping this sentence to what exists today and naming the supported resource types on the main page (or restoring a short scope statement there).

Suggested change
The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.
The Kosli Capture managed service uses the public AWS APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.

@claude claude Bot Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — GCP and Azure are claimed only here, and the "publicly accessible" template still has no URL.

Two problems in one sentence:

  1. GCP/Azure. This says Kosli Capture "uses the public AWS, GCP and Azure APIs", but everything else across both pages is AWS-only: IAM role, CloudFormation, ECS and Lambda policy statements, and kosli_capture.md:57/:63 talk only about AWS accounts. A reader on GCP or Azure is told the service uses their provider's API and then given no mechanism to grant access. The Current status section that used to scope this ("Support for … other cloud providers is in active development") was dropped in 7afa53c, so this is now the only provider-scope statement on either page — and it over-claims.
  2. The template URL. "The template is publicly accessible and can be used directly within an aws cloudformation create-stack call" is the most actionable sentence on the page, but the template is named five times across the two pages and never linked. A reader who wants to review the permissions before contacting Customer Success has nowhere to go. If the URL is public, link it and show the create-stack invocation; if it isn't public yet, say "Kosli provides the template during onboarding" so the reader stops looking.
Suggested change
The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.
The Kosli Capture managed service uses the public AWS APIs to extract information about your cloud environments. To do this, you provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template showing the permissions needed, which you can use directly in an `aws cloudformation create-stack` call.

@claude claude Bot Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — GCP and Azure are claimed only here, and the "publicly accessible" template still has no URL.

Two problems in one sentence:

  1. GCP/Azure. This says Kosli Capture "uses the public AWS, GCP and Azure APIs", but every mechanism described across both pages is AWS-only: an IAM role, a CloudFormation template, and ECS/Lambda policy statements. kosli_capture/overview.md:57 and :65 talk only about AWS accounts and regions. The Current status section that used to scope this ("Support for … other cloud providers is in active development") was dropped in 7afa53c, so this line is now the only provider-scope statement on either page — and it over-claims. A reader on GCP or Azure is told their provider's API is used and then given no way to grant access.
  2. The template URL. "The template is publicly accessible and can be used directly within an aws cloudformation create-stack call" is the most actionable sentence on the page, but the template is named five times across the two pages and never once linked. A reader who wants to review the permissions before contacting Customer Success has nowhere to go. If the URL is public, link it and show the create-stack invocation. If it is not public yet, say "Kosli provides the template during onboarding" so the reader stops looking.
Suggested change
The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.
The Kosli Capture managed service uses the public AWS APIs to extract information about your cloud environments. To do this, you provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template showing the permissions needed, which you can use directly in an `aws cloudformation create-stack` call.

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — GCP and Azure are claimed only here, and nothing on any of the three pages gives those readers a mechanism.

This says Kosli Capture "uses the public AWS, GCP and Azure APIs", but every mechanism described across the new folder is AWS-only: an IAM role, a CloudFormation template, an sts:AssumeRole trust policy, and ECS + Lambda policy statements. overview.md:36 says "supported resources within your AWS accounts"; overview.md:44 says "multiple AWS regions and accounts"; getting_started.md:29 says "your ECS clusters and Lambdas".

This became the only provider-scope statement on the site when 7afa53c dropped the Current status section ("Support for … other cloud providers is in active development"), which used to be what kept the claim honest. A reader on GCP or Azure is now told their provider's API is used, reads a page of AWS IAM, and has no way to grant access or to tell that they are out of scope today.

Suggested change
The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.
The Kosli Capture managed service uses the public AWS APIs to extract information about your cloud environments. To do this, you provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template showing the permissions needed, which you can use directly in an `aws cloudformation create-stack` call.

Related, and the reason the scope statement is load-bearing: with Current status gone, the supported resource types are no longer stated anywhere on the site. overview.md:36 says "all supported resources" without defining the set, overview.md:40 uses ECS and Lambda only as incidental examples, and the IAM policy below is now the sole authoritative signal (ECS + Lambda; S3 removed in b6dd574). One sentence on overview.md naming the types would restore what the removed section provided, and gives you an obvious place to update when S3 or EKS lands.

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — GCP and Azure are claimed only here, and no page gives those readers a mechanism.

Every mechanism across the folder is AWS-only: an IAM role, a CloudFormation template, an sts:AssumeRole trust policy, and ECS + Lambda policy statements. overview.md:38 says "within your AWS accounts"; overview.md:46 says "multiple AWS regions and accounts"; getting_started.md:29 says "your ECS clusters and Lambdas".

This became the only provider-scope statement on the site when 7afa53c dropped the Current status section, which used to keep the claim honest ("Support for … other cloud providers is in active development"). A reader on GCP or Azure is now told their provider's API is used, reads a page of AWS IAM, and has no way to tell they are out of scope today.

Second thing in the same sentence: "The template is publicly accessible and can be used directly within an aws cloudformation create-stack call" is the most actionable line on the page, but the template is named nine times across the three pages and never linked. There is no URL to pass to --template-url. If it is public, link it here and at getting_started.md:31; if not, say "Kosli provides the template during onboarding" so the reader stops looking.

Suggested change
The Kosli Capture managed service uses the public AWS, GCP and Azure APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template, for use in AWS, showing the permissions needed. The template is publicly accessible and can be used directly within an `aws cloudformation create-stack` call.
The Kosli Capture managed service uses the public AWS APIs to extract information about your cloud environments. In order to do this, you need to provide Kosli with an IAM role that allows access to these APIs. The role is created and owned by you. Kosli publishes a CloudFormation template showing the permissions needed, which you can use directly within an `aws cloudformation create-stack` call.


The CloudFormation template we share with you includes a "phone-home" feature that notifies Kosli when a CloudFormation stack has been built from it; this allows us to pick up the AWS AccountId for the account in which you have used the CloudFormation template without you needing to do anything. This automation is especially useful when you deploy the template as a StackSet within an Organizational Unit.

### Assume role

The IAM role defined within the CloudFormation template includes an "assume role" policy granting permission from Kosli. This appears as:

```
KosliCaptureAccessRole:
Type: AWS::IAM::Role
Properties:
RoleName: !Ref RoleName
Description: >-
Read-only access for Kosli Capture SDLC compliance evidence collection.
Managed by CloudFormation; do not edit in place.
MaxSessionDuration: 3600
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: AllowKosliToAssumeWithExternalId
Effect: Allow
Principal:
AWS: !Ref TrustedPrincipalArn
Action: sts:AssumeRole
Condition:
StringEquals:
sts:ExternalId: !Ref ExternalId
```

### All permissions needed

The IAM role defined within the Cloudformation template includes a number of IAM policy statements, granting read-only access to some AWS APIs. The statements are:

```
Statement:

# How Capture finds what to snapshot. Discovery lists the ECS
# clusters in the account and reads each cluster's tags from the
# same DescribeClusters call; those tags are what decide which
# Kosli environment a cluster is reported into. Without
# ListClusters and DescribeClusters a role created from this
# template cannot run discovery at all.
#
# Worth knowing for a security review: these are inventory calls
# and none of them returns application data. DescribeTaskDefinition
# is the widest - a task definition holds the container image, the
# command, and any environment variables written into the
# definition itself in plain text. Values injected from Secrets
# Manager or Parameter Store are named there rather than resolved,
# so what comes back is the reference and not the secret.
- Sid: EcsInventory
Effect: Allow
Action:
- ecs:DescribeCapacityProviders
- ecs:DescribeClusters
- ecs:DescribeContainerInstances
- ecs:DescribeServices
- ecs:DescribeTaskDefinition
- ecs:DescribeTasks
- ecs:ListClusters
- ecs:ListContainerInstances
- ecs:ListServices
- ecs:ListTagsForResource
- ecs:ListTaskDefinitionFamilies
- ecs:ListTaskDefinitions
- ecs:ListTasks
Resource: "*"

- Sid: LambdaInventory
Effect: Allow
Action:
- lambda:GetFunctionConfiguration
- lambda:GetPolicy
- lambda:ListAliases
- lambda:ListFunctions
- lambda:ListTags
- lambda:ListVersionsByFunction
Resource: "*"

# lambda:GetFunction returns a pre-signed URL to the deployment
# package. That is source-code access, so it is denied outright.
- Sid: NeverDownloadFunctionCode
Effect: Deny
Action:
- lambda:GetFunction
- lambda:GetLayerVersion
Resource: "*"
````

@claude claude Bot Sep 7, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion — closing fence has four backticks, and neither code block declares a language.

The four-backtick close does still terminate the block under CommonMark, so it renders — but it's a stray character, and neither block (line 20 and line 46) tags a language, so both lose syntax highlighting on what is otherwise a page of YAML.

Change ``` → ```yaml on lines 20 and 46, and:

Suggested change
````

@claude claude Bot Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — stray fourth backtick, and the S3 removal left the block's framing stale.

The closing fence is ```` (four backticks). CommonMark still terminates the block, so it renders — but it's a stray character in the last line of the page.

More substantively: b6dd574 removed the S3BucketMetadataOnly allow and the NeverReadObjectData deny, and with them the comment that explained why the explicit denies exist ("redundant given the allow-list above, but they are here so that a reviewer can verify the boundary…"). The surviving NeverDownloadFunctionCode deny at line 94 is now an unexplained deny in a policy of allows — its own comment explains what it blocks but not why a deny is used rather than simply omitting the action. For a page whose whole purpose is passing a security review, that rationale was worth keeping.

Neither code block declares a language, so both lose highlighting on what is otherwise a page of YAML — change ``` to ```yaml on lines 20 and 46.

Suggested change
````

Comment on lines +94 to +102

@claude claude Bot Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion — the S3 removal left this deny unexplained, and the closing fence has four backticks.

b6dd574 removed the S3BucketMetadataOnly allow and the NeverReadObjectData deny, and with them the comment that explained why explicit denies appear in an allow-list policy at all ("redundant given the allow-list above, but they are here so that a reviewer can verify the boundary…"). NeverDownloadFunctionCode is now the only deny in a policy of allows: its comment says what it blocks, but not why a deny is used rather than simply omitting the action. On a page whose purpose is passing someone else's security review, that rationale was the valuable part.

Also, line 100 closes with (four backticks). CommonMark still terminates the block so it renders, but it is a stray character on the last line of the page. And neither block on this page (lines 20 and 46) declares a language, so a page that is entirely YAML gets no syntax highlighting — worth changing both openers to ```yaml ````.

Suggested change
# lambda:GetFunction returns a pre-signed URL to the deployment
# package. That is source-code access, so it is denied outright.
- Sid: NeverDownloadFunctionCode
Effect: Deny
Action:
- lambda:GetFunction
- lambda:GetLayerVersion
Resource: "*"
````
# lambda:GetFunction returns a pre-signed URL to the deployment
# package. That is source-code access, so it is denied outright.
# The deny is belt-and-braces given the allow-list above, but it
# is here so a reviewer can verify the boundary without reasoning
# about IAM defaults, and so that any future widening of this
# policy cannot accidentally grant code access.
- Sid: NeverDownloadFunctionCode
Effect: Deny
Action:
- lambda:GetFunction
- lambda:GetLayerVersion
Resource: "*"

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion — stray fourth backtick, no language tags, and the S3 removal left this deny unexplained.

The closing fence is ```` (four backticks). CommonMark still terminates the block so the page renders, but it is a stray character on the final line.

Neither code block on this page declares a language (openers at lines 22 and 48), so a page that is entirely YAML gets no syntax highlighting — worth making both ```yaml.

Substantively: b6dd574 removed the S3BucketMetadataOnly allow and the NeverReadObjectData deny, and with them the comment that explained why explicit denies appear in an allow-list policy at all ("redundant given the allow-list above, but they are here so that a reviewer can verify the boundary without having to reason about IAM defaults"). NeverDownloadFunctionCode is now the only deny among allows: its comment says what it blocks, but not why a deny is used rather than simply omitting the action. On a page whose entire purpose is passing someone else's security review, that rationale was the valuable half.

Suggested change
````
# lambda:GetFunction returns a pre-signed URL to the deployment
# package. That is source-code access, so it is denied outright.
# The deny is redundant given the allow-list above, but it is here
# so that a reviewer can verify the boundary without reasoning
# about IAM defaults, and so that any future widening of this
# policy cannot accidentally grant code access.
- Sid: NeverDownloadFunctionCode
Effect: Deny
Action:
- lambda:GetFunction
- lambda:GetLayerVersion
Resource: "*"

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion — stray fourth backtick, no language tags, and the S3 removal left this deny unexplained.

The closing fence here is ```` (four backticks). CommonMark still terminates the block so the page renders, but it is a stray character on the final line.

Neither code block declares a language (openers at lines 22 and 48), so a page that is entirely YAML gets no syntax highlighting — worth making both ```yaml.

Substantively: b6dd574 removed the S3BucketMetadataOnly allow and the NeverReadObjectData deny, and with them the comment explaining why explicit denies appear in an allow-list policy at all ("redundant given the allow-list above, but they are here so that a reviewer can verify the boundary without having to reason about IAM defaults"). NeverDownloadFunctionCode is now the only deny among allows — its comment says what it blocks, but not why a deny rather than simply omitting the action. On a page whose purpose is passing someone else's security review, that rationale was the valuable half.

Suggested change
````

4 changes: 4 additions & 0 deletions administration/managing_environments/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,10 @@ terraform import kosli_environment.my_environment production
The `type` in your Terraform configuration must exactly match the type of the existing environment in Kosli. A mismatch will cause import errors or misconfiguration.
</Warning>

### Automatically creating physical environments

The [Kosli Capture Managed Service](/administration/kosli_capture/overview) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed.
Comment on lines +67 to +69

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — "according to rules you define" is stale, and the section sits outside this page's declared scope.

Two separate problems:

  1. The claim no longer matches the linked page. 0a1e3f9 removed the user-authored configuration document; at this branch head kosli_capture/overview.md:18 says you configure Kosli Capture "by activating it for different AWS services", and getting_started.md:39 is a UI toggle. There are no rules you define — the only reader-controlled input left is the kosli.capture=false exclusion tag. A reader follows this link expecting a rules format and finds none.
  2. Scope clash. Line 13 tells the reader "This page covers managing environments via Terraform. For creating environments via the CLI or UI, see [Getting started: Environments]". Kosli Capture is none of the three, so the section needs to say why it is here. The H3 nesting under "Managing physical environments" is right.

Present tense also reads better than "will automatically snapshot" / "will create" for a capability that exists today.

Suggested change
### Automatically creating physical environments
The [Kosli Capture Managed Service](/administration/kosli_capture/overview) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed.
### Automatically creating physical environments
The [Kosli Capture Managed Service](/administration/kosli_capture/overview) creates physical environments for you, without Terraform. It snapshots the supported resources in your AWS accounts on a schedule and creates the environments it needs as it discovers them.

@claude claude Bot Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improvement — "according to rules you define" no longer matches the page it links to.

0a1e3f9 removed the user-authored configuration document. At this branch head kosli_capture/overview.md:20 says you configure Kosli Capture "by activating it for different AWS services", and getting_started.md:39 is a UI toggle. There are no rules you define — the only reader-controlled input left is the kosli.capture=false exclusion tag. A reader follows this link expecting a rules format and finds none.

Two smaller points on the same block: the H3 nesting under "Managing physical environments" is right, but line 13 tells the reader "This page covers managing environments via Terraform", and Kosli Capture is neither Terraform, CLI, nor UI — saying so explicitly stops the section reading as misfiled. And the two sibling H3s are imperative ("Create a physical environment", "Import an existing physical environment"), so a gerund heading stands out.

Suggested change
The [Kosli Capture Managed Service](/administration/kosli_capture/overview) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed.
### Create physical environments automatically
The [Kosli Capture Managed Service](/administration/kosli_capture/overview) creates physical environments for you, without Terraform. It snapshots the supported resources in your AWS accounts on a schedule and creates the environments it needs as it discovers them.


## Managing logical environments

Logical environments group physical environments into a combined view — useful for representing a full production tier across multiple runtimes.
Expand Down
10 changes: 9 additions & 1 deletion config/navigation.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,15 @@
"administration/managing_custom_attestation_types/overview"
]
},
"administration/managing_tags"
"administration/managing_tags",
{
"group": "Kosli Capture",
"pages": [
"administration/kosli_capture/overview",
"administration/kosli_capture/getting_started",
"administration/kosli_capture/security"
]
Comment on lines +78 to +82

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Critical — administration/kosli_capture/getting_started.md is not listed here. The new group lists only overview and security, so the third new page is an orphan: it will not appear in the sidebar, and nothing else in the repo links to it (grep -rn "kosli_capture/getting_started" returns nothing). CLAUDE.md core rule 2 requires the nav entry, and pytest tests/ enforces navigation integrity — the Test live-docs scripts check should fail this PR as it stands.

Worth deciding placement rather than just appending it. getting_started.md is the only how-to of the three (it has the actual <Steps>, the CloudFormation deployment options, and the kosli.capture=false exclusion tag), so it is also the page a reader arriving from /getting_started/environments most needs. Ordering it first in the group reads better than after security.

Two smaller things while you are in here:

  • overview.md sets sidebarTitle: "Kosli Capture" inside a group also called "Kosli Capture", so the sidebar renders Kosli Capture ▸ Kosli Capture. "Overview" matches the managing_environments / managing_custom_attestation_types groups, which both label their overview.md page as Overview.
  • getting_started.md sets sidebarTitle: "Managed Service", which does not describe a setup page and reads oddly next to a sibling titled Security. "Getting started" or "Setup" would be clearer.
Suggested change
"pages": [
"administration/kosli_capture/overview",
"administration/kosli_capture/security"
]
"pages": [
"administration/kosli_capture/overview",
"administration/kosli_capture/getting_started",
"administration/kosli_capture/security"
]

}
]
},
{
Expand Down
2 changes: 1 addition & 1 deletion getting_started/environments.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,7 @@ Currently, the following environment types are supported:
- Azure Web Apps and Function Apps
- Google Cloud Run (services and jobs)

You can report environment snapshots manually using the `kosli snapshot [...]` commands for testing. For production use, however, you would configure the reporting to happen automatically on regular intervals, e.g. via a cron job or scheduled CI job, or on certain events.
You can report environment snapshots manually using the `kosli snapshot [...]` commands for testing. For production use, however, you would configure the reporting to happen automatically on regular intervals, e.g. via a cron job or scheduled CI job, or on certain events. Kosli can also report these snapshots for you, using the [Kosli Capture Managed Service](/administration/kosli_capture/overview).

You can follow one of the tutorials below to setup automatic snapshot reporting for your environment:
- [Kubernetes environment reporting](/tutorials/report_k8s_envs)
Expand Down