Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
73 changes: 73 additions & 0 deletions administration/kosli_capture/overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
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.
## Overview

Kosli Capture connects to your cloud accounts using permissions that you manage. You configure Kosli Capture by providing a few details describing what you want to be in scope, and Kosli Capture uses the permissions to regularly reach into your estate and record snapshots, sending the data into your Kosli organization. Kosli Capture is architected to be driven by your tagging scheme; it examines the tags on your infrastructure and uses them to determine how to structure the snapshots, and how to build the environments within Kosli.

There are several benefits to this this architecture:

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 — duplicated word, and the bullets use semicolon terminators.

"to this this architecture" has a doubled "this". Also, the two bullets end in ; and . and begin lowercase — every other bulleted list in this file and in kosli_capture_security.md uses sentence-cased bullets (see lines 29–31).

Suggested change
There are several benefits to this this architecture:
There are several benefits to this architecture:
* The only infrastructure you need to manage is an IAM role — you do not need to install or run any additional software in your cloud estate.
* Kosli Capture leverages your existing tagging scheme, so as your infrastructure evolves, Kosli Capture automatically discovers the snapshots it needs to take.


* the only infrastructure you need to manage is an IAM role; you do not need to install or execute any additional software in your cloud estate;
* Kosli Capture leverages your existing tagging scheme, so as your infrastructure evolves, Kosli Capture will automatically discover the snapshots it needs to take.
Comment on lines +20 to +23

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 — doubled word, and these two bullets are punctuated unlike every other list on the pages.

"to this this architecture" has a doubled "this". The bullets also start lowercase and terminate with ; / ., whereas the bulleted lists at lines 29–31 and on the security page are sentence-cased.

Suggested change
There are several benefits to this this architecture:
* the only infrastructure you need to manage is an IAM role; you do not need to install or execute any additional software in your cloud estate;
* Kosli Capture leverages your existing tagging scheme, so as your infrastructure evolves, Kosli Capture will automatically discover the snapshots it needs to take.
There are several benefits to this architecture:
* The only infrastructure you need to manage is an IAM roleyou do not need to install or run any additional software in your cloud estate.
* Kosli Capture leverages your existing tagging scheme, so as your infrastructure evolves, Kosli Capture automatically discovers the snapshots it needs to take.


## 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 +25 to +27

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 does not hold any customer data, it is near-stateless with the only thing it keeps is your configuration data. Snapshots taken by Kosli Catpure are immediately sent to Kosli through the same ingest path as your existing pipelines.
Comment on lines +27 to +33

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 — this section still refers to an unnamed "customer A". Line 29 reads "Only that role is permitted to call AssumeRole into A's account with A's ExternalId." Nothing on the page defines "A" — it's carried over from an internal design document where customers were labelled A and B. A reader hits an unresolvable pronoun in the one section they are most likely to forward to their security team.

Three more defects in the same block:

  • Line 27 has no closing full stop ("...scoped to one customer").
  • "Kosli Catpure" appears twice on line 33 — the product name is misspelled. Vale won't catch this: .vale.ini sets BasedOnStyles = Kosli, and styles/Kosli/ contains only AmericanSpelling.yml, so there is no general spellchecker on this repo.
  • Line 33 is a comma splice ("...customer data, it is near-stateless...").
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 does not hold any customer data, it is near-stateless with the only thing it keeps is your configuration 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 holds no customer data. It is near-stateless, keeping only your configuration. Snapshots taken by Kosli Capture are immediately sent to Kosli through the same ingest path as your existing pipelines.

(The suggestion also unifies on "external ID", which is the form used on lines 71–73 and on the security page.)

Comment on lines +27 to +33

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 29 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 one section a reader is most likely to forward to their own security team, and it contains an unresolvable pronoun.

Two more defects in the same block: line 27 has no closing full stop ("...scoped to one customer"), and line 33 is a comma splice ("...customer data, it is near-stateless...") whose second clause also doesn't parse ("with the only thing it keeps is your configuration data").

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 does not hold any customer data, it is near-stateless with the only thing it keeps is your configuration 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 holds no customer data. It is near-stateless, keeping only your configuration. Snapshots taken by Kosli Capture are immediately sent to Kosli through the same ingest path as your existing pipelines.

(The suggestion also unifies on "external ID", the form used on lines 71–73 and on the security page.)


## 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 according to your tagging scheme 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.

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 over-claims against the tag-driven model the page is built on, plus two word-level defects.

"your application teams do not need to take any action in order to onboard their products and services into Kosli" contradicts lines 18, 23 and 57, which all say routing is driven by your tagging scheme. An untagged new service can't be routed into an environment — so the action app teams do need to take is tagging their resources to the scheme. Saying that is more useful than claiming zero action, and it's exactly what a platform team needs to pass on.

Also on this line: "rotation of API keys is all handed automatically" → "handled", and "Kosli capture" is lowercase twice (capitalized everywhere else on the page). Neither is caught by vale-spellcheckstyles/Kosli/ only holds AmericanSpelling.yml.

Suggested change
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 according to your tagging scheme 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.
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 handled automatically. As your cloud infrastructure changes over time, Kosli Capture will continue to find resources according to your tagging scheme; as long as application teams tag their resources to that scheme, their products and services are onboarded into Kosli with no further action.

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 — the closing clause over-claims against the tag-driven model this page is built on.

"your application teams do not need to take any action in order to onboard their products and services into Kosli" contradicts lines 18, 23 and 57, which all say routing is driven by your tagging scheme. An untagged new service cannot be routed into an environment, so the action app teams do need to take is tagging their resources to the scheme. Stating that is more useful than claiming zero action — it is exactly the instruction a platform team needs to pass on, and it is the one thing that will generate support tickets if left unsaid.

Suggested change
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 according to your tagging scheme 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.
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 handled automatically. As your cloud infrastructure changes over time, Kosli Capture will continue to find resources according to your tagging scheme; as long as application teams tag their resources to that scheme, their products and services are onboarded into Kosli with no further action.


## Setup

Getting started with Kosli Capture involves three 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 during onboarding.

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 — the CloudFormation template is the one artifact the reader has to get hold of, and it's still not linked. It's named four times across the two pages (here, line 64, and kosli_capture_security.md:14), and the security page now says it "is publicly accessible and can be used directly within an aws cloudformation create-stack call" — which makes the missing URL more conspicuous, not less. A reader who wants to review the permissions before contacting Customer Success is stuck.

If the URL is public, link it here and on the security page. If it isn't public yet, say that explicitly ("Kosli provides the template during onboarding") so the reader stops looking.

</Step>
<Step title="Write the configuration document">
Working with Kosli's Customer Success team, author a configuration document that shows how your cloud resources should be mapped to Kosli environments. This configuration document is loaded into Kosli.
</Step>
<Step title="Enable Kosli Capture">
Kosli enables Kosli Capture for your Kosli org, and the regular snapshots appear in Kosli.
</Step>
</Steps>

## Finding resources

Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.

Kosli Capture can filter out resources based on your tags.

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.

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 +57 to +61

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 still stated twice. Line 38 ends with "Kosli Capture will create physical environments for you", and line 42 repeats it ("Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up"). The second sentence in line 42 is also circular — it restates the claim as the reason for itself.

Fold the capability into the paragraph that explains why it matters, and drop it from line 38:

Suggested change
Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
Kosli Capture can filter out resources based on your tags.
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 finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots.
Kosli Capture can filter out resources based on your tags.
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.

Comment on lines +57 to +61

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 still claimed twice, and the second one is circular.

Line 38 ends with "Kosli Capture will create physical environments for you", then line 42 says "Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up" — which restates the claim as the reason for itself. The genuinely new information in that paragraph is that evolving infrastructure needs no reconfiguration; folding the auto-creation into it lands the claim once, in the place where it matters.

Suggested change
Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
Kosli Capture can filter out resources based on your tags.
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 finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots.
Kosli Capture can filter out resources based on your tags.
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.

Comment on lines +57 to +61

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 now undefined anywhere on the site, and auto-creation is claimed twice.

The Current status section was removed in 7afa53c, which took with it the only statement of what Kosli Capture can snapshot. As of this HEAD:

  • line 57 says "all supported resources" without defining the set;
  • line 61 uses ECS clusters and Lambdas as incidental examples;
  • the only actual signal is the IAM policy on the security page (ECS + Lambda — S3 was dropped in b6dd574).

So a reader evaluating Kosli Capture has to reverse-engineer the supported resource types from an IAM policy two pages away. One sentence naming them ("Kosli Capture currently snapshots ECS services and Lambda functions") restores what the removed section provided, and keeps this page in sync when S3 or EKS lands.

Separately, environment auto-creation is stated on line 57 ("Kosli Capture will create physical environments for you") and again on line 61 ("Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up") — the second is circular, restating the claim as its own reason. Folding it into the evolution paragraph lands it once, where it matters.

Suggested change
Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
Kosli Capture can filter out resources based on your tags.
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 services and Lambda functions. It finds these resources within your AWS accounts and examines their tags to determine which Kosli environment should hold the snapshots.
Kosli Capture can filter out resources based on your tags.
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.

Comment on lines +57 to +61

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 no longer defined anywhere on the site.

7afa53c removed the Current status section, which was the only statement of what Kosli Capture can snapshot, and b6dd574 then dropped the S3 statements from the policy on the security page. At this HEAD:

  • line 57 says "all supported resources" without defining the set;
  • line 61 uses ECS clusters and Lambdas only as incidental examples;
  • the only real signal is the IAM policy on security.md (ECS + Lambda).

So a reader evaluating Kosli Capture has to reverse-engineer the supported resource types from an IAM policy on another page. One sentence naming them restores what the removed section provided, and gives you an obvious place to update when S3 or EKS lands.

Separately, environment auto-creation is claimed twice — line 57 ("Kosli Capture will create physical environments for you") and again on line 61 ("Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up"), where it is restated as its own reason. Folding it into the evolution paragraph lands it once, in the place where it matters.

Suggested change
Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
Kosli Capture can filter out resources based on your tags.
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 services and Lambda functions. It finds these resources within your AWS accounts and examines their tags to determine which Kosli environment should hold the snapshots.
Kosli Capture can filter out resources based on your tags.
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.


## 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 configuration document.

## 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 +67 to +73

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.

100 changes: 100 additions & 0 deletions administration/kosli_capture/security.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
---
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.

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.

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.

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.


### 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: "*"
````

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
````

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 +92 to +100

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: "*"

4 changes: 4 additions & 0 deletions administration/managing_environments/overview.md
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.

## Managing logical environments

Logical environments group physical environments into a combined view — useful for representing a full production tier across multiple runtimes.
Expand Down
9 changes: 8 additions & 1 deletion config/navigation.json
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,14 @@
"administration/managing_custom_attestation_types/overview"
]
},
"administration/managing_tags"
"administration/managing_tags",
{
"group": "Kosli Capture",
"pages": [
"administration/kosli_capture/overview",
"administration/kosli_capture/security"
]
}
]
},
{
Expand Down
2 changes: 1 addition & 1 deletion getting_started/environments.md
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