diff --git a/concepts/billing.mdx b/concepts/billing.mdx index aee2d203..1fd62bcb 100644 --- a/concepts/billing.mdx +++ b/concepts/billing.mdx @@ -6,24 +6,24 @@ keywords: ['pricing', 'subscription', 'credit card', 'stripe', 'invoice download ## Overview -A billing account allows you to manage user access, invoices, payment methods, and spending threshold alerts. You can create multiple billing accounts to manage billing separately. +A billing account allows you to manage user access, invoices, payment methods, and spending threshold alerts. You can create multiple billing accounts to manage billing independently. -In each billing account, you can access: +Each billing account provides access to: -- [Account Details](#account-details): Manage personal details, billing information, and spend threshold email alert. -- [Orgs](/reference/org): View the orgs linked to this billing account. -- Invoices: View and download invoices. -- Payment Methods: Add, update, or remove payment methods. -- [Users](#users): Manage user access, roles, and permissions. -- Cost & Usage: Review cost and usage across all orgs in this billing account. +- [Account Details](#account-details): Manage account details, billing information, and spend threshold email alert. +- [Orgs](/reference/org): View the orgs associated with this billing account. +- Invoices: View and download billing invoices. +- Payment Methods: Add, update, and remove payment methods. +- [Users](#users): Manage user access, roles, and permissions. +- Cost & Usage: Review cost and usage across all orgs associated in this billing account. ### Account Details View and manage your billing account information. ### Spend Threshold Email Alert -Spend threshold email alerts help you monitor your billing account. You must first enable the spend alert to receive an email when you reach the monthly limit that has been set. +Spend threshold email alerts help you monitor billing usage and spending. You must first enable the spend alert to receive email notifications when your configured monthly threshold is reached. ### Users -You can add users to your billing account. You must assign them a role of either billing_admin or billing_viewer. Additionally, you can assign a user as an org_creator. The user will gain immediate access to the billing account once added. \ No newline at end of file +You can add users to your billing account and assign billing roles. You must assign them a role of either billing_admin or billing_viewer. Additionally, you can assign a user as an org_creator. The user will gain immediate access to the billing account once added. \ No newline at end of file diff --git a/concepts/gvc.mdx b/concepts/gvc.mdx index d37617d7..3ddcbb5c 100644 --- a/concepts/gvc.mdx +++ b/concepts/gvc.mdx @@ -6,22 +6,22 @@ keywords: ['cpln', 'multi-region', 'geo', 'pull secret', 'private registry', 'im ## Overview -A Global Virtual Cloud ([GVC](/reference/gvc)) defines a set of cloud providers and their [locations](/reference/location). +A Global Virtual Cloud ([GVC](/reference/gvc)) defines a set of cloud providers and deployment [locations](/reference/location). -When creating a GVC you are in essence building an uber-cloud that is comprised of the specified [locations](/reference/location). [Workloads](/concepts/workload) are deployed to the GVC which are then served from all the [locations](/reference/location) specified. +When creating a GVC effectively builds a unified multi-cloud environment that is comprised of the specified [locations](/reference/location). [Workloads](/concepts/workload) are deployed to the GVC which are then served from all the configured [locations](/reference/location). -Each [org](/reference/org) can have multiple GVCs, each with its own unique set of [locations](/reference/location). +Each [org](/reference/org) can have multiple GVCs, each with its own set of [locations](/reference/location). -A [domain name](/reference/domain) owned at the org level can be assigned to a GVC for routing. Each domain is associated with exactly one GVC at a time. Callers can reach [workloads](/concepts/workload) using the assigned [domain name](/reference/domain). +A [domain name](/reference/domain) configured at the org level can be assigned to a GVC for routing. Each domain is associated with exactly one GVC at a time. Traffic is routed to [workloads](/concepts/workload) using the assigned [domain name](/reference/domain). ## Benefits -- GVCs enable your [workload](/concepts/workload) to be deployed with ease to multiple cloud providers and locations - - You choose the provider (AWS, Azure, and GCP) and their different locations - - Select [locations](/reference/location) that are close to your end-users - - Select the [locations](/reference/location) that fulfill the requirements of your workloads - - Ensure maximum availability if a cloud provider has an occasional outage -- You get granular controls to define the scaling characteristics of your [workload](/concepts/workload) +- GVCs enable your [workload](/concepts/workload) to be deployed easily to multiple cloud providers and locations + - Choose cloud providers such as (AWS, Azure, and GCP) along with their deployment locations + - Select [locations](/reference/location) close to your end users + - Select the [locations](/reference/location) that fulfill your workload requirements + - Ensure maximum availability if a cloud provider experiences an outage + - Configure granular scaling behavior for your [workload](/concepts/workload) ## Domain Name @@ -29,17 +29,17 @@ A [domain name](/reference/domain) owned at the org level can be assigned to a G ## Pull Secrets -Pull secrets are [secrets](/reference/secret) that are assigned to a GVC and used by [workloads](/concepts/workload) when authentication is required for pulling an image from a private registry. Only the [Docker](/reference/secret#docker), [Amazon ECR](/reference/secret#ecr), and [GCP](/reference/secret#google-cloud-platform-gcp) [secret](/reference/secret) types are supported. +Pull secrets are [secrets](/reference/secret) assigned to a GVC and used by [workloads](/concepts/workload) when authentication is required to pull an image from a private registry. Only the [Docker](/reference/secret#docker), [Amazon ECR](/reference/secret#ecr), and [GCP](/reference/secret#google-cloud-platform-gcp) [secret](/reference/secret) types are supported. If the image was pushed to the Control Plane registry for the same [org](/reference/org), no secret is required. -Multiple pull secrets can be assigned to a GVC. A [workload's container](/concepts/workload) will use the appropriate secret when pulling the image from a private registry. If there are multiple secrets, the container will cycle through each one. +A GVC can have multiple pull secrets assigned. A [workload's container](/concepts/workload) will use the appropriate secret when pulling images from a private registry. f multiple secrets are configured, the container attempts each secret in sequence. -If authentication fails, the deployment will not be updated and the image pull will have an exponential backoff retry starting at 10 seconds until 5 minutes (e.g., 10 seconds, 20 seconds, 40 seconds, etc.). +If authentication fails, the deployment is not updated and the image pull will have an exponential backoff retry starting at 10 seconds until 5 minutes (e.g., 10 seconds, 20 seconds, 40 seconds, etc.). ## Location Routing -By default, traffic is routed to the nearest healthy location using DNS geo-routing based on latency. For more complex routing scenarios, you can configure [location routing options](/reference/gvc#location-routing-options) on a per-GVC basis to control priority-based failover, adjust traffic distribution with latency offsets, and set latency thresholds for location availability. +By default, traffic is routed to the nearest healthy location using latency-based DNS geo-routing. For more advanced routing scenarios, you can configure [location routing options](/reference/gvc#location-routing-options) on a per-GVC basis to control priority-based failover, adjust traffic distribution with latency offsets, and set latency thresholds for location availability. ## Reference diff --git a/concepts/org.mdx b/concepts/org.mdx index 07df8b41..2de3e9dd 100644 --- a/concepts/org.mdx +++ b/concepts/org.mdx @@ -6,14 +6,13 @@ keywords: ['tenant', 'tenancy', 'workspace', 'cpln', 'multi-tenant', 'globally u ## Overview -An organization is a strictly isolated bounded context that encapsulates all the resources managed by Control Plane. These kinds of resources include [domains](/reference/domain), [images](/reference/image), [workloads](/concepts/workload), [GVCs](/reference/gvc), [users](/reference/user), [groups](/reference/group), [service accounts](/reference/serviceaccount), etc. +An organization is a strictly isolated bounded context that encapsulates all the resources managed by Control Plane. These resources include [domains](/reference/domain), [images](/reference/image), [workloads](/concepts/workload), [GVCs](/reference/gvc), [users](/reference/user), [groups](/reference/group), [service accounts](/reference/serviceaccount), etc. -A physical organization (e.g., Acme) can create more than one ‘org’, although it is optional. Reasons for -doing so might be to provide absolute isolation between subsidiaries for example. +A physical organization (e.g., Acme) can create more than one ‘org’, although it is optional. Reasons for doing so might include providing isolation between subsidiaries. -An org name is **globally unique** +An org name must be **globally unique** -As a user of Control Plane, you will be a member of at least one organization and have access to manage the org resources listed below: +As a user of Control Plane, you are a member of at least one organization and have access to manage the org resources listed below: **Click on any of the links below to learn more about each specific resource:** @@ -39,7 +38,7 @@ As a user of Control Plane, you will be a member of at least one organization an ## Cross-GVC Communication -Workloads in different GVCs within the same org can communicate with each other using [internal firewall rules](/reference/workload/firewall#internal). Configure the internal firewall with `same-org` or `workload-list` to allow specific cross-GVC access. +Workloads in different GVCs within the same org can communicate using [internal firewall rules](/reference/workload/firewall#internal). Configure the internal firewall with `same-org` or `workload-list` to allow specific cross-GVC access. ## Reference diff --git a/concepts/workload.mdx b/concepts/workload.mdx index 26928fd7..cd8d2483 100644 --- a/concepts/workload.mdx +++ b/concepts/workload.mdx @@ -6,11 +6,11 @@ keywords: ['microservice', 'app', 'service', 'pod', 'replica', 'serverless', 'st ## Overview -A workload represents a backend application such as a microservice. It is comprised of one or multiple containers. Containers making up the workload communicate freely on localhost. +A workload represents a backend application such as a microservice. It is comprised of one or multiple containers. Containers within a workload communicate freely on localhost. -Workloads run in Control Plane’s AWS, Azure, GCP accounts or in your own [Custom Location](/reference/location#byok-locations) (BYOK), where clouds/regions are determined by the [GVC](/reference/gvc) definition. Your workload may run only in a single region of one cloud, or across many regions of all the three clouds – completely up to the GVC definition. Requests are routed to the nearest healthy location. +Workloads run in Control Plane’s AWS, Azure, GCP accounts, or in your own [Custom Location](/reference/location#byok-locations) (BYOK), where cloud providers and regions are determined by the [GVC](/reference/gvc) definition. Your workload may run in a single region of one cloud, or across many regions of all the three clouds – depending up to the GVC definition. Requests are routed to the nearest healthy location. -Workloads are managed using a common interface, regardless of cloud providers. Workload log data is consolidated for easy retrieval and analysis. It means that a particular workload can be operating on AWS, Azure and GCP, yet its log – across instances/providers is accessed using a single API/CLI/UI/Grafana operation. +Workloads are managed using a common interface, regardless of cloud providers. Workload log data are consolidated for easy retrieval and analysis. This means that a workload can run across AWS, Azure and GCP, yet its log – across instances and providers is accessed using a single API/CLI/UI/Grafana operation. ## Reference For detailed workload configuration options see the [Workload Reference](/reference/workload/general). @@ -28,7 +28,7 @@ For detailed workload configuration options see the [Workload Reference](/refere ## Auto Scaling -The number of workload replicas is automatically scaled up and down based on the workload's scaling strategy. +Workload replicas are automatically scaled up and down based on the selected scaling strategy. Selectable Scaling Strategies: @@ -52,15 +52,15 @@ The minimum and maximum number of replicas that can be deployed are configurable A workload can leverage intelligent allocation of its container's resources (CPU and Memory) by using Capacity AI. -Capacity AI uses an analysis of historical usage to adjust these resources up to a configured maximum. +Capacity AI uses historical usage analysis to adjust these resources up to a configured maximum. This approach can substantially reduce costs; however, it may result in temporary performance issues during sudden spikes in usage. -Before enabling capacity AI on your workload, please read the [Capacity AI reference page](/reference/workload/capacity) +Before enabling capacity AI on your workload, review the [Capacity AI reference page](/reference/workload/capacity) ## Location Override -By default, both [Capacity AI](#capacity-ai) and [Auto Scaling](#auto-scaling) settings are applied to all deployments at each location enabled in the [GVC](/concepts/gvc). However, these settings can be customized at each location to enhance performance for specific audiences. +By default, both [Capacity AI](#capacity-ai) and [Auto Scaling](#auto-scaling) settings are applied to all deployments at each location enabled in the [GVC](/concepts/gvc). However, these settings can be customized per location to enhance performance for specific audiences. This allows for granular control over how your workload scales in specific locations. For instance, if the majority of your users are in Europe, you can set the European locations to a higher level than the rest of the world. @@ -68,7 +68,7 @@ Setting local options ensures that your target users are served quickly and help ## Probes -Probes are a feature of Kubernetes that are used to control the health of an application running inside a container. +Probes are a Kubernetes feature that are used to monitor the health of an application running in a container. Each container can have a: @@ -77,13 +77,13 @@ Each container can have a: - An endpoint is configured to allow queries, enabling you to check if the workload is available and ready to receive requests. - Liveness Probe - - An endpoint is configured to allow queries, enabling you to check if the workload is healthy or if it needs to be restarted. + - An endpoint is configured to allow queries, enabling you to check if the workload is healthy or needs to be restarted. ## Alerts Using Grafana, you can create alerts on any of the standard metrics exposed by Control Plane, or on your [custom metrics](/reference/workload#metrics). To access Grafana, navigate to one of your orgs in the Control Plane console and click the "Metrics" link. -You have the full capability of Grafana alerting at your disposal. For more information, please consult [the Grafana documentation](https://grafana.com/docs/grafana/latest/alerting/) +You have full access to Grafana alerting capabilities. For more information, see the [the Grafana documentation](https://grafana.com/docs/grafana/latest/alerting/) ## Reference diff --git a/core/accessing-cloud-resources.mdx b/core/accessing-cloud-resources.mdx index 9818ddee..f6a624e3 100644 --- a/core/accessing-cloud-resources.mdx +++ b/core/accessing-cloud-resources.mdx @@ -10,21 +10,21 @@ The Control Plane platform enables your [workloads](/reference/workload), regard This capability is **optional**. -This feature alleviates various aspects of credential management. By leveraging this capability, running workloads becomes more straightforward. Cloud providers refer to this as "temporary session credentials." For more information, see how AWS uses temporary credentials in this [link](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). +This feature simplifies credential management by allowing workloads to obtain temporary credentials dynamically instead of relying on embedded secrets. Cloud providers refer to this as "temporary session credentials." For more information, see how AWS uses temporary credentials in this [link](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). Customers choosing to define fine-grained access that allows a [workload](/reference/workload) to access cloud resources must perform the following: -- Register with Control Plane a [cloud account](/reference/cloudaccount) for each cloud provider (AWS, Azure, or GCP) that hosts the resources your workload requires. -- Create an [identity](/reference/identity) and assign the desired [cloud access](/guides/create-identity#cloud-access) to resources within each registered [cloud account](/reference/cloudaccount). -- Assign the [identity](/reference/identity) to a [workload](/reference/workload). Only one identity can be assigned to a particular workload. [Identities](/reference/identity) can be re-used by multiple workloads and have the same set of permissions. +- Register a [cloud account](/reference/cloudaccount) with Control Plane for each cloud provider (AWS, Azure, or GCP) that hosts the resources your workload requires. +- Create an [identity](/reference/identity) and assign the desired [cloud access](/guides/create-identity#cloud-access) permissions to resources within each registered [cloud account](/reference/cloudaccount). +- Assign the [identity](/reference/identity) to a [workload](/reference/workload). Each workload can have only one assigned identity. [Identities](/reference/identity) can be re-used by multiple workloads that require the same permissions. -For Control Plane to provision and de-provision the [identity's](/reference/identity) access to consume native cloud services, Control Plane must be able to: +For Control Plane to provision and revoke the [identity's](/reference/identity) access to consume native cloud services, Control Plane must be able to: - Create `Roles` in AWS - Create `App registrations` in Azure - Create `Service Accounts` in GCP -For additional details on this process, refer to the [cloud account](/reference/cloudaccount) reference page for each cloud provider: +For additional detail, refer to the [cloud account](/reference/cloudaccount) reference page for each cloud provider: - [AWS](/reference/cloudaccount#aws-details) - [Azure](/reference/cloudaccount#azure-details) diff --git a/core/audittrail.mdx b/core/audittrail.mdx index 82b22cee..0302c88a 100644 --- a/core/audittrail.mdx +++ b/core/audittrail.mdx @@ -6,15 +6,15 @@ keywords: ['event log', 'compliance log', 'who did what', 'change history', 'act ## Overview -Control Plane exposes a tamper-proof audit trail service for both Control Plane and custom workload actions. A [UI](#audit-trail-ui) is available to search, filter, and view the actions. +Control Plane provides a tamper-proof audit trail for both Control Plane and custom workload actions. A [UI](#audit-trail-ui) is available to search, filter, and view these events. -Each action that occurs on the Control Plane UI console or [CLI](/cli-reference/overview) is reliably captured, securely stored, and indexed using the audit trail. When using the Control Plane UI console, most resources have an audit trail link that will redirect to the audit trail page with the resource ID prefilled. Additional filters can be added to drill-down to specific events. +Each action performed in the Control Plane UI console or via the [CLI](/cli-reference/overview) is captured, securely stored, and indexed using the audit trail. In the UI, most resources include an audit trail link that will redirect to the audit trail page with the resource ID prefilled. Additional filters can be added to drill-down to specific events. -Your custom workloads can leverage this robust audit trail service without having to build your own. Please refer to [custom workloads](#custom-workloads) for additional details. +Custom workloads can use the audit trail service without needing to build their own solution. Please refer to [custom workloads](#custom-workloads) for additional details. ## Audit Trail UI -The audit trail UI displays the details of each action that has been captured. +The audit trail UI displays details for each captured event. Each action contains: @@ -25,7 +25,7 @@ Each action contains: - Results - Message - Subject (the user that acted) -- Link to display the raw JSON of the events +- Link to view raw JSON for the event The actions displayed can be filtered by: @@ -45,18 +45,18 @@ Below is a sample of the audit trail UI after executing a query showing all acti ## Custom Workloads -The architecture of the audit trail is generic and allows any [workload](/concepts/workload) to capture any action securely and reliably. +The audit trail architecture is generic and allows any [workload](/concepts/workload) to securely and reliably capture events. -For your [workload](/concepts/workload) to use the audit trail, it must first create an [audit context](/reference/auditctx). Refer to the [audit context](/reference/auditctx) reference page for additional details. +For a [workload](/concepts/workload) to use the audit trail, it must first create an [audit context](/reference/auditctx). Refer to the [audit context](/reference/auditctx) reference page for additional details. -**COMING SOON**: Detailed instructions on how your workload can use the audit trail service. +**COMING SOON**: Detailed instructions for using the audit trail service in workloads. ### View Custom Audit Trail To view the actions that have been captured by your workload, you can use: -- The Control Plane Audit Trail UI: - - Within the UI, you can select the [audit context](/reference/auditctx) and only view those actions. -- The Control Plane audit API: +- Control Plane Audit Trail UI: + - You can select an [audit context](/reference/auditctx) to only view those actions. +- Control Plane audit API: - Leveraging the API, you can create a custom UI to display the audit data. - View the [Audit API OpenAPI spec](https://audit.cpln.io/openapi.json) to review the audit schema and available methods. diff --git a/core/authentication.mdx b/core/authentication.mdx index 507e0207..e7100122 100644 --- a/core/authentication.mdx +++ b/core/authentication.mdx @@ -10,7 +10,7 @@ Control Plane supports multiple authentication methods depending on how you acce ## Console UI -The Console uses single sign-on (SSO) for user authentication with the following providers: +The Console supports single sign-on (SSO) for user authentication with the following providers: @@ -42,23 +42,23 @@ The CLI supports two authentication methods: - For interactive use, run the login command which opens your browser for SSO authentication: + For interactive use, run the login command, which opens your browser for SSO authentication: ```bash cpln login ``` - This creates a default profile with your credentials. + This creates a default profile for your credentials. For CI/CD pipelines and automation, use a service account token: ```bash - # Create a profile with a service account token + # Create a profile using a service account token cpln profile create PROFILE_NAME --org ORG_NAME --token TOKEN --default ``` - The `--default` flag makes this profile active for all future commands. + The `--default` flag sets this profile active for all future commands. You can also use the `CPLN_TOKEN` environment variable: @@ -100,7 +100,7 @@ export CPLN_TOKEN=your-service-account-token ## Pulumi -Configure authentication using Pulumi config or environment variables: +Configure authentication using either Pulumi config or environment variables: @@ -145,7 +145,7 @@ Tokens can be obtained from: ## Service Accounts -For programmatic access (CI/CD, automation, IaC), create a [service account](/reference/serviceaccount) and generate a key: +For programmatic access (CI/CD, automation, and IaC), create a [service account](/reference/serviceaccount) and generate a key: @@ -159,11 +159,11 @@ For programmatic access (CI/CD, automation, IaC), create a [service account](/re cpln serviceaccount add-key my-service-account --org my-org ``` - The key is displayed only once. Save it immediately in a secure location. + The key is shown only once. Save it immediately in a secure location. - Add the service account to a [group](/reference/group) or create a [policy](/reference/policy) granting it the necessary permissions. + Add the service account to a [group](/reference/group) or create a [policy](/reference/policy) that grants the necessary permissions. Use the generated key as your token in the CLI, Terraform, Pulumi, or API requests. diff --git a/core/kubernetes-operator.mdx b/core/kubernetes-operator.mdx index 6cf50aa7..53b1f664 100644 --- a/core/kubernetes-operator.mdx +++ b/core/kubernetes-operator.mdx @@ -57,7 +57,7 @@ The operator manages the following Control Plane resource types through CRDs: # ... ``` - Always use the [export feature](#exporting-resources-as-crds) to generate accurate manifests. + Always use the [export feature](#exporting-resources-as-crds) to generate accurate CRD manifests. @@ -144,7 +144,7 @@ kubectl apply -f gvc.yaml kubectl apply -f workload.yaml ``` -The operator watches for CRD changes and syncs them to Control Plane automatically. You can organize resources by namespace: +The operator watches for CRD changes and synchronizes them to Control Plane automatically. You can organize resources by namespace: - **One namespace per GVC** for GVC-scoped resources (workloads, identities, volumesets) - **One namespace per org** for org-scoped resources (GVCs, secrets, policies) diff --git a/core/logs.mdx b/core/logs.mdx index addbf919..6164b1f4 100644 --- a/core/logs.mdx +++ b/core/logs.mdx @@ -6,11 +6,11 @@ keywords: ['loki', 'log aggregation', 'tail', 'observability', 'log search', 'li ## Overview -The logs UI displays the logs for your running [workloads](/concepts/workload). No matter which combination of cloud providers or regions your workload is running at, the logs will be aggregated and displayed as if they were running at one provider/region. +The Logs UI aggregates and displays logs for running [workloads](/concepts/workload) across all configured cloud providers and regions and the logs will be aggregated and displayed as if they were running at one provider/region. -[Filters](#log-filters) can be applied to pinpoint any issues that might be occurring at a specific [workload](/concepts/workload). +Use [filters](#log-filters) to narrow any issues that might be occurring at a specific [workload](/concepts/workload). -The [Grafana](https://grafana.com/grafana/) explorer is available to query and visualize your log data. +The [Grafana](https://grafana.com/grafana/) explorer can be used to query, visualize, and analyze log data. ## LogQL @@ -18,7 +18,7 @@ The Control Plane logs use the LogQL query language to query your log data. The documentation for LogQL is available in the [LogQL documentation](https://grafana.com/docs/loki/latest/logql/). -The available labels that can be used to create a query are: +The following labels that can be used to create a query are: - container - gvc @@ -29,21 +29,21 @@ The available labels that can be used to create a query are: ## Log Filters -The results of a query can be filtered by the following: +Query results can be filtered by the following: - [Location](/reference/location) - [Container](/reference/workload/containers) - Start date and optional end date (the date/time selector includes helper buttons ranging from the `Last 5 minutes` to the `Last 30 days`) -Selecting a [location](/reference/location) or [container](/reference/workload/containers) will automatically add the value to the LogQL query. +Selecting a [location](/reference/location) or [container](/reference/workload/containers) automatically add the value to the LogQL query. ## Live Logs -The results of the given query can be streamed in real-time using the `Live` button. +Log streams can be viewed in real time using the `Live` option. -After entering the desired query, click the `Live` button. +After entering the desired query, click `Live` to begin streaming logs. -To end the live streaming, click the `Stop` button. +Click `Stop` to end the live stream. ## Grafana @@ -91,7 +91,7 @@ sum(count_over_time({gvc="GVC_NAME", container="_accesslog"} |= "\" 50"[1m])) b {gvc="GVC_NAME", workload="WORKLOAD_NAME", location="aws-eu-central-1", container="CONTAINER_NAME"} ``` -- View all logs (will contain all workloads logs across all gvcs) +- View logs across all workloads and GVCs ```log Query {gvc=~".+"} @@ -99,8 +99,8 @@ sum(count_over_time({gvc="GVC_NAME", container="_accesslog"} |= "\" 50"[1m])) b - Count of inbound requests by ip -This query will produce a count of inbound requests by source ip address for the last 10 minutes. -You must set the grafana query options to type `Instant` so that a list is produced and can be sorted. +This query will produce a count of inbound requests grouped by source ip address over the last 10 minutes. +Set the Grafana query type to `Instant` so the results can be returned as a sortable list. ```log Query sum(count_over_time({gvc="GVC_NAME", workload="WORKLOAD_NAME", container="_accesslog"} | logfmt | regexp "(?P\\d+\\.\\d+\\.\\d+\\.\\d+)"[10m])) by (ip) @@ -108,8 +108,8 @@ sum(count_over_time({gvc="GVC_NAME", workload="WORKLOAD_NAME", container="_acces - Count of inbound requests by path -This query will produce a count of inbound requests by request path for the last 10 minutes with a latency greater than 100ms. -You must set the grafana query options to type `Instant` so that a list is produced and can be sorted. +This query returns the count of inbound requests grouped by request path for the last 10 minutes where latency exceeds 100ms. +Set the Grafana query type to `Instant` so the results can be returned as a sortable list. ```log Query @@ -119,7 +119,7 @@ sum(count_over_time({gvc="GVC_NAME", workload="WORKLOAD_NAME", container="_acces ## Log Retention Policy -The log retention period for logs stored at Control Plane is 30 days by default and can be adjusted for each Org. +The log retention period for logs stored for 30 days by default and can be adjusted for each Org. Learn how to [configure log shipping to an external provider](/external-logging/overview). diff --git a/core/misc.mdx b/core/misc.mdx index 26bf2ad9..122196db 100644 --- a/core/misc.mdx +++ b/core/misc.mdx @@ -12,18 +12,18 @@ Alerts can be created from the Org's Grafana instance. Refer to these [instructi Most Control Plane resources can be labeled with multiple key-value pairs called tags. -These tags can be used by the UI or other resource to query / filter / select a resource based on its keys and value. +Tags can be used throughout the UI and by other resources to query, filter, and select resources based on tag keys and values. -A majority of resources will have a `Query` button that will show a modal allowing you to filter the resources shown. +Most resources include a `Query` option that opens a modal allowing you to filter the resources shown. -[Group](/reference/group) and [policy](/reference/policy) can use a query to dynamically assign members and resources, respectively. +[Groups](/reference/group) and [policies](/reference/policy) can use tag queries to dynamically assign members and resources. The `Match Tags By` selector values are: | Selector | Definition | | :------- | :------------------------------ | -| All | All tag items should match | -| Any | Any of the tags should match | +| All | All tag items must match | +| Any | At least one tag must match | | None | None of these tags should match | To filter resources based on their tags: @@ -32,6 +32,6 @@ To filter resources based on their tags: 2. Select the wanted match tag selector 3. Enter a tag name, equality operator, and value. Click `Add`. 4. Enter any additional tags -5. Click `Apply` and the filtered resources will be displayed +5. Click `Apply` to display the filtered resources. To remove the filter, click on the `Query` button again and click `Clear`. diff --git a/core/query.mdx b/core/query.mdx index 7a9e0b0d..9b3db664 100644 --- a/core/query.mdx +++ b/core/query.mdx @@ -4,11 +4,11 @@ description: "Filter and select resources using tags, properties, and relations. keywords: ['cpln query', 'tag query', 'rel', 'expression', 'selector', 'match all', 'match any', 'sort order', 'list filter', 'item filter', 'where', 'predicate'] --- -Clients and items can select/filter other items with the help of queries. Queries utilize [tags](/core/misc#tags), `properties` of an item or the `relations` of it to execute. +Queries allow clients and resources to filter and select other resources using [tags](/core/misc#tags), `properties` of an item or the `relations` of it to execute. -Query is also used for sorting items when fetching a list of items, by any property and by ascending or descending order. +Queries also support sorting resource lists by property in ascending or descending order. -Some examples of items that use queries: +Examples of resources that use queries include: - [Group](/reference/group) can dynamically assign users - [Policy](/reference/policy) can target items or principals with queries @@ -18,9 +18,9 @@ Some examples of items that use queries: ## Filtering -A query consists of terms, each term can target tags, properties or relations (`rel`). +A query consists of one or more terms that target tags, properties, or relations (`rel`). -For `rel` term, the value depends on the kind. For example, workload has `gvc` rel, which allows you to filter workloads in an org by the GVC they belong to. +For `rel` term, the value depends on the resource kind. For example, workload has `gvc` rel, which allows you to filter workloads in an org by the GVC they belong to. diff --git a/core/security.mdx b/core/security.mdx index c8b74a47..87ef501e 100644 --- a/core/security.mdx +++ b/core/security.mdx @@ -15,15 +15,15 @@ Access to the Control Plane console or CLI is granted by authenticating using si - Microsoft - Security Assertion Markup Language (SAML) -For your chosen provider, Multi-Factor Authentication (MFA) is recommended. +Multi-Factor Authentication (MFA) is recommended for your chosen provider. ### Service Accounts -Access to the Control Plane CLI using a [Service Account](/reference/serviceaccount) is granted by the use of a generated token. During the token generation, the token can be copied to the clipboard or downloaded. Once the token modal is dismissed, the token will no longer be available for display or retrieval. If the token is lost or compromised, it must be regenerated. +Access to the Control Plane CLI using a [Service Account](/reference/serviceaccount) is granted through the use of a generated token. During token generation, the token can be copied to the clipboard or downloaded. Once the token modal is dismissed, the token will no longer be available for display or retrieval. If the token is lost or compromised, it must be regenerated. ### Authorization -Authorization to all Control Plane resources is controlled using fine-grained authorization policies assigned to the following principal types: +Authorization for all Control Plane resources is controlled using fine-grained policies assigned to the following principal types: - [Users](/reference/user) - [Groups](/reference/group) @@ -34,7 +34,7 @@ Authorization to all Control Plane resources is controlled using fine-grained au ### External Certificates -All communications from external sources use end-to-end TLS to the destination Workloads. +All communications from external sources use end-to-end TLS to destination Workloads. The server certificates are generated by [Let's Encrypt](https://letsencrypt.org) and are rotated every 60 days. @@ -59,7 +59,7 @@ Workload client certificates are rotated every hour and utilize TLSv1.2 with the ## Firewall Security -Control Plane uses industry-standard firewall technology. All workloads are configured to be fully restricted with no internal or external communication enabled by default, except for internal health check monitoring. +Control Plane uses industry-standard firewall technologies. All workloads are configured to be fully restricted with no internal or external communication enabled by default, except for internal health check monitoring. ### External Firewall @@ -94,7 +94,7 @@ Network resource access via [agents](/reference/agent) (configured within a [wor ## GVC Isolation -Every workload receives discovery information for other workloads across the org but communication is disabled by default using firewalls and client certificate validation. +Every workload receives discovery information for other workloads across the org, but communication is disabled by default using firewalls and client certificate validation. ## Workload Isolation @@ -104,7 +104,7 @@ All workloads are isolated at the org level based on the use of: - Client Certificates - Proxies -Direct communications between containers residing in other orgs are not possible, external endpoints can be used to communicate with workloads in other orgs. Isolation between workloads within an org is defined based on the workloads' internal firewall configuration. +Direct communication between containers residing in different orgs is not possible. External endpoints can be used to communicate with workloads in other orgs. Isolation between workloads within an org is defined based on the workloads' internal firewall configuration. ## Container Isolation @@ -120,7 +120,7 @@ Containers are isolated by the use of: The following headers are sanitized and replaced with valid content before being forwarded to running workloads: - x-envoy-external-address - - Used to verify the source address of the external requestee. + - Used to verify the source address of the external requester. - x-forwarded-client-cert - Used to verify that communications between workloads were made using mTLS and to verify the identity of the requesting workload. - x-forwarded-for @@ -176,7 +176,7 @@ Retention settings for logs, metrics and traces can be adjusted on the [org](/re ### Secrets -Org-level secrets are encrypted at rest using envelope encryption and use TLS while in transit. Secrets are stored on multiple cloud providers using cloud-based Hardware Security Modules (HSM). +Org-level secrets are encrypted at rest using envelope encryption and protected with TLS while in transit. Secrets are stored on multiple cloud providers using cloud-based Hardware Security Modules (HSM). ## Platform Security @@ -186,7 +186,7 @@ Security updates and patches are applied regularly and meet all compliance and r For zero-day vulnerabilities, updates are applied as soon as they are available and verified. -All scheduled maintenance that could cause downtime will be communicated via email and Discord. +All scheduled maintenance that could cause downtime is communicated via email and Discord. If you find any security issues, or have any security questions, please email [secops@controlplane.com](mailto:secops@controlplane.com). @@ -214,7 +214,7 @@ Each provider complies with the following: ## Platform Privacy -Control Plane is committed to customer privacy. For details, see the [Privacy Policy](https://controlplane.com/privacy-policy). +Control Plane is committed to protecting customer privacy. For details, see the [Privacy Policy](https://controlplane.com/privacy-policy). Support staff has access to the following: diff --git a/core/terms.mdx b/core/terms.mdx index 0c71d417..2fae202f 100644 --- a/core/terms.mdx +++ b/core/terms.mdx @@ -8,7 +8,7 @@ keywords: ['glossary', 'definitions', 'terminology', 'selflink', 'self link', 'f Each object in Control Plane Platform belongs to a kind. These are the fundamental pieces you will create, manage and design the relationship between, such as `Workload`, `VolumeSet`, `Agent`, `Service Account` and more. -Each instance of a kind is referred to as `item` in the platform. Our API drives all of the other clients (`Terraform Provider`, `Pulumi Provider`, `UI Console`, `cpln` CLI) and when a request is made to our API, it will usually act on a single item or multiple items (`instances of a kind`). +Each instance of a kind is referred to as an `item` in the platform. Our API drives all of the other clients (`Terraform Provider`, `Pulumi Provider`, `UI Console`, `cpln` CLI) and when a request is made to our API, it will usually act on a single item or multiple items (`instances of a kind`). ## Context @@ -18,9 +18,9 @@ Some kinds are scoped to a gvc, while others are scoped to an org. `Workload`, ` ## Links -Each `item` is accessible by its link. This is a url/address for the `item` and is an essential part of the platform. There are two ways to structure the link of an item, which is called a `selfLink`. These types are `fullLink` and `relativeLink`. When a kind is scoped to a gvc, its relative link must include gvc name. +Each `item` is accessible by its link. This is a url/address for the `item` and is an essential part of the platform. There are two ways to structure an item link, which is called a `selfLink`. These types are `fullLink` and `relativeLink`. When a kind is scoped to a gvc, its relative link must include gvc name. -Relative link relies on the `context` set in the client that is being used. +A relative link relies on the `context` set in the client being used. See examples for different possibilities such as gvc or org scoped items. @@ -33,7 +33,7 @@ See examples for different possibilities such as gvc or org scoped items. ## Clients -There are multiple ways to use the platform, which are our `clients`. Such as the UI Console, Control Plane API, `cpln` CLI, Terraform Provider Plugin, Pulumi. +There are multiple ways to use the platform, referred to as `clients`. Examples include the UI Console, Control Plane API, `cpln` CLI, Terraform Provider Plugin, Pulumi. ## Containers @@ -51,7 +51,7 @@ You can find the built-in alert rules in your Grafana instance under `Alerts` > - `container-restarts` - - This alert triggers if any of your workloads restart repeatedly. Specifically, it activates if the Control Plane custom metric `container_restarts` is greater than 1 in the last 5 minutes. + - This alert triggers if any of your workloads restart repeatedly. Specifically, it activates if the Control Plane custom metric `container_restarts` exceeds 1 within a 5 minute period. - `stuck-deployments` @@ -71,18 +71,18 @@ The list of public IPs for each cloud provider and region can be obtained. Navigate to `Locations` list page from the main navigation bar. - Select a location and you will see the ip ranges are listed in the `info` page. + Select a location to view the IP ranges listed on the `info` page. - Use the command below to view ip ranges of all locations. + Use the command below to view the ip ranges of all locations. ```bash cpln location get -o json ``` - The output can also be formatted in YAML by using the flag `-o yaml` instead of `-o json` + The output can also be formatted as YAML by using the flag `-o yaml` instead of `-o json` - To view a single location, use the command below by replacing the `{locationName}` with a correct value. + To view a single location, replace `{locationName}` with a valid location name in the command below. ```bash cpln location get {locationName} -o json @@ -92,7 +92,7 @@ The list of public IPs for each cloud provider and region can be obtained. - Location list endpoint or location specific endpoint returns the location object with `ipRanges` property. + The location list endpoint and location-specific endpoint return the location object with `ipRanges` property. See the [Get All Locations API endpoint](/api-reference/location/get-all-locations) for details. @@ -101,7 +101,7 @@ The list of public IPs for each cloud provider and region can be obtained. -The list of IPs may be required by external services that restrict the IPs allowed to call them. +The list of IPs may be required by external services that restrict which IPs are allowed to access them. The IPs may change when underlying infrastructure changes. Therefore, Control Plane recommends the automation of querying the location API for changes. In case of changes, the automation should re-configure external services’ allowed IP address list. @@ -110,4 +110,4 @@ The IPs may change when underlying infrastructure changes. Therefore, Control Pl ## Workload Deployment Errors - `Error: exitCode: 1 message: standard_init_linux.go:228: exec user process caused: exec format error` - - The incorrect platform was used to build the configured image. Control Plane requires the image target `amd64`. Refer to the [Push an Image Guide](/guides/push-image#step-2-build-a-new-image-using-docker-and-a-dockerfile-optional) for additional details. + - The configured image was built for the incorrect platform. Control Plane requires the image target `amd64`. Refer to the [Push an Image Guide](/guides/push-image#step-2-build-a-new-image-using-docker-and-a-dockerfile-optional) for additional details. diff --git a/introduction.mdx b/introduction.mdx index f648f24a..eaf67331 100644 --- a/introduction.mdx +++ b/introduction.mdx @@ -10,7 +10,7 @@ keywords: ['home', 'docs', 'getting started', 'overview', 'multi-cloud', 'multic Control Plane -Control Plane is a hybrid platform that enables you to deploy and manage workloads across AWS, GCP, Azure, and private clouds from a single, unified interface. Build resilient, multi-cloud applications without vendor lock-in. +Control Plane is a hybrid platform that enables you to deploy and manage workloads across AWS, GCP, Azure, and private clouds from a single interface. Build resilient, multi-cloud applications without vendor lock-in. @@ -22,7 +22,7 @@ Control Plane is a hybrid platform that enables you to deploy and manage workloa - SOC 2 Type II, HIPAA, & and more + SOC 2 Type II, HIPAA, and more diff --git a/quickstart/quick-start-1-deploy-workload.mdx b/quickstart/quick-start-1-deploy-workload.mdx index defb9ee4..149f54ba 100644 --- a/quickstart/quick-start-1-deploy-workload.mdx +++ b/quickstart/quick-start-1-deploy-workload.mdx @@ -10,7 +10,7 @@ This quickstart guides you through deploying your first application on Control P **What you'll accomplish:** -- Create a GVC spanning multiple cloud providers and locations +- Create a GVC across AWS and GCP regions - Deploy a sample web application as a Workload - Access your application via a TLS-secured, geo-routed global endpoint @@ -44,7 +44,7 @@ Enter a name for your GVC (e.g., `quickstart-gvc`). -Click `Locations` in the left menu. Choose the locations where your workload will be deployed. For this quickstart, select: +Click `Locations` in the left pane. Choose the locations where your workload will be deployed. For this quickstart, select: - `aws-us-west-2` - `gcp-us-east1` @@ -53,7 +53,7 @@ This deploys your application across both AWS and GCP. -Click `Create`. The GVC summary page will be displayed. +Click `Create`. You can click `Set as Current Context` to make this GVC your current context. This allows you to browse its workloads, identities, and volumesets from the sidebar. @@ -69,11 +69,11 @@ Click `Workloads` in the left menu, then click `New`. -Enter a name (e.g., `hello-world`). Ensure the GVC dropdown under the description field has `quickstart-gvc` selected. +Enter a name (e.g., `hello-world`). Make sure the GVC dropdown under the description field has `quickstart-gvc` selected. -Click `Containers` in the left menu. For the image source, select `External`, then enter: +Click `Containers` in the left pane. For the image source, select `External`, then enter: ```text gcr.io/knative-samples/helloworld-go @@ -85,7 +85,7 @@ Under `Ports`, ensure there is a port configured with: -Click `Firewall` in the left menu, then click the `Make Public` button at the top to allow external access. +Click `Firewall` in the left pane, then click the `Make Public` button at the top to allow external access. @@ -107,7 +107,7 @@ Under `Endpoints`, click the link next to `Canonical Endpoint`. Your application -Click `Deployments` in the left menu to see each location's endpoint. Click `Open` next to any location to access that specific deployment. +Click `Deployments` in the left pane to see each location's endpoint. Click `Open` next to any location to access that specific deployment. @@ -266,7 +266,7 @@ For CI/CD pipelines or environments without the CLI, create a service account to 1. In the [Console](https://console.cpln.io), click `Service Accounts` in the left menu, then `New` 2. Enter a name (e.g., `terraform-sa`), select `superusers` from the Assign to Group dropdown, and click `Create`. You'll be navigated to the service account summary page. -3. Click the `Keys` link, add a description, and click `Add` +3. Click the `Keys` in the left pane, add a description, and click `Add` 4. **Copy the generated key** - it won't be shown again Set the token as an environment variable: @@ -453,7 +453,7 @@ For CI/CD pipelines or environments without the CLI, create a service account to 1. In the [Console](https://console.cpln.io), click `Service Accounts` in the left menu, then `New` 2. Enter a name (e.g., `pulumi-sa`), select `superusers` from the Assign to Group dropdown, and click `Create`. You'll be navigated to the service account summary page. -3. Click the `Keys` link, add a description, and click `Add` +3. Click the `Keys` in the left pane, add a description, and click `Add` 4. **Copy the generated key** - it won't be shown again Set the token as an environment variable: diff --git a/quickstart/quick-start-2-deploy-application.mdx b/quickstart/quick-start-2-deploy-application.mdx index 378e4173..48f8f00b 100644 --- a/quickstart/quick-start-2-deploy-application.mdx +++ b/quickstart/quick-start-2-deploy-application.mdx @@ -6,7 +6,7 @@ keywords: ['tutorial', 'walkthrough', 'getting started', 'cli install', 'buildpa ## Overview -This quickstart guides you through building and deploying your own application to Control Plane. You'll containerize a sample Node.js application, push it to your org's private image registry at Control Plane, and deploy it as a workload. +This quickstart guides you through building and deploying your own application to Control Plane. You'll containerize a sample Node.js application, push it to your org's private image registry on Control Plane, and deploy it as a workload. **What you'll accomplish:** @@ -62,7 +62,7 @@ Log in to Control Plane: cpln login ``` -This opens your browser for authentication. After successful login, set your default organization: +This opens your browser to authenticate. After successful login, set your default organization: ```bash cpln profile update default --org YOUR_ORG_NAME @@ -96,7 +96,7 @@ Expand-Archive cpln_app.zip && cd cpln_app -The application is a web app that displays the environment variables of the running process, including Control Plane variables such as cloud provider and location. +The application is a web app that displays runtime environment variables, including Control Plane injected variables such as cloud provider and location. ## Step 4: Build and Push the Image @@ -112,7 +112,7 @@ The `cpln image build` command uses [Buildpacks](https://buildpacks.io) to autom -The image is now available in your organization's private registry at `//image/my-app:1.0`. +The image is now available in your organization's private registry as `//image/my-app:1.0`. @@ -151,11 +151,11 @@ Click `Workloads` in the left menu, then click `New`. -The workload shows `Ready` in Workload Health (1-2 minutes). +The workload status changes to show `Ready` under Health (1-2 minutes). -Click `Open` next to the Canonical Endpoint. Your application displays the Control Plane environment variables including the location and provider. +Under `Endpoints`, click the link next to `Canonical Endpoint`. Your application displays the Control Plane environment variables including the location and provider. @@ -178,7 +178,7 @@ cpln workload create --name my-app \ -The `//image/` prefix tells Control Plane to pull from your organization's private registry. +The `//image/` prefix tells Control Plane to pull the image from your organization's private registry. @@ -488,7 +488,7 @@ pulumi stack output ## Updating Your Application -To deploy a new version, update your code and build with a new tag: +To deploy a new version, update your code and build with a new image tag: ```bash cpln image build --name my-app:1.1 --push diff --git a/quickstart/quick-start-3-custom-domain.mdx b/quickstart/quick-start-3-custom-domain.mdx index ce40bc22..e48709b9 100644 --- a/quickstart/quick-start-3-custom-domain.mdx +++ b/quickstart/quick-start-3-custom-domain.mdx @@ -21,7 +21,7 @@ This quickstart guides you through configuring a custom domain for your workload -This quickstart uses `example.com` as a sample domain. Replace it with your own domain throughout the guide. +This quickstart uses `example.com` as an example domain. Replace it with your own domain throughout the guide. @@ -42,7 +42,7 @@ Click `Domains` in the left menu, then click `New`. Click `Advanced`, then enter -You'll be prompted to prove ownership by adding a TXT record to your DNS. Add the displayed TXT record to your DNS provider and wait a few minutes for propagation. +You'll be prompted to verify ownership by adding a TXT record to your DNS. Add the displayed TXT record to your DNS provider and wait a few minutes for propagation. @@ -83,7 +83,7 @@ Once the DNS record is configured, click `Create`. -Control Plane automatically provisions TLS certificates once DNS propagates and your workload is ready. This may take a few minutes. +Control Plane automatically provisions TLS certificates after the DNS propagates and your workload is ready. This may take a few minutes. @@ -103,7 +103,7 @@ First, attempt to create the apex domain: cpln domain create --name example.com ``` -The command returns an error with the TXT record you need to add to prove ownership. Add one of the displayed TXT records to your DNS provider and wait a few minutes for propagation, then run the command again: +The command returns an error with the TXT record you need to add to verify ownership. Add one of the displayed TXT records to your DNS provider and wait a few minutes for propagation, then run the command again: ```bash cpln domain create --name example.com @@ -142,7 +142,7 @@ Get the GVC alias: cpln gvc get quickstart-gvc -o yaml ``` -Look for the `alias` field in the output: +Find the `alias` field in the output: ```yaml alias: abc123xyz @@ -166,7 +166,7 @@ After DNS propagates, access your application at `https://app.example.com`. ## Step 1: Define the Apex Domain -Add to your `main.tf` to verify domain ownership: +Add the following to your `main.tf` to verify domain ownership: ```hcl resource "cpln_domain" "apex" { @@ -186,7 +186,7 @@ resource "cpln_domain" "apex" { } ``` -Apply the configuration to see the TXT records you need to add to your DNS: +Apply the configuration to retrieve the TXT records you need to add to your DNS: ```bash terraform apply @@ -196,7 +196,7 @@ The output contains the TXT record you need to add to your DNS provider to prove ## Step 2: Define the Subdomain and Route -Add the subdomain and route configuration: +Add the subdomain and routing configuration: ```hcl resource "cpln_domain" "app" { @@ -363,7 +363,7 @@ var apexDomain = new Domain("apex-domain", new DomainArgs -Deploy the configuration to see the TXT records you need to add to your DNS: +Deploy the configuration to retrieve the TXT records you need to add to your DNS: ```bash pulumi up @@ -578,7 +578,7 @@ Route different paths to different workloads: -Each workload gets its own subdomain automatically: +Each workload automatically receives its own subdomain: - `https://api.app.example.com` → API workload - `https://web.app.example.com` → Frontend workload @@ -591,10 +591,10 @@ Requires NS record delegation to Control Plane. ## What's Configured -Your domain now provides: +Your domain is now configured with: - **Automatic TLS** - Certificates provisioned and renewed automatically -- **Global load balancing** - Traffic routed to the nearest healthy location +- **Global load balancing** - Traffic is routed to the nearest healthy location - **Path-based routing** - Multiple workloads can share the same domain ## Continue diff --git a/quickstart/quick-start-4-service-to-service.mdx b/quickstart/quick-start-4-service-to-service.mdx index 99c65592..8bb0db35 100644 --- a/quickstart/quick-start-4-service-to-service.mdx +++ b/quickstart/quick-start-4-service-to-service.mdx @@ -1,19 +1,19 @@ --- title: 4. Service-to-Service Communication -description: Configure internal firewall rules to enable secure service-to-service communication between workloads with automatic mTLS encryption. +description: Configure internal firewall rules to enable secure service-to-service communication between workloads using automatic mTLS encryption. keywords: ['east-west', 'internal traffic', 'cpln.local', 'private endpoint', 'inter-workload', 'service mesh', 'zero trust', 'tutorial', 'walkthrough', 'workload to workload'] --- ## Overview -This quickstart demonstrates how workloads communicate internally with automatic mTLS encryption. By default, workloads are isolated and reject internal traffic. You'll configure firewall rules to enable secure service-to-service calls. +This quickstart demonstrates how workloads communicate internally with automatic mTLS encryption. By default, workloads are isolated and reject internal traffic. You'll configure firewall rules to enable secure service-to-service communication. **What you'll accomplish:** -- Deploy a new workload that calls an existing service +- Deploy a new workload that communicates an existing service - Observe the default deny behavior - Configure internal firewall rules to allow communication -- Verify secure service-to-service calls +- Verify secure service-to-service communication ## Prerequisites @@ -22,13 +22,13 @@ This quickstart demonstrates how workloads communicate internally with automatic ## How Internal Communication Works -Workloads communicate using internal endpoints following this pattern: +Workloads communicate using internal endpoints that follow this pattern: ```text http://WORKLOAD_NAME.GVC_NAME.cpln.local:PORT ``` -All internal traffic is automatically encrypted with mTLS. No certificates to manage. +All internal traffic is automatically encrypted with mTLS. No certificate management required. So far, you've created a GVC (`quickstart-gvc`) and deployed a workload (`hello-world`). Now you'll create a new workload that communicates with the existing `hello-world` workload. @@ -108,7 +108,7 @@ Click `Workloads` in the left menu and select `hello-world`. -The `hello-world` workload redeploys with new firewall rules (1-2 minutes). +The `hello-world` workload redeploys with the updated firewall rules (1-2 minutes). @@ -156,7 +156,7 @@ The request will timeout and fail because the `hello-world` workload blocks inte ## Step 3: Enable Internal Access -Update the `hello-world` firewall to allow internal traffic: +Update the `hello-world` firewall configuration to allow internal traffic: ```bash cpln workload update hello-world --gvc quickstart-gvc --set spec.firewallConfig.internal.inboundAllowType=same-gvc @@ -602,7 +602,7 @@ The `workload-list` option requires `view` permission on the allowed workloads. ## Internal Endpoint Format -Workloads communicate using internal DNS: +Workloads communicate using internal DNS endpoints: ```text http://WORKLOAD.GVC.cpln.local:PORT @@ -616,13 +616,13 @@ http://WORKLOAD.GVC.cpln.local:PORT ## What You've Learned - Workloads are **isolated by default** - internal traffic is blocked -- **mTLS is automatic** - no certificate configuration needed -- **Firewall rules** control which workloads can communicate +- **mTLS is automatic** - no certificate configuration required +- **Firewall rules** control which workloads are allowed to communicate - Internal endpoints use the `.cpln.local` domain ## Clean Up -To delete all resources created in the quickstart series: +To delete all resources created through the quickstart series: @@ -670,7 +670,7 @@ Remember to remove the DNS records from your DNS provider after deleting the dom - Deploy your own containerized application to Control Plane. + Deploy your own containerized application on Control Plane. diff --git a/reference/auditctx.mdx b/reference/auditctx.mdx index 157a13d2..a6e7f39f 100644 --- a/reference/auditctx.mdx +++ b/reference/auditctx.mdx @@ -6,22 +6,20 @@ keywords: ['cpln audit', 'audit api', 'event ingestion', 'siem feed', 'complianc ## Overview -Control Plane exposes a tamper-proof audit trail service for both Control Plane and custom workload actions. +Control Plane provides a tamper-proof audit trail service for both Control Plane and custom workload actions. To use this feature, a unique **Audit Context** needs to be created for your workload. -The audit context named `cpln` already exists to audit the actions that occur while using Control Plane. +The `cpln` audit context is pre-provisioned and captures all native Control Plane platform activity. Please refer to the [audit trail](/core/audittrail) reference page for additional details on how to query the audit trail and how to securely capture actions for your workloads. ## Create an Audit Context -Refer to the [Create an Audit Context](/guides/create-audit-context) guide for additional details. +Refer to the [Create an Audit Context](/guides/create-audit-context) guide for setup instructions. ## Permissions - -The permissions below are used to define [policies](/reference/policy) together with one or more of the four -[principal types](/concepts/access-control): +The following permissions can be assigned through [policies](/reference/policy) to supported [principal types](/concepts/access-control): | Permission | Description | Implies | | :--------- | :----------------------- | :------------------------------------------------ | @@ -38,7 +36,7 @@ Displays the permissions granted to principals for the audit context. ## Writing audit records from a workload -1. Make sure the workload is assigned an identity that is granted writeAudit permissions to your custom audit context. +1. Make sure the workload is assigned an identity that is granted writeAudit permissions on the target audit context. 2. Write events using the internal audit endpoint ```bash diff --git a/reference/cloudaccount.mdx b/reference/cloudaccount.mdx index ad6e541b..654ed1fd 100644 --- a/reference/cloudaccount.mdx +++ b/reference/cloudaccount.mdx @@ -6,30 +6,31 @@ keywords: ['bridge account', 'cross-account', 'iam', 'connect aws', 'connect azu ## Overview -A **cloud account** is a mapping between your [org](/reference/org) and a cloud provider. When creating a cloud account, instructions are provided on how to create a bridge account at the cloud provider with minimum access permissions. This bridge account is used by Control Plane to query and manage the necessary resources at the cloud provider on behalf of your [org](/reference/org). +A **cloud account** establishes a secure integration between your [org](/reference/org) and an external cloud provider.When creating a cloud account, you are guided to create a provider-side bridge role or service principal with minimum access permissions. This bridge identity allows Control Plane to securely manage and query cloud resources on behalf of your [org](/reference/org). Cloud accounts are scoped to an [org](/reference/org) and are used in conjunction with [identities](/reference/identity) to set up [cloud access](/reference/identity#cloud-access-universal-cloud-identity) rules. -Your [workload](/concepts/workload) can then be associated with an [identity](/reference/identity) and will then have the ability to call any of the allowed cloud provider resources transparently without any additional set up. +Your [workload](/concepts/workload) can then be associated with an [identity](/reference/identity) and will have access to permitted cloud provider resources without additional configuration. -For example, if your application uses AWS S3 for storage and Azure Cosmos DB for its database, your workload will be able to access both no matter which [location](/reference/location) the workload is deployed to. The [workload](/concepts/workload) calls each resource as if it had a direct connection and the [identity](/reference/identity) will route the request seamlessly to the proper location. +For example, if an application uses AWS S3 for storage and Azure Cosmos DB for its database, a workload can access both services regardless of the [location](/reference/location) in which the workload is deployed to. The [workload](/concepts/workload)interacts with each service as if it were directly connected, while the [identity](/reference/identity) handles secure routing and credential exchange transparently. ## Create a Cloud Account -Refer to the [Create a Cloud Account](/guides/create-cloud-account) guide for additional details. +Refer to the [Create a Cloud Account](/guides/create-cloud-account) guide for setup instructions. ## AWS Details - Cloud Account Creation - - When registering a cloud account targeting AWS, your AWS administrator will manually create a new AWS role (named `cpln-ORG_NAME`) with the following policies: - - Create a new policy named `cpln-connector` which has the necessary access to create and manage roles. - - `ReadOnlyAccess` which "provides read-only access to AWS services and resources". - - A "trust relationship" is associated with this role that allows the Control Plane AWS account to assume this role. + - When registering a cloud account targeting AWS, your AWS administrator must create a new AWS role (named `cpln-ORG_NAME`) with the following policies: + - A `cpln-connector` policy granting permissions to create and manage IAM roles. + - `ReadOnlyAccess` policy for read-only access to AWS services and resources. + - A "trust relationship" must be configured to allow Control Plane to assume this role. - Identity Creation - - When an [identity](/reference/identity) is created targeting AWS, Control Plane will create a new role in AWS that will have the minimum permissions that are required to access the targeted services. When a [workload](/concepts/workload) that is assigned with an [identity](/reference/identity) requests credentials to access AWS services, Control Plane will obtain a temporary access token that impersonates the role and inject it into the [workload](/concepts/workload) granting it access. + - When an [identity](/reference/identity) is targets AWS, Control Plane creates an IAM role with least-privilege permissions for the requested services. + When a [workload](/concepts/workload) requests AWS access via its [identity](/reference/identity), Control Plane issues temporary credentials by assuming the IAM role and injecting them into the [workload](/concepts/workload) at runtime. - Removing an AWS Cloud Account - If you no longer require Control Plane to create identities targeting AWS: @@ -39,7 +40,7 @@ Refer to the [Create a Cloud Account](/guides/create-cloud-account) guide for ad ## Azure Details -When registering a cloud account targeting Azure, you can choose from the following methods: +When registering an Azure cloud account, you can choose between the following integration methods: - [Azure SDK](#azure-sdk) - Access tokens are minted using an Azure Service Principal. @@ -49,7 +50,7 @@ When registering a cloud account targeting Azure, you can choose from the follow -During the creation of an Azure cloud account, the Azure CLI generates credentials that are used by Control Plane when connecting to Azure to provision apps or user identities that will be used by workload identities. These credentials are uploaded and stored securely as an [Azure-SDK secret](/reference/secret#azure-sdk) or [Azure-Connector secret](/reference/secret#azure-connector) and can be viewed by clicking `Secrets` from the left menu in the console after creating an Azure cloud account. +During Azure cloud account setup, credentials generated via Azure CLI are securely stored and used by Control Plane to provision identities and manage resources. These credentials are uploaded and stored securely as an [Azure-SDK secret](/reference/secret#azure-sdk) or [Azure-Connector secret](/reference/secret#azure-connector) and can be viewed by clicking `Secrets` from the left menu in the console after creating an Azure cloud account. @@ -71,7 +72,7 @@ For every [identity](/reference/identity) created, Control Plane creates an App - Identity Creation - - When creating an [identity](/reference/identity), [cloud access](/reference/identity#cloud-access-universal-cloud-identity) rules targeting Azure can be defined which specify the minimum access needed by the identity. When the [identity](/reference/identity) is saved in the console, the Azure cloud account will leverage the service principal to create a new App registration with the configured access. + - When creating an [identity](/reference/identity), and [cloud access](/reference/identity#cloud-access-universal-cloud-identity) rules targeting Azure can be defined which specify the minimum access needed by the identity. When the [identity](/reference/identity) is saved in the console, the Azure cloud account will leverage the service principal to create a new App registration with the configured access. - Any [workload](/concepts/workload) can be configured to use this [identity](/reference/identity) and will have access to the defined resources. - Expired / Compromised Credentials diff --git a/reference/domain.mdx b/reference/domain.mdx index 483c74ac..d50f6154 100644 --- a/reference/domain.mdx +++ b/reference/domain.mdx @@ -5,20 +5,20 @@ keywords: ['domain','dns','routing','workload','gvc','tls','certificate','cname' --- ## Domain Overview +[Workloads](/concepts/workload) managed at Control Plane can be configured to serve requests using domain that you own. -[Workloads](/concepts/workload) managed at Control Plane can be configured to serve requests using any domain name you own. Domains are scoped to an [org](/reference/org) and are associated with **one** [GVC](/reference/gvc). The domain can then be configured to handle requests for one or multiple [Workloads](/concepts/workload) within that [GVC](/reference/gvc). -Domains that are configured at Control Plane are automatically secured using TLS certificates, load balanced, and DNS geo-routed to the nearest healthy [location](/reference/location) assigned to the [GVC](/reference/gvc). Geo-routing behavior can be customized per location using [location routing options](/reference/gvc#location-routing-options) to configure priority-based failover and latency adjustments. +Domains configured in Control Plane are automatically secured with TLS certificates, load balanced, and DNS geo-routed to the nearest healthy [location](/reference/location) assigned to the [GVC](/reference/gvc). Geo-routing behavior can be customized per location using [location routing options](/reference/gvc#location-routing-options) to configure priority-based failover and latency adjustments. ### Domain Name Validation -Domain names must be valid domain names with TLDs allowed. The domain name validation follows standard DNS domain name rules. +Domain names must conform to standard DNS naming rules and use a valid TLD. The domain name validation follows standard DNS domain name rules. ## Default Domain Names -If a Domain is not mapped to a [GVC](/reference/gvc), the default domain names provided to [Workloads](/concepts/workload) are: +If a Domain is not associated with a [GVC](/reference/gvc), the following default endpoints are available to [Workloads](/concepts/workload): - Canonical endpoints (Global): `cpln.app` - Individual location endpoints: `controlplane.us` @@ -29,7 +29,7 @@ Refer to the [Configure a Domain](/guides/configure-domain) guide for additional ## Domain Configuration Example -Here's a comprehensive example of a domain configuration: +The following example demonstrates a complete domain configuration: ```yaml kind: domain @@ -92,7 +92,7 @@ spec: An apex domain, also known as a root domain, refers to a domain name that does not have any subdomain prefix (e.g., **example.com**). If you want to use subdomains configured in NS mode, you must create and verify the apex domain in the org. -Even if the apex domain is not used for any workloads, it must be verified to allow these subdomains to be created. +Even if the apex domain is not used by workloads, it must still be verified before subdomains can be created. If multiple [orgs](/reference/org) are creating subdomains using the same apex domain, the apex domain verification only needs to be performed in one of the orgs, but subdomains in orgs that don't have the apex domain will require a TXT record be added to DNS for verification. @@ -104,7 +104,7 @@ The verification TXT record can be named `_cpln.` or `_verify.` ## Hostname Behavior -The `Host` header that will be sent in the request to the target workload will depend on the type of workload and which domain was used for the request. +The `Host` header forwarded to the target workload depends on both the workload type and the domain used for the request. For **serverless** workloads, even if the request was served using a custom domain, the `Host` header will be the canonical endpoint of the workload. @@ -121,7 +121,7 @@ Control Plane provides two routing modes for directing requests to your domain: ### Path Based Routing -Path based routing allows requests to a specific path prefix be routed to a specific workload. Multiple paths can be defined, but there must be at least one path. +Path based routing allows requests matching a specific path prefix to be routed to a specific workload. Multiple paths can be defined, but there must be at least one path defined. This is accomplished by adding a **CNAME** record to DNS and configuring the domain with `dnsMode: cname`. @@ -164,7 +164,7 @@ ALL requests. #### Port Selection -The `port` property allows each route to specify a port that will route requests to the respective port at the running workload. +The `port` property allows each route to forward traffic to a specific port exposed by the running workload. For **serverless** workloads, assigning the port is optional since only one port can serve traffic. @@ -178,7 +178,7 @@ If no replica is specified, traffic will be routed to all replicas of the worklo #### Header Operations -The `headers` property allows routes to be configured to manipulate HTTP headers for all requests to that route. Header operations allow you to set or override headers before forwarding requests to the workload. +The `headers` property allows routes to modify HTTP headers for all requests processed by that route. Header operations allow you to set or override headers before forwarding requests to the workload. **Supported Operations:** - **`set`**: Sets or overrides headers to all HTTP requests for this route @@ -211,7 +211,7 @@ port configured on the container. (i.e., HTTP2 is compatible with HTTP2 and GRPC The `mirror` property allows a route to be configured to mirror requests to another workload. **For example:** A request to the URL `https://sub.example.com/` can be mirrored to the workload `api-service-v2` 50% of the time. -This can be useful for testing new versions of a workload before promoting it to the main workload. +This is commonly used for testing new workload versions before promoting them to production traffic. An optional `port` property can be added to the mirror configuration to specify which port the mirrored request should be sent to on the target workload. If not specified, it will default to first listed port on the target workload. @@ -243,7 +243,7 @@ Instead of specifying routes based on a path prefix, paths can be specified usin ### Subdomain Based Routing -Subdomain based routing allows a domain to be mapped to all workloads in a [GVC](/reference/gvc). +Subdomain based routing maps a domain to all workloads within a [GVC](/reference/gvc). This is accomplished by adding **NS** records to DNS which delegate DNS to Control Plane for this domain **only** and configuring the domain with `dnsMode: ns`. @@ -266,7 +266,7 @@ Control Plane supports two DNS modes for domain configuration: ### CNAME Mode (`dnsMode: cname`) -In CNAME mode, Control Plane will configure workloads to accept traffic for the domain but will not manage DNS records for the domain. End users configure CNAME records in their own DNS pointed to the canonical workload endpoint. +In CNAME mode, Control Plane will configure workloads to accept traffic for the domain but will not manage DNS records for the domain. Users configure CNAME records in their DNS provider that point to the canonical workload endpoint. **Certificate Challenge Types:** - `certChallengeType: http01`: Uses HTTP-01 challenge for certificate validation @@ -280,7 +280,7 @@ In CNAME mode, Control Plane will configure workloads to accept traffic for the ### NS Mode (`dnsMode: ns`) -In NS mode, Control Plane will manage the subdomains and create all necessary DNS records. End users configure an NS record to forward DNS requests to the Control Plane managed DNS servers. +In NS mode, Control Plane manages subdomains and automatically creates the required DNS records. End users configure an NS record to forward DNS requests to the Control Plane managed DNS servers. HTTP-01 challenge type is not supported for NS mode domains. @@ -338,7 +338,7 @@ The `protocol` property specifies the protocol used for the port. The following The default TLS protocol version is **`minProtocolVersion: TLSV1_2`**. The minimum TLS protocol version is **`TLSV1_0`**. -The minimum version should be set as high as possible, with a maximum supported value of **`TLSV1_3`**. All modern browsers support the default of **`TLSV1_2`**. +The minimum TLS version should be configured as high as compatibility requirements allow, with a maximum supported value of **`TLSV1_3`**. All modern browsers support the default of **`TLSV1_2`**. Supported TLS protocol versions: - **`TLSV1_3`** (TLS 1.3) @@ -427,7 +427,7 @@ When a web page makes a cross-origin request, the server needs to include specif CORS helps to prevent malicious scripts from performing unauthorized actions on behalf of a user, while still allowing legitimate cross-origin requests between trusted domains. It plays a crucial role in enabling modern web applications to interact with APIs and services hosted on different domains. -The following are CORS properties that are configurable on the domain. Depending on the application being served, these setting could be configured from the application. +The following CORS properties can be configured on the domain. Depending on the application being served, these setting could be configured from the application. The following CORS properties can be configured: @@ -460,7 +460,7 @@ See the [GVC dedicated load balancer](/reference/gvc#dedicated-load-balancer) re The `numTrustedProxies` property gives control over the number of trusted proxies that are configured in front of Control Plane. -Changing it, controls the source ip address used for request logging, firewall settings and for the X-Envoy-External-Address header passed to workloads. +Changing this value controls the source IP address used for request logging, firewall settings, and for the X-Envoy-External-Address header passed to workloads. If set to 1, then the last address in an existing X-Forwarded-For header will be used in place of the source client IP address. @@ -525,7 +525,7 @@ This option allows forwarding traffic for different host headers to specific wor ## Replica Direct Routing Domains can be configured, in conjunction with a `stateful` workload, for replica direct endpoints. -These links will direct traffic directly to the specified replica of a workload. +These endpoints route traffic directly to a specific workload replica. Control Plane also provides built-in per-replica endpoints under `controlplane.us` when `spec.loadBalancer.replicaDirect` is enabled on the workload — no custom domain required. See [Replica-Direct Endpoints](/reference/workload/general#replica-direct-endpoints) in the workload reference. @@ -533,7 +533,7 @@ These links will direct traffic directly to the specified replica of a workload. To configure a Domain for replica direct routing, you need to set the `workloadLink` property on the Domain to the link of the workload. The domain will also need to be configured as a `cname` domain with the `dns01` cert challenge type. -The domain needs at least one port with exactly one route per port. +The domain must define at least one port, and each port must contain exactly one route. **Validation Rules:** - When `workloadLink` is configured, `certChallengeType` cannot be `http01` @@ -667,7 +667,7 @@ To view the CLI documentation for domains, see the [Domain CLI reference](/cli-r ## Domain Certificate Management Control Plane automatically handles the creation and renewal of TLS certificates for Domains. -This ensures that your Domains are always secured with up-to-date certificates without requiring manual intervention. +This ensures that your Domains are remain secured with up-to-date certificates without requiring manual intervention. The certificates issued are valid for 90 days and refresh every 60 days. ### Certificate Creation and Renewal Process @@ -787,6 +787,6 @@ Any other response indicates that the request was blocked. ### Logging and Monitoring -Errors and warnings are displayed in the status of the Domain objects and are displayed in the UI. +Errors and warnings are exposed through Domain status fields and displayed in the UI. A Grafana metric of `domain_warning` is updated for each Domain. An alarm is configured to notify the default contact using this metric when any Domain is in a warning state. diff --git a/reference/overview.mdx b/reference/overview.mdx index 8ba1c57d..ee7e5679 100644 --- a/reference/overview.mdx +++ b/reference/overview.mdx @@ -10,7 +10,7 @@ The Reference section provides detailed documentation for all Control Plane reso ## Resource Hierarchy -Control Plane uses a hierarchical structure where resources are scoped to provide isolation and governance: +Control Plane resources are organized into a hierarchical structure where resources are scoped to provide isolation and governance: ```text Org (Organization) @@ -29,6 +29,7 @@ Org (Organization) ## Organization +Top-level administrative boundary for all platform resources. Configure organization-wide governance, observability, security integrations, and operational settings. Isolated environment and top-level container for all resources. Configure external logging, threat detection, tracing, and organization-wide settings. @@ -67,7 +68,7 @@ Core resources for running and managing your applications. Global Virtual Cloud - container for workloads deployed across multiple cloud locations with shared configuration. - Your applications running as standard, stateful, cron, or serverless deployments with autoscaling and load balancing. + Deploy containerized applications as standard, stateful, cron, or serverless workloads with autoscaling and load balancing. Geographic regions across AWS, GCP, and Azure where your workloads can be deployed. @@ -179,15 +180,15 @@ The Workload resource has extensive configuration options documented across mult - Control Plane uses a role-based access control model where **Policies** grant specific permissions to **Principals** (users, groups, service accounts, identities) for target resources. Permissions follow hierarchical "implies" relationships - for example, `manage` implies `create`, `delete`, and `edit`. + Control Plane implements hierarchical role-based access control (RBAC) where **Policies** bind permissions to **Principals** (users, groups, service accounts, identities) for target resources. Permission inheritance follows hierarchical implication rules; for example, `manage` implicitly grants `create`, `edit`, and `delete`. - A single **GVC** can deploy workloads across multiple **Locations** spanning AWS, GCP, and Azure regions simultaneously. Traffic is automatically routed to the nearest healthy instance. + A single **GVC** can deploy workloads across multiple **Locations** spanning AWS, GCP, and Azure regions simultaneously. Platform networking automatically routes traffic to healthy workload instances based on availability and geographic proximity. **Identities** provide credential-free access to cloud resources and private networks. Instead of embedding secrets in your code, workloads assume cloud-native identities (AWS IAM roles, GCP service accounts, Azure managed identities) at runtime. - **Agents** create secure tunnels to private networks without exposing them to the internet. Combined with **Identities**, workloads can access databases, APIs, and services in your VPCs. + **Agents** establish secure connectivity between Control Plane and private infrastructure without requiring public network exposure. Combined with **Identities**, workloads can securely access databases, internal APIs, and services within private cloud networks and VPC environments. diff --git a/whatis.mdx b/whatis.mdx index 1af7adac..8108a018 100644 --- a/whatis.mdx +++ b/whatis.mdx @@ -6,36 +6,36 @@ keywords: ['cpln', 'product overview', 'hybrid cloud', 'multicloud', 'cloud worm ## Overview -Control Plane is a hybrid platform enabling cloud architects to combine the services, regions, and computing power of Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure and any other public or private cloud to provide developers with a flexible yet unbreakable global environment for building backend apps and services. +Control Plane is a hybrid platform enabling cloud architects to combine the services, regions, and computing power of Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and any other public or private cloud to provide developers with a flexible yet resilient global environment for building backend apps and services. -On Control Plane, microservices can run simultaneously on any combination of cloud compute and consume any combination of cloud services without embedded credentials. The platform handles identity conveyance and authorization uniformly, utilizing best-practices/least privilege principles consistently and securely. +On Control Plane, microservices can run simultaneously across any combination of cloud infrastructure and connect to any combination of cloud services without embedded credentials. The platform handles identity propagation and authorization uniformly, utilizing best-practices and least-privilege principles consistently across environments. ## Based on Kubernetes -While Kubernetes orchestrates workloads within a single cluster, Control Plane orchestrates an unlimited number of hardened, security-isolated Kubernetes clusters in all the regions of the major clouds. You can easily add additional Kubernetes clusters running in any cloud as custom `CPLN Platform (BYOK)` regions. You can use Control Plane without in-depth knowledge of Kubernetes and its associated technologies but, if you have already deployed your own clusters, the platform augments and expands your existing Kubernetes infrastructure. +While Kubernetes orchestrates workloads within a single cluster, Control Plane orchestrates an unlimited number of hardened, security-isolated Kubernetes clusters across all regions in major cloud providers. You can easily add additional Kubernetes clusters in any cloud as custom `CPLN Platform (BYOK)` regions. You can use Control Plane without in-depth knowledge of Kubernetes, but if you already deployed your own clusters, the platform augments and extends your current Kubernetes infrastructure. ## Why run on Control Plane? -Rather than restricting architects to a corner of the cloud, Control Plane enables architects to build a resilient, easy-to-use combination of clouds and cloud resources. +Rather than restricting architects to a single cloud, Control Plane enables them to build a resilient, unified multi-cloud environment. Some of the attributes which set Control Plane apart include: -- **Multi-Region and Multicloud Compute**: With Control Plane, your workloads run agnostically across any combination of geographic regions and cloud providers (AWS, Azure, GCP or any other public and private clouds). Kubernetes clusters hosted anywhere can be easily added to Control Plane. This enables you to switch clouds or add clouds with a few clicks. +- **Multi-Region and Multicloud Compute**: With Control Plane, your workloads run across any combination of geographic regions and cloud providers (AWS, Azure, GCP or any other public and private cloud). Kubernetes clusters hosted anywhere can be easily added to Control Plane. This enables you to switch or add cloud providers with a few clicks. -- **Any Cloud Backing Service**: Microservices running on Control Plane have native access to ANY service on ANY cloud (e.g., BigQuery on GCP, AD on Azure, SQS on AWS) without embedding credentials by using [Universal Cloud Identity](/reference/identity#cloud-access-universal-cloud-identity-universal-cloud-identity). This enables you to easily mix and match services from multiple clouds by virtually unifying the networking and identity and authorization policies across all supported clouds. Control Plane’s [Cloud Wormhole](/reference/identity#network-resources-cloud-wormholes-cloud-wormhole) functionality enables your microservice to access native AWS, Azure, and GCP services within and across VPCs. Using [Cloud Wormhole](/reference/identity#network-resources-cloud-wormholes-cloud-wormhole), workloads can also access endpoints behind firewalls on-prem and even on the developer's laptop during development. +- **Any Cloud Backing Service**: Microservices running on Control Plane have native access to ANY service on ANY cloud (e.g., BigQuery on GCP, AD on Azure, SQS on AWS) without embedding credentials by using [Universal Cloud Identity](/reference/identity#cloud-access-universal-cloud-identity-universal-cloud-identity). This enables you to easily mix and match services from multiple clouds by virtually unifying networking, identity and authorization policies across all supported clouds. Control Plane’s [Cloud Wormhole](/reference/identity#network-resources-cloud-wormholes-cloud-wormhole) functionality enables your microservice to access native AWS, Azure, and GCP services within and across VPCs. Using [Cloud Wormhole](/reference/identity#network-resources-cloud-wormholes-cloud-wormhole), workloads can also access endpoints behind firewalls on-prem and even on the developer's laptop during development. -- **Best-of-Breed DevOps Stack**: Control Plane integrates the best of the cloud-native ops stack for metrics, logging, secrets management, software-defined VPN, geo-intelligent DNS and more. You can also easily integrate the tools of your choice. +- **Best-of-Breed DevOps Stack**: Control Plane integrates the best of the cloud-native operations stack for metrics, logging, secrets management, software-defined VPN, geo-intelligent DNS, and more. You can also easily integrate the tools of your choice. -- **Uniform Access Control**: Control Plane provides advanced, consistent, yet easy-to-use fine-grained authorization controls. These controls are identical whether administering Control Plane itself or your custom workloads. Your workloads get an out-of-the-box fine-grained authorization "dial tone" that uniformly handles simple and complex use cases alike. +- **Uniform Access Control**: Control Plane provides consistent, fine-grained authorization controls. These controls are identical whether administering Control Plane itself or your custom workloads. Your workloads get an out-of-the-box fine-grained authorization "dial tone" that handles both simple and complex access patterns uniformly. -- **Built In Audit Trail**: Control Plane exposes a tamper-proof audit trail facility for both the Control Plane actions you take as well as for custom workloads. Your code writes to a configured localhost port, and your audit events are correctly captured and secured. The audit data is indexed and can efficiently be searched programmatically from your user interface. +- **Built-In Audit Trail**: Control Plane provides a tamper-proof audit trail facility for both platform actions and custom workloads. Your code writes to a configured localhost port, and audit events are captured and secured automatically. Audit data is indexed and can be efficiently searched programmatically or via the user interface. -- **Efficient Cloud Cost**: Cloud consumption is elastically optimized on Control Plane to run with the exact resources required and nothing else, enabling you to derive the benefits of serverless without rearchitecting your microservices. Whether your app has a Dockerfile or not, regardless of whether you designed the app to run serverless, the platform runs your microservice with elastic scalability - from zero to any scale you specify. +- **Efficient Cloud Cost Optimization**: Cloud consumption is optimized on Control Plane to use only the exact resources required, enabling serverless-like benefits without rearchitecting your microservices. Whether your app has a Dockerfile or not, or was originally designed for serverless, the platform runs your microservice with elastic scalability - from zero to any scale you specify. -- **Unified Interface**: The cloud platforms differ substantially from one another in their APIs, CLIs, and UIs. Each has its specialized, often convoluted interface surface, with its unique and steep learning curve. Control Plane offers a symmetrical UI, API, and CLI which enable you to deploy and run in **any** cloud. It enables developers to deploy and manage workloads uniformly to multiple clouds simultaneously, from a single, intuitive and consistent interface, making workload deployment and day-2 operations a breeze. +- **Unified Interface**: Cloud platforms differ significantly in their APIs, CLIs, and UIs. Each has a specialized, often convoluted interface, with its unique and steep learning curve. Control Plane provides a symmetrical UI, API, and CLI that enables developers to deploy and run workloads in **any** cloud. It allows developers to deploy and manage workloads uniformly across multiple clouds simultaneously, from a single, consistent interface, making workload deployment and day-2 operations easy to manage. **The result: Enhanced performance for the end-user.** -Control Plane utilizes advanced, redundant health monitoring and geographically-distributed DNS infrastructure. The platform automatically re-routes traffic to healthy regions and clusters. It removes unhealthy and unreachable nodes from rotation, so the end-users measured availability and latency are optimal. A user from one part of the world experiences ultra-low-latency responses, while a user on the other side of the planet experiences similar ~20-30 ms latency. +Control Plane utilizes advanced, redundant health monitoring and geographically-distributed DNS infrastructure. The platform automatically reroutes traffic to healthy regions and clusters. It removes unhealthy and unreachable nodes from rotation, improving availability and reducing latency for end users. A user from one part of the world experiences ultra-low-latency responses, while a user on the other side of the planet experiences similar ~20-30 ms latency. -Control Plane enables you to utilize the full range of services and computing power your application requires from any number of clouds while delivering your users uniform and predictable performance. +Control Plane enables you to use the full range of services and the computing power your application requires across multiple clouds while delivering uniform and predictable performance to your users. \ No newline at end of file