diff --git a/administration/cloud_capture/overview.md b/administration/cloud_capture/overview.md index b7b2a1c..06b4c21 100644 --- a/administration/cloud_capture/overview.md +++ b/administration/cloud_capture/overview.md @@ -20,7 +20,7 @@ To set it up for your organization, see [Getting started with Cloud Capture](/ad Cloud Capture connects to your cloud accounts using permissions that you manage. You configure Cloud Capture by activating it for different services, and Cloud Capture uses the permissions to regularly reach into your estate and record snapshots, sending the data into your Kosli organization. Cloud Capture uses details about your infrastructure, such as the name of an ECS cluster, to build environments within Kosli. -Diagram showing Cloud Capture, inside Kosli, sending queries to and receiving snapshots from three customer cloud accounts, then passing the data to the Kosli API and database +Diagram showing Cloud Capture, inside Kosli, sending queries to and receiving snapshots from three tenant cloud accounts, then passing the data to the Kosli API and database ## Security @@ -28,8 +28,8 @@ Cloud Capture connects to your cloud accounts using permissions that you manage. The security of your cloud infrastructure is the primary driver behind the internal architecture of Cloud Capture. You grant a read-only IAM role in your account, protected by an external ID that acts as a shared secret between Kosli and you. On Kosli's side, each Cloud Capture job runs under a role -scoped to your organization alone, so a worker running for another customer cannot reach your cloud -account. Cloud Capture holds no customer data; snapshots go straight to Kosli through the same ingest +scoped to your organization alone, so a worker running for another tenant cannot reach your cloud +account. Cloud Capture holds no tenant data; snapshots go straight to Kosli through the same ingest path as your existing pipelines. See [Cloud Capture Security](/administration/cloud_capture/security) for the isolation model and the full list of permissions. diff --git a/administration/cloud_capture/security.md b/administration/cloud_capture/security.md index e4cc5ef..5db3178 100644 --- a/administration/cloud_capture/security.md +++ b/administration/cloud_capture/security.md @@ -127,8 +127,8 @@ The trust has two parts, mirroring the AWS assume-role policy and external ID. T pool accepts credentials only from the Kosli AWS account, which is the counterpart of the principal in the trust policy. Within that account it accepts only the Kosli-side IAM role that is dedicated to your organization, which is the counterpart of the external ID. Every Cloud Capture job runs -under the role for the organization it is working for, so a job for another Kosli customer presents -a different role name and is refused by your pool, even if that customer gave Kosli your provider +under the role for the organization it is working for, so a job for another Kosli tenant presents +a different role name and is refused by your pool, even if that tenant gave Kosli your provider and service account instead of their own. The role name is part of the credential that AWS signs and Google verifies, so it cannot be forged by the caller. @@ -163,7 +163,7 @@ variable "kosli_aws_account_id" { type = string description = <<-EOT The AWS account in which Cloud Capture runs, supplied by Kosli. It differs - per customer because more than one Kosli account serves customers. There + per tenant because more than one Kosli account serves tenants. There is no default and no value you can derive yourself. EOT @@ -223,7 +223,7 @@ resource "google_iam_workload_identity_pool_provider" "kosli_aws" { # Kosli account are accepted, however the token reaches Google. The role # check is the counterpart of the external ID: within that account, only the # Kosli-side role dedicated to your organization is accepted. A Cloud Capture - # job for another customer runs under a different role and is refused here. + # job for another tenant runs under a different role and is refused here. attribute_condition = join(" && ", [ "attribute.account == \"${var.kosli_aws_account_id}\"", "attribute.aws_role == \"${var.kosli_role_name}\"", @@ -322,25 +322,25 @@ gcloud infra-manager deployments apply \ -## How Kosli isolates customers +## How Kosli isolates tenants Cloud Capture runs as a shared, autoscaled service, but each job runs under a role that is scoped to -one customer: +one tenant: * A Cloud Capture worker picks up a job for your organization and assumes the role in your account - using your externalId. A worker running for a different customer is unable to read the externalId + using your externalId. A worker running for a different tenant is unable to read the externalId for your cloud account. * When the job finishes, the temporary credentials for your account are discarded. A worker holding credentials for your cloud account has no path to anyone else's account. * The ExternalId lives in Kosli's 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 + organization. The shared task role cannot read any tenant's ExternalId. Separation is enforced by IAM, not by application code. The trust policy on the role in your account limits access to the AWS account in which the Cloud Capture is running. The ExternalId acts as a shared secret between Kosli and you, so that only Cloud Capture is permitted to assume the role. -Cloud Capture itself does not hold any customer data. Snapshots taken by Cloud Capture are +Cloud Capture itself does not hold any tenant data. Snapshots taken by Cloud Capture are immediately sent to Kosli through the same ingest path as your existing pipelines. ## Changing security permissions