From 193060c881c69b46c741d48a6249e87876f7deed Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Wed, 2 Sep 2026 12:07:12 +0000 Subject: [PATCH 1/5] feat: add Kosli Capture Managed Service page to Getting started --- administration/kosli_capture.md | 70 +++++++++++++++++++ .../managing_environments/overview.md | 4 ++ config/navigation.json | 3 +- getting_started/environments.md | 2 +- 4 files changed, 77 insertions(+), 2 deletions(-) create mode 100644 administration/kosli_capture.md diff --git a/administration/kosli_capture.md b/administration/kosli_capture.md new file mode 100644 index 00000000..abbcb53d --- /dev/null +++ b/administration/kosli_capture.md @@ -0,0 +1,70 @@ +--- +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: "BETA" +--- + + +Kosli Capture is still in beta. Its capabilities and configuration format may change, and onboarding is done together with Kosli's Customer Success team. + + +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. + +## Current status + +Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. + +## Approach + +Getting started with Kosli Capture involves three stages: + + + + 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. + + + 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. + + + Kosli enables Kosli Capture for your Kosli org, and the regular snapshots appear in Kosli. + + + +## 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. + +## Revoking Kosli Capture + +To prevent Kosli Capture from snapshotting your infrastructure, revoke the IAM role created in the initial setup. This role is the only mechanism for Kosli Capture to connect to your cloud environment, so revoking it acts as a simple kill-switch. + +## Multiple AWS accounts + +Kosli Capture can operate across multiple AWS 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 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 that has been configured for you. + +## Kosli Capture runtime details + +Within Kosli's AWS accounts, every customer has a dedicated instance of Kosli Capture running. The Kosli Capture instance for a customer is granted access to that customer's external ID and no other customer's external ID. Similarly, the API token needed to access the Kosli API on behalf of a customer is only accessible by the specific instance of Kosli Capture for that customer. By running isolated instances of the managed service per customer, Kosli guarantees that each customer's data remains separate. + +## Snapshot frequency + +The configuration for the Kosli Capture Managed Service includes a snapshot frequency parameter. Kosli defaults to running a snapshot every five minutes, but you can change the frequency to meet your own requirements. + +## Scaling + +Kosli Capture runs multiple snapshots in parallel to support customers with large numbers of Kosli environments or AWS accounts. diff --git a/administration/managing_environments/overview.md b/administration/managing_environments/overview.md index 5727f0b6..1d56bacd 100644 --- a/administration/managing_environments/overview.md +++ b/administration/managing_environments/overview.md @@ -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. +### Automatically creating physical environments + +The [Kosli Capture Managed Service](/administration/kosli_capture) 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. diff --git a/config/navigation.json b/config/navigation.json index a536cb54..b6128484 100644 --- a/config/navigation.json +++ b/config/navigation.json @@ -72,7 +72,8 @@ "administration/managing_custom_attestation_types/overview" ] }, - "administration/managing_tags" + "administration/managing_tags", + "administration/kosli_capture" ] }, { diff --git a/getting_started/environments.md b/getting_started/environments.md index ed8723ff..dfa1c242 100644 --- a/getting_started/environments.md +++ b/getting_started/environments.md @@ -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). You can follow one of the tutorials below to setup automatic snapshot reporting for your environment: - [Kubernetes environment reporting](/tutorials/report_k8s_envs) From 0d7fb5379ec0c406904263ced9b8e6d1db74a522 Mon Sep 17 00:00:00 2001 From: Graham Savage Date: Mon, 7 Sep 2026 14:35:26 +0100 Subject: [PATCH 2/5] Add more Kosli Capture IAM details --- administration/kosli_capture.md | 46 ++++---- administration/kosli_capture_security.md | 134 +++++++++++++++++++++++ config/navigation.json | 8 +- 3 files changed, 163 insertions(+), 25 deletions(-) create mode 100644 administration/kosli_capture_security.md diff --git a/administration/kosli_capture.md b/administration/kosli_capture.md index abbcb53d..5cfd3be8 100644 --- a/administration/kosli_capture.md +++ b/administration/kosli_capture.md @@ -2,30 +2,44 @@ 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: "BETA" +tag: "ALPHA" --- -Kosli Capture is still in beta. Its capabilities and configuration format may change, and onboarding is done together with Kosli's Customer Success team. +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. 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. -## Current status +## Overview -Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly. +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. -## Approach +## Security + +The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. + +* Each customer has their own dedicated instance of Kosli Capture +* The service connects to your cloud using IAM permissions that you manage, secured using a shared-secret. +* Snapshots are written to your Kosli organizations using an API key that you are able to revoke + +Within Kosli's AWS accounts, every customer has a dedicated instance of Kosli Capture, and its permissions are limited to reading the shared-secret and API key for your organization only. By running isolated instances of the managed service per customer, Kosli guarantees that each customer's data remains separate. + +## 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 without needing additional support. 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. + +## Setup Getting started with Kosli Capture involves three stages: - + 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. - + 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. @@ -41,30 +55,14 @@ 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. -## Revoking Kosli Capture - -To prevent Kosli Capture from snapshotting your infrastructure, revoke the IAM role created in the initial setup. This role is the only mechanism for Kosli Capture to connect to your cloud environment, so revoking it acts as a simple kill-switch. - ## Multiple AWS accounts Kosli Capture can operate across multiple AWS 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. +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](./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 that has been configured for you. - -## Kosli Capture runtime details - -Within Kosli's AWS accounts, every customer has a dedicated instance of Kosli Capture running. The Kosli Capture instance for a customer is granted access to that customer's external ID and no other customer's external ID. Similarly, the API token needed to access the Kosli API on behalf of a customer is only accessible by the specific instance of Kosli Capture for that customer. By running isolated instances of the managed service per customer, Kosli guarantees that each customer's data remains separate. - -## Snapshot frequency - -The configuration for the Kosli Capture Managed Service includes a snapshot frequency parameter. Kosli defaults to running a snapshot every five minutes, but you can change the frequency to meet your own requirements. - -## Scaling - -Kosli Capture runs multiple snapshots in parallel to support customers with large numbers of Kosli environments or AWS accounts. diff --git a/administration/kosli_capture_security.md b/administration/kosli_capture_security.md new file mode 100644 index 00000000..36d4b950 --- /dev/null +++ b/administration/kosli_capture_security.md @@ -0,0 +1,134 @@ +--- +title: Kosli Capture - Security +sidebarTitle: Security +description: "Learn about the security of Kosli Capture" +tag: "ALPHA" +--- + + +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. + + +## 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. + +### 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: "*" + + - Sid: S3BucketMetadataOnly + Effect: Allow + Action: + - s3:GetBucketLocation + - s3:GetBucketLogging + - s3:GetBucketPolicyStatus + - s3:GetBucketPublicAccessBlock + - s3:GetBucketTagging + - s3:GetBucketVersioning + - s3:GetEncryptionConfiguration + - s3:ListAllMyBuckets + Resource: "*" + + # The explicit denies below are 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, and so + # that any future widening of this policy cannot accidentally + # grant data-plane access. + - Sid: NeverReadObjectData + Effect: Deny + Action: + - s3:GetObject + - s3:GetObjectAcl + - s3:GetObjectAttributes + - s3:GetObjectTagging + - s3:GetObjectTorrent + - s3:GetObjectVersion + - s3:GetObjectVersionAcl + - s3:GetObjectVersionAttributes + - s3:GetObjectVersionTagging + - s3:ListMultipartUploadParts + 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: "*" +```` + diff --git a/config/navigation.json b/config/navigation.json index b6128484..0768049b 100644 --- a/config/navigation.json +++ b/config/navigation.json @@ -73,7 +73,13 @@ ] }, "administration/managing_tags", - "administration/kosli_capture" + { + "group": "Kosli Capture", + "pages": [ + "administration/kosli_capture", + "administration/kosli_capture_security" + ] + } ] }, { From 7afa53ce5cb1915bef87a095794fb6005171782f Mon Sep 17 00:00:00 2001 From: Graham Savage Date: Mon, 14 Sep 2026 16:12:28 +0100 Subject: [PATCH 3/5] Update Capture docs to reflect recent decisions We've recently decided on a slightly different approach to the runtime security of the Kosli Capture service, and this commit updates the overall documentation to be aligned to the changes we've decided --- administration/kosli_capture.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/administration/kosli_capture.md b/administration/kosli_capture.md index 5cfd3be8..44ebf007 100644 --- a/administration/kosli_capture.md +++ b/administration/kosli_capture.md @@ -17,19 +17,24 @@ Kosli also supports reporting from your own cloud accounts by running the Kosli 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: + +* 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. + ## Security -The security of your cloud infrastructure is the primary driver behind the internal architecture of the Kosli Capture managed service. +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 -* Each customer has their own dedicated instance of Kosli Capture -* The service connects to your cloud using IAM permissions that you manage, secured using a shared-secret. -* Snapshots are written to your Kosli organizations using an API key that you are able to revoke +* 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. -Within Kosli's AWS accounts, every customer has a dedicated instance of Kosli Capture, and its permissions are limited to reading the shared-secret and API key for your organization only. By running isolated instances of the managed service per customer, Kosli guarantees that each customer's data remains separate. +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. ## 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 without needing additional support. 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 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. ## Setup @@ -57,7 +62,7 @@ As your cloud environment evolves, such as the addition of new ECS clusters or t ## Multiple AWS accounts -Kosli Capture can operate across multiple AWS accounts, allowing you to snapshot development, QA, pre-production, and production workloads with the same configuration document. +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 @@ -65,4 +70,4 @@ For Kosli Capture to snapshot your environment, you must grant a set of read-onl 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 that has been configured for you. +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. From b6dd574339bc178b8df7df15d691e09ee8bbcd06 Mon Sep 17 00:00:00 2001 From: Graham Savage Date: Mon, 14 Sep 2026 16:24:07 +0100 Subject: [PATCH 4/5] Remove S3 from the Cloudformation Template Kosli Capture does not need S3 access _at the moment_ and so removing it here helps to provide a simpler security-posture. --- administration/kosli_capture_security.md | 34 ------------------------ 1 file changed, 34 deletions(-) diff --git a/administration/kosli_capture_security.md b/administration/kosli_capture_security.md index 36d4b950..9606845a 100644 --- a/administration/kosli_capture_security.md +++ b/administration/kosli_capture_security.md @@ -89,39 +89,6 @@ Statement: - lambda:ListVersionsByFunction Resource: "*" - - Sid: S3BucketMetadataOnly - Effect: Allow - Action: - - s3:GetBucketLocation - - s3:GetBucketLogging - - s3:GetBucketPolicyStatus - - s3:GetBucketPublicAccessBlock - - s3:GetBucketTagging - - s3:GetBucketVersioning - - s3:GetEncryptionConfiguration - - s3:ListAllMyBuckets - Resource: "*" - - # The explicit denies below are 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, and so - # that any future widening of this policy cannot accidentally - # grant data-plane access. - - Sid: NeverReadObjectData - Effect: Deny - Action: - - s3:GetObject - - s3:GetObjectAcl - - s3:GetObjectAttributes - - s3:GetObjectTagging - - s3:GetObjectTorrent - - s3:GetObjectVersion - - s3:GetObjectVersionAcl - - s3:GetObjectVersionAttributes - - s3:GetObjectVersionTagging - - s3:ListMultipartUploadParts - Resource: "*" - # lambda:GetFunction returns a pre-signed URL to the deployment # package. That is source-code access, so it is denied outright. - Sid: NeverDownloadFunctionCode @@ -131,4 +98,3 @@ Statement: - lambda:GetLayerVersion Resource: "*" ```` - From 6e1d5c5b554599f98f5f1e185b76c43bf9543126 Mon Sep 17 00:00:00 2001 From: Graham Savage Date: Mon, 14 Sep 2026 17:48:28 +0100 Subject: [PATCH 5/5] docs: move Kosli Capture pages into their own folder More Kosli Capture content is coming, so the two existing pages now live under administration/kosli_capture/ rather than as loose files in administration/. The files are renamed to overview.md and security.md to match the sibling groups such as managing_environments/overview. The navigation group and the inbound links from the environments pages are updated to the new paths. The overview page's link to the security page was a relative link, which the repo conventions forbid, so it is now root-relative. No redirects are added because these pages have not yet been published from main. Co-Authored-By: Claude Fable 5.1 --- .../{kosli_capture.md => kosli_capture/overview.md} | 2 +- .../{kosli_capture_security.md => kosli_capture/security.md} | 0 administration/managing_environments/overview.md | 2 +- config/navigation.json | 4 ++-- getting_started/environments.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) rename administration/{kosli_capture.md => kosli_capture/overview.md} (97%) rename administration/{kosli_capture_security.md => kosli_capture/security.md} (100%) diff --git a/administration/kosli_capture.md b/administration/kosli_capture/overview.md similarity index 97% rename from administration/kosli_capture.md rename to administration/kosli_capture/overview.md index 44ebf007..15b0e635 100644 --- a/administration/kosli_capture.md +++ b/administration/kosli_capture/overview.md @@ -66,7 +66,7 @@ Kosli Capture can operate across multiple AWS regions and accounts, allowing 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. The permissions are typically "Describe" or "List" permissions. The [Kosli Capture Security](./kosli_capture_security) page provides a deep-diver into the structure of the permissions needed. +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. diff --git a/administration/kosli_capture_security.md b/administration/kosli_capture/security.md similarity index 100% rename from administration/kosli_capture_security.md rename to administration/kosli_capture/security.md diff --git a/administration/managing_environments/overview.md b/administration/managing_environments/overview.md index 1d56bacd..20534966 100644 --- a/administration/managing_environments/overview.md +++ b/administration/managing_environments/overview.md @@ -66,7 +66,7 @@ The `type` in your Terraform configuration must exactly match the type of the ex ### Automatically creating physical environments -The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed. +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 diff --git a/config/navigation.json b/config/navigation.json index 0768049b..af5dc731 100644 --- a/config/navigation.json +++ b/config/navigation.json @@ -76,8 +76,8 @@ { "group": "Kosli Capture", "pages": [ - "administration/kosli_capture", - "administration/kosli_capture_security" + "administration/kosli_capture/overview", + "administration/kosli_capture/security" ] } ] diff --git a/getting_started/environments.md b/getting_started/environments.md index dfa1c242..6e9bfb0c 100644 --- a/getting_started/environments.md +++ b/getting_started/environments.md @@ -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. Kosli can also report these snapshots for you, using the [Kosli Capture Managed Service](/administration/kosli_capture). +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)