diff --git a/platform/administer/authentication/access-keys.mdx b/platform/administer/authentication/access-keys.mdx index 4624790574..c897a9e847 100644 --- a/platform/administer/authentication/access-keys.mdx +++ b/platform/administer/authentication/access-keys.mdx @@ -25,7 +25,7 @@ The platform supports limiting access key permissions by scoping them to specifi A single project within the platform, limiting actions to only that project's resources. -A particular virtual cluster, constraining operations to just that virtual cluster's components. +A particular tenant cluster, constraining operations to just that tenant cluster's components. A specific namespace, allowing actions only within that defined namespace boundary. @@ -35,13 +35,13 @@ Scoping provides an important security control by restricting what an access key When implementing access keys in automated workflows, consider using scoped keys to improve security by limiting access to only the required resources. -For example, an automated deployment process typically needs access to just one project or virtual cluster. By scoping the access key appropriately, you protect other resources in case the key is compromised. +For example, an automated deployment process typically needs access to just one project or tenant cluster. By scoping the access key appropriately, you protect other resources in case the key is compromised. ## Example use cases CI/CD integration often requires access to platform resources. You can create project-scoped access keys for build pipelines to enable automated building and deployment while limiting potential security exposure. -Automated deployment tools can use virtual cluster-scoped keys to manage deployments without gaining unnecessary access to other parts of your infrastructure. +Automated deployment tools can use tenant cluster-scoped keys to manage deployments without gaining unnecessary access to other parts of your infrastructure. Monitoring applications need to gather metrics and status information. Configure namespace-scoped keys for these systems to allow monitoring without granting broader permissions. @@ -79,7 +79,7 @@ Apply the principle of least privilege by using the most restrictive scope possi Optional If you'd like to limit the scope of the Access Key, expand the configuration section. In this section - you can select the clusters, namespaces, and virtual clusters of which to + you can select the clusters, namespaces, and tenant clusters of which to limit the Access Key scope to. @@ -135,7 +135,7 @@ Replace the following placeholders: Save the modified template as `my-kube-config.yaml`. -You can access your virtual cluster using the newly created kube config file: +You can access your tenant cluster using the newly created kube config file: ```bash KUBECONFIG=my-kube-config.yaml kubectl get users diff --git a/platform/administer/bare-metal/overview.mdx b/platform/administer/bare-metal/overview.mdx index eab2b09112..050041581e 100644 --- a/platform/administer/bare-metal/overview.mdx +++ b/platform/administer/bare-metal/overview.mdx @@ -8,7 +8,7 @@ import FeatureTable from '@site/src/components/FeatureTable'; -vCluster Platform integrates [Metal3](https://metal3.io/) and [Ironic](https://ironicbaremetal.org/) for bare metal server lifecycle management. Physical servers are represented as `BareMetalHost` resources on a host cluster. The platform manages their detection, provisioning, configuration, and decommissioning for reuse. +vCluster Platform integrates [Metal3](https://metal3.io/) and [Ironic](https://ironicbaremetal.org/) for bare metal server lifecycle management. Physical servers are represented as `BareMetalHost` resources on a control plane cluster. The platform manages their detection, provisioning, configuration, and decommissioning for reuse. ## When to use bare metal @@ -21,12 +21,12 @@ Bare metal servers are a good fit when workloads need direct hardware access or ## Prerequisites -Before managing bare metal servers, you need a [Metal3 node provider](../node-providers/metal3.mdx) configured on a host cluster. +Before managing bare metal servers, you need a [Metal3 node provider](../node-providers/metal3.mdx) configured on a control plane cluster. The node provider can deploy Metal3, Ironic, and a DHCP server automatically, or you can install them yourself. ## Add servers -Bare metal servers are added by creating `BareMetalHost` resources on the host cluster, either through the platform UI or by applying them directly with kubectl. Each BareMetalHost represents a physical server and requires BMC (Baseboard Management Controller) configuration for out-of-band management. +Bare metal servers are added by creating `BareMetalHost` resources on the control plane cluster, either through the platform UI or by applying them directly with kubectl. Each BareMetalHost represents a physical server and requires BMC (Baseboard Management Controller) configuration for out-of-band management. ### BMC configuration diff --git a/platform/administer/clusters/advanced/external-database/deploy.mdx b/platform/administer/clusters/advanced/external-database/deploy.mdx index 46f4a53433..2d4a73741d 100644 --- a/platform/administer/clusters/advanced/external-database/deploy.mdx +++ b/platform/administer/clusters/advanced/external-database/deploy.mdx @@ -64,7 +64,7 @@ across failure domains. ### Install the Amazon EBS CSI driver The EBS CSI driver is required for dynamic provisioning of persistent volumes -on EKS. Without it, virtual cluster StatefulSet pods remain in `Pending` state +on EKS. Without it, tenant cluster StatefulSet pods remain in `Pending` state because the `gp2` storage class cannot provision volumes. -For more details on EKS prerequisites for running virtual clusters, see the +For more details on EKS prerequisites for running tenant clusters, see the [EKS environment setup guide](/docs/vcluster/deploy/control-plane/kubernetes-pod/environment/eks). ### Note the EKS VPC ID and CIDR @@ -538,7 +538,7 @@ configuration. Unlike multi-region, no `multiRegion` block is needed — only Create a values file (`platform-ha-values.yaml`): diff --git a/platform/administer/clusters/advanced/external-database/external-database.mdx b/platform/administer/clusters/advanced/external-database/external-database.mdx index 6438b5d561..aa037d3844 100644 --- a/platform/administer/clusters/advanced/external-database/external-database.mdx +++ b/platform/administer/clusters/advanced/external-database/external-database.mdx @@ -28,7 +28,7 @@ Consider an external database deployment when you need one or more of the follow - **Control plane resilience**: If the platform pod or its node goes down, another replica takes over leadership automatically. Connected clusters continue operating through the surviving replicas. -- **Strict RBAC environments**: Run the platform on a host cluster with +- **Strict RBAC environments**: Run the platform on a control plane cluster with limited permissions, similar to [Least Privilege Mode](../../../../configure/agent-settings/least-privilege-mode.mdx) for agents. An external database lets the platform replicas use a shared diff --git a/platform/administer/clusters/advanced/ingress-suffix.mdx b/platform/administer/clusters/advanced/ingress-suffix.mdx index 311fa22e79..e03d824771 100644 --- a/platform/administer/clusters/advanced/ingress-suffix.mdx +++ b/platform/administer/clusters/advanced/ingress-suffix.mdx @@ -11,9 +11,9 @@ import Label from "@site/src/components/Label"; import Input from "@site/src/components/Input"; import Expander from "@site/src/components/Expander"; -As outlined in the 'Virtual Clusters -> Advanced Topics -> Ingress Access' section, you can enable the 'AccessPoint' feature to access a virtual cluster API server directly by avoiding the vCluster Platform proxy. This requires a valid ingress controller to be present on the host cluster and a valid domain to be set in the `loft.sh/ingress-suffix` annotation on the Cluster Object. +As outlined in the 'Tenant Clusters -> Advanced Topics -> Ingress Access' section, you can enable the 'AccessPoint' feature to access a tenant cluster API server directly by avoiding the vCluster Platform proxy. This requires a valid ingress controller to be present on the control plane cluster and a valid domain to be set in the `loft.sh/ingress-suffix` annotation on the Cluster Object. -Once this is done, vCluster Platform creates a connection to the virtual cluster through an ingress instead of the default vCluster Platform proxy. This can be useful, if you want to handout the virtual cluster kubeconfig to users that do not belong to vCluster Platform. +Once this is done, vCluster Platform creates a connection to the tenant cluster through an ingress instead of the default vCluster Platform proxy. This can be useful, if you want to handout the tenant cluster kubeconfig to users that do not belong to vCluster Platform. The ingress name URL is calculated in the following way: @@ -34,7 +34,7 @@ You can set the required ingress suffix in the vCluster Platform UI: In the drawer that appears from the right, click the{" "} configuration pane. Provide the desired domain - under the field. + under the field. Click on the button. diff --git a/platform/administer/clusters/advanced/multi-region.mdx b/platform/administer/clusters/advanced/multi-region.mdx index dc3f583310..219fff991c 100644 --- a/platform/administer/clusters/advanced/multi-region.mdx +++ b/platform/administer/clusters/advanced/multi-region.mdx @@ -148,7 +148,7 @@ eksctl create cluster \ #### Install the Amazon EBS CSI driver The EBS CSI driver is required for dynamic provisioning of persistent volumes -on EKS. Without it, virtual cluster StatefulSet pods remain in `Pending` state +on EKS. Without it, tenant cluster StatefulSet pods remain in `Pending` state because the `gp2` storage class cannot provision volumes. Install the driver as an EKS managed add-on on **each** cluster: @@ -163,7 +163,7 @@ eksctl create addon --name aws-ebs-csi-driver \ --region eu-west-1 ``` -For more details on EKS prerequisites for running virtual clusters, see the +For more details on EKS prerequisites for running tenant clusters, see the [EKS environment setup guide](/docs/vcluster/next/deploy/control-plane/kubernetes-pod/environment/eks). ### Step 2 - Install AWS load balancer controller diff --git a/platform/administer/clusters/advanced/networking.mdx b/platform/administer/clusters/advanced/networking.mdx index 3ed004f498..d50a01ec22 100644 --- a/platform/administer/clusters/advanced/networking.mdx +++ b/platform/administer/clusters/advanced/networking.mdx @@ -28,24 +28,24 @@ In private GKE clusters, Kubernetes control plane and worker nodes might reside ### Connect vCluster to the platform -When vCluster and the platform are in the same host cluster, the platform exposes an in‑cluster Service that targets port `10443` on the platform pods, so vCluster in the same host cluster talk to the +When vCluster and the platform are in the same control plane cluster, the platform exposes an in‑cluster Service that targets port `10443` on the platform pods, so vCluster in the same control plane cluster talk to the platform via that `ClusterIP` Service. You should allow egress from the vCluster namespace to platform pods on TCP port `10443`. -When vCluster and the platform are in different host clusters, vCluster uses the `loftHost` value (your platform's load balancer or Ingress DNS) to establish a Tailscale-backed tunnel for API traffic. +When vCluster and the platform are in different control plane clusters, vCluster uses the `loftHost` value (your platform's load balancer or Ingress DNS) to establish a Tailscale-backed tunnel for API traffic. You shoud allow egress traffic from vCluster pods to the `lostHost` domain and the egress traffic from platform agent to `loftHost`, if it participates in the handshake in your setup. -### Enable DNS resolution in virtual clusters +### Enable DNS resolution in tenant clusters -vCluster runs a CoreDNS component inside each virtual cluster to handle internal DNS queries. To avoid conflicts with the host cluster's DNS, CoreDNS in vCluster listens on port `1053` instead of the default port `53`. +vCluster runs a CoreDNS component inside each tenant cluster to handle internal DNS queries. To avoid conflicts with the control plane cluster's DNS, CoreDNS in vCluster listens on port `1053` instead of the default port `53`. -If this port is blocked, DNS queries from virtual cluster pods might not work, especially when the querying pod and the CoreDNS pod are on different nodes. This issue commonly affects EKS clusters created with Terraform, which set up separate security groups for the control plane and worker nodes. By default, the node security group does not allow inbound traffic on port `1053`. +If this port is blocked, DNS queries from tenant cluster pods might not work, especially when the querying pod and the CoreDNS pod are on different nodes. This issue commonly affects EKS clusters created with Terraform, which set up separate security groups for the control plane and worker nodes. By default, the node security group does not allow inbound traffic on port `1053`. -To enable proper DNS resolution within virtual clusters, allow inbound traffic on port `1053` between nodes. +To enable proper DNS resolution within tenant clusters, allow inbound traffic on port `1053` between nodes. | Port | Description | Purpose | |--------|----------------------|-------------------------------------------------------------------------| -| `1053` | CoreDNS for vCluster | Enables internal DNS resolution across nodes in virtual clusters | +| `1053` | CoreDNS for vCluster | Enables internal DNS resolution across nodes in tenant clusters | :::note If you're using EKS with Terraform, check the default node security group and manually allow inbound traffic on TCP and UDP port `1053`. This ensures DNS queries between pods and CoreDNS can succeed even when scheduled on different nodes. diff --git a/platform/administer/clusters/advanced/terraform-registration.mdx b/platform/administer/clusters/advanced/terraform-registration.mdx index 4a6319be44..da85f02505 100644 --- a/platform/administer/clusters/advanced/terraform-registration.mdx +++ b/platform/administer/clusters/advanced/terraform-registration.mdx @@ -13,11 +13,11 @@ import PageVariables from "@site/src/components/PageVariables"; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -Automate host cluster registration to vCluster Platform using Terraform. This guide shows you how to programmatically register clusters during infrastructure provisioning, eliminating manual registration steps. +Automate control plane cluster registration to vCluster Platform using Terraform. This guide shows you how to programmatically register clusters during infrastructure provisioning, eliminating manual registration steps. ## Overview -When provisioning infrastructure with Terraform, you can automate the complete cluster registration workflow. This approach registers the cluster in vCluster Platform and installs the agent, making the cluster immediately available for virtual cluster deployment. +When provisioning infrastructure with Terraform, you can automate the complete cluster registration workflow. This approach registers the cluster in vCluster Platform and installs the agent, making the cluster immediately available for tenant cluster deployment. :::info Terraform provider deprecation The vCluster Platform Terraform provider is deprecated. This guide provides an alternative approach using the Kubernetes provider and vCluster Platform API to achieve the same automation goals. @@ -598,7 +598,7 @@ The configuration requires two kubernetes provider contexts: one for the platfor After registering your cluster, you can: -- [Create virtual clusters](../../../use-platform/virtual-clusters/add-virtual-clusters.mdx) on the registered host cluster +- [Create tenant clusters](../../../use-platform/virtual-clusters/add-virtual-clusters.mdx) on the registered control plane cluster - [Configure agent settings](./agent-config.mdx) for advanced networking or security requirements - [Set up monitoring](../../../maintenance/monitoring/overview.mdx) for the agent and connected resources - [Implement policies](./policies.mdx) to control resource usage across clusters diff --git a/platform/administer/connector/database.mdx b/platform/administer/connector/database.mdx index 924ef03036..b906ca3fad 100644 --- a/platform/administer/connector/database.mdx +++ b/platform/administer/connector/database.mdx @@ -2,7 +2,7 @@ title: Database Connector sidebar_label: Database sidebar_position: 1 -description: Learn how to use Database Connectors with the platform to manage backing stores for multiple virtual clusters. +description: Learn how to use Database Connectors with the platform to manage backing stores for multiple tenant clusters. --- import BasePrerequisites from '../../_partials/install/base-prerequisites.mdx'; @@ -22,7 +22,7 @@ import Flow, { Step } from '@site/src/components/Flow' -The database connector feature allows an admin to configure a database server to manage backing stores for multiple virtual clusters. For each virtual cluster, the feature automatically creates an independent database and non-privileged user. Read more about the use of external databases in the [External Database documentation](/docs/vcluster/configure/vcluster-yaml/control-plane/components/backing-store/database/external). +The database connector feature allows an admin to configure a database server to manage backing stores for multiple tenant clusters. For each tenant cluster, the feature automatically creates an independent database and non-privileged user. Read more about the use of external databases in the [External Database documentation](/docs/vcluster/configure/vcluster-yaml/control-plane/components/backing-store/database/external). ## Compatibility matrix @@ -215,7 +215,7 @@ For the platform to start using a database server, a secret must be created that To create a database connector secret in the UI, navigate to the sidebar and select **Databases** -> **Connect Database Secrets**. -Alternatively, a Secret YAML manifest can be applied to the platform's host cluster. +Alternatively, a Secret YAML manifest can be applied to the platform's control plane cluster. ```yaml title="Shared database secret template" @@ -245,9 +245,9 @@ kubectl create secret generic default-secret-name \ -o yaml --dry-run=client > secret.yaml ``` -## Use virtual cluster with shared database +## Use tenant cluster with shared database -A new virtual cluster can now reference the created connector secret by setting the `controlPlane.backingStore.database.external.connector` field in the virtual cluster config to the `name` of the connector secret. +A new tenant cluster can now reference the created connector secret by setting the `controlPlane.backingStore.database.external.connector` field in the tenant cluster config to the `name` of the connector secret. :::warning Modifying a database secret to point to a different database server is not recommended and may lead to data loss. @@ -273,21 +273,21 @@ stringData: type: mysql # This can be mysql or postgres. If left blank, the mysql database type is assumed. ``` -## Recreate / restore virtual clusters +## Recreate / restore tenant clusters -To accommodate infrastructure updates or disaster recovery needs, follow this process to restore virtual clusters using a **database connector** powered backing store. +To accommodate infrastructure updates or disaster recovery needs, follow this process to restore tenant clusters using a **database connector** powered backing store. - Annotate the target VirtualClusterInstance with `vcluster.com/database-reclaim-policy: retain` so deleting the virtual cluster does not also delete the database. + Annotate the target VirtualClusterInstance with `vcluster.com/database-reclaim-policy: retain` so deleting the tenant cluster does not also delete the database. Record the value of the `vcluster.com/database-uid` annotation and save the `spec` from the VirtualClusterInstance. - Delete the virtual cluster. - Create the virtual cluster with the same `vcluster.com/database-uid` annotation and the saved `spec`. + Delete the tenant cluster. + Create the tenant cluster with the same `vcluster.com/database-uid` annotation and the saved `spec`. :::important Scope -This procedure only restores the backing store connection. Depending on your configuration, resources such as persistent volumes or other external dependencies might not be available for the recreated virtual cluster. +This procedure only restores the backing store connection. Depending on your configuration, resources such as persistent volumes or other external dependencies might not be available for the recreated tenant cluster. ::: :::important RBAC permissions @@ -308,9 +308,9 @@ rules: ### Sample bulk migration script :::important -This script assumes that every matched virtual cluster uses a database connector. +This script assumes that every matched tenant cluster uses a database connector. -If a matched virtual cluster does not use a database connector, its data is not preserved. +If a matched tenant cluster does not use a database connector, its data is not preserved. ::: ```sh title="Sample control plane host bulk migration script" diff --git a/platform/administer/connector/iam_database.mdx b/platform/administer/connector/iam_database.mdx index 8543aaff97..f70b5012d8 100644 --- a/platform/administer/connector/iam_database.mdx +++ b/platform/administer/connector/iam_database.mdx @@ -2,7 +2,7 @@ title: IAM Database Connector sidebar_label: IAM Database sidebar_position: 1 -description: Learn how to use IAM based Database Connectors with the platform to manage backing stores for multiple virtual clusters. +description: Learn how to use IAM based Database Connectors with the platform to manage backing stores for multiple tenant clusters. --- import BasePrerequisites from "../../_partials/install/base-prerequisites.mdx"; @@ -13,7 +13,7 @@ import TabItem from "@theme/TabItem"; -The IAM Database Connector feature allows virtual clusters to use a shared database server as their backing store and authenticate using workload identity. +The IAM Database Connector feature allows tenant clusters to use a shared database server as their backing store and authenticate using workload identity. This page describes how to set up a shared database connector for cloud providers, for general instructions on using database connectors, see the [Database Connectors](./database.mdx) page. @@ -184,7 +184,7 @@ Once IAM authentication is granted to a user, password-based login for that user ### Create IAM policies and role Next up, you need to allow the vCluster Platform to connect to the RDS instance using IAM authentication. This is done by creating an IAM Policy and attaching it to the IAM Role used by the vCluster Platform pods. -It also needs permissions to manage IAM Roles, Policies, and EKS Pod Identity Associations for the virtual clusters. +It also needs permissions to manage IAM Roles, Policies, and EKS Pod Identity Associations for the tenant clusters. :::info A policy for each DB Connector / RDS Instance that the platform manages is required. The vCluster Platform must be restarted for newly attached policies to take effect. @@ -223,7 +223,7 @@ For example, if the `DbProxyArn` is `arn:aws:rds:us-east-1:123456789012:db-proxy -This policy allows the vCluster Platform to manage IAM roles for virtual cluster database access. +This policy allows the vCluster Platform to manage IAM roles for tenant cluster database access. You can set this up with or without an AWS IAM permission boundary. Using a permission boundary is strongly recommended for production environments. Permission boundaries act as a safety @@ -444,7 +444,7 @@ remove the second statement. -Manages EKS Pod Identity Associations for virtual clusters to allow them to assume the IAM Roles created for database access. +Manages EKS Pod Identity Associations for tenant clusters to allow them to assume the IAM Roles created for database access. Replace `${REGION}`, `${ACCOUNT}`, and `${EKS_CLUSTER_NAME}` with your values. @@ -542,7 +542,7 @@ you can add the annotation to the secret after it has been created by the UI, by -Alternatively, a Secret YAML manifest can be applied to the platform's host cluster. +Alternatively, a Secret YAML manifest can be applied to the platform's control plane cluster. @@ -646,12 +646,12 @@ Verify the secret was created with the correct label: kubectl get secrets -n vcluster-platform -l loft.sh/connector-type=shared-database ``` -To use the secret in a virtual cluster, refer to the [Database Connectors](./database#use-virtual-cluster-with-shared-database) documentation. +To use the secret in a tenant cluster, refer to the [Database Connectors](./database#use-tenant-cluster-with-shared-database) documentation. :::note -AWS RDS PostgreSQL requires secure transport for IAM authentication to work. You must set the appropriate SSL mode environment variable for each virtual cluster that uses an IAM database connector. +AWS RDS PostgreSQL requires secure transport for IAM authentication to work. You must set the appropriate SSL mode environment variable for each tenant cluster that uses an IAM database connector. -Set `PGSSLMODE` to `require` in the virtual cluster's `values.yaml`: +Set `PGSSLMODE` to `require` in the tenant cluster's `values.yaml`: ```yaml controlPlane: diff --git a/platform/administer/node-providers/kubevirt.mdx b/platform/administer/node-providers/kubevirt.mdx index 5ace4f325a..074c940674 100644 --- a/platform/administer/node-providers/kubevirt.mdx +++ b/platform/administer/node-providers/kubevirt.mdx @@ -53,7 +53,7 @@ flowchart LR The KubeVirt provider works by defining a base `virtualMachineTemplate` and a collection of `nodeTypes`. Each `nodeType` represents a specific kind of virtual machine you want to offer. When a NodeClaim is created for a vCluster, it references one of these `nodeTypes`. The platform then generates a VirtualMachine manifest by combining the base template with any customizations defined in the chosen `nodeType` and applies it to the target -KubeVirt host cluster. +KubeVirt control plane cluster. This approach allows for customizations like: @@ -69,9 +69,9 @@ The KubeVirt provider automates this process using `cloud-init`. Here's the workflow: 1. When a NodeClaim is processed, the platform generates a `cloud-init` configuration containing the necessary registration scripts. -2. This configuration is stored in a Kubernetes Secret in the KubeVirt host cluster. +2. This configuration is stored in a Kubernetes Secret in the KubeVirt control plane cluster. 3. The provider injects this Secret into the VirtualMachine definition as a `cloudInitNoCloud` disk. -4. When the VM boots, `cloud-init` executes the script from the disk, configuring the machine and registering it as a node with the virtual cluster. +4. When the VM boots, `cloud-init` executes the script from the disk, configuring the machine and registering it as a node with the tenant cluster. :::danger Image Requirement This entire process depends on the guest OS image having **cloud-init installed and enabled**. Furthermore, the image must be compatible with KubeVirt's `cloudInitNoCloud` data source. Standard cloud images for distributions like Ubuntu are generally compatible. If you use custom images, you must ensure they meet this requirement. @@ -79,7 +79,7 @@ This entire process depends on the guest OS image having **cloud-init installed ## Configuration -A KubeVirt `NodeProvider` configuration consists of a reference to the host cluster, a base VM template, and a list of node types. +A KubeVirt `NodeProvider` configuration consists of a reference to the control plane cluster, a base VM template, and a list of node types. ### Minimal example @@ -591,7 +591,7 @@ The interface injection itself is a generic mechanism. Netris is one way to driv **Prerequisites:** - [Netris integration](/vcluster/next/configure/vcluster-yaml/integrations/netris) must be enabled and configured in the vCluster configuration. - vCluster Platform license must include the Netris feature. -- Bridge with the `nbr-` must exist on the host cluster nodes. +- Bridge with the `nbr-` must exist on the control plane cluster nodes. **Optional properties:** - `kubevirt.vcluster.com/network-attachment-definition` @@ -663,7 +663,7 @@ spec: memory: 4Gi ``` -Create a NetworkAttachmentDefinition in the KubeVirt host cluster: +Create a NetworkAttachmentDefinition in the KubeVirt control plane cluster: ```yaml apiVersion: k8s.cni.cncf.io/v1 diff --git a/platform/administer/node-providers/overview.mdx b/platform/administer/node-providers/overview.mdx index 8964485def..ac4e899173 100644 --- a/platform/administer/node-providers/overview.mdx +++ b/platform/administer/node-providers/overview.mdx @@ -4,13 +4,13 @@ sidebar_label: Overview sidebar_position: 1 --- -Nodes providers allow you to configure sources for private nodes for virtual clusters in an automatic fashion. The following supported node providers currently exist: +Nodes providers allow you to configure sources for private nodes for tenant clusters in an automatic fashion. The following supported node providers currently exist: * [Terraform](./terraform.mdx) (powered by [OpenTofu](https://opentofu.org) under the hood) * [KubeVirt](./kubevirt.mdx) * [Nvidia Base Command Manager](./bcm.mdx) * [Metal3](./metal3.mdx) (bare metal provisioning via Metal3/Ironic) -Each node provider defines provider specific configuration and its node types, which then are used by the virtual clusters to choose from. +Each node provider defines provider specific configuration and its node types, which then are used by the tenant clusters to choose from. When a vCluster requests a new node it will create a new node claim, telling the platform to create a new node with the given requirements. The platform will then match these requirements to the cheapest available node type and consequentially create a new node from that type.
diff --git a/platform/administer/node-providers/terraform.mdx b/platform/administer/node-providers/terraform.mdx index c425e5bfb4..6e79a84bcb 100644 --- a/platform/administer/node-providers/terraform.mdx +++ b/platform/administer/node-providers/terraform.mdx @@ -141,7 +141,7 @@ Besides the user-defined credentials specified below, the platform passes a `var * `var.vcluster.namespace`: Project namespace of the vCluster instance * `var.vcluster.userData`: The [cloud-init script](https://cloud-init.io/) generated that should be passed to the instance to join the node into the vCluster * `var.vcluster.requirements`: A key-value map of the specified and resolved requirements of the node claim -* `var.vcluster.instance`: Full virtual cluster instance object +* `var.vcluster.instance`: Full tenant cluster instance object * `var.vcluster.nodeClaim`: Full node claim object * `var.vcluster.nodeType`: Full node type object * `var.vcluster.nodeEnvironment.outputs`: If a node environment was specified for this provider, the defined outputs of the node environment @@ -247,7 +247,7 @@ Besides the user-defined credentials specified below, the platform passes a `var * `var.vcluster.name`: Name of the vCluster * `var.vcluster.namespace`: Project namespace of the vCluster * `var.vcluster.requirements`: A key-value map of the specified and resolved requirements of the first node claim used to create this node environment -* `var.vcluster.instance`: Full virtual cluster instance object +* `var.vcluster.instance`: Full tenant cluster instance object * `var.vcluster.nodeEnvironment`: Full node environment object ## Credentials diff --git a/platform/administer/projects/allowed/templates.mdx b/platform/administer/projects/allowed/templates.mdx index 4d728eed05..4f929dc798 100644 --- a/platform/administer/projects/allowed/templates.mdx +++ b/platform/administer/projects/allowed/templates.mdx @@ -13,28 +13,28 @@ Allowed templates are the templates that project members are allowed to use when ## Security best practices -By default, vCluster Platform requires templates for non-admin users to create virtual clusters. This default exists because creating virtual clusters without templates can pose security risks. +By default, vCluster Platform requires templates for non-admin users to create tenant clusters. This default exists because creating tenant clusters without templates can pose security risks. :::warning Why templates matter for security -When users create virtual clusters without a template, they have full control over the vCluster configuration. Misconfigured settings can allow users to: -- Access host cluster resources they should not have access to through sync settings -- Sync sensitive resources from the host cluster into the virtual cluster +When users create tenant clusters without a template, they have full control over the vCluster configuration. Misconfigured settings can allow users to: +- Access control plane cluster resources they should not have access to through sync settings +- Sync sensitive resources from the control plane cluster into the tenant cluster - Create resources in the host namespace that affect other workloads - Deploy arbitrary resources to the host namespace using [`experimental.deploy.host`](/docs/vcluster/configure/vcluster-yaml/experimental/deploy), which inherits the platform's permissions and can create role bindings or cluster role bindings -- Access the host namespace through [Namespace Objects and Namespace Apps](/docs/platform/use-platform/namespaces/key-features/isolation#configure-namespace-objects), which deploy resources directly to the host cluster +- Access the host namespace through [Namespace Objects and Namespace Apps](/docs/platform/use-platform/namespaces/key-features/isolation#configure-namespace-objects), which deploy resources directly to the control plane cluster ::: ### Recommendations -1. **Keep templates required**: The default `requireTemplate` setting ensures non-admin users can only create virtual clusters from pre-approved templates. Do not disable this setting unless you trust all project members with full vCluster configuration access. +1. **Keep templates required**: The default `requireTemplate` setting ensures non-admin users can only create tenant clusters from pre-approved templates. Do not disable this setting unless you trust all project members with full vCluster configuration access. 2. **Use hardened templates**: Configure templates with restricted sync settings. See [security hardening](../../templates/create-templates.mdx#security-hardening) for guidance on creating secure templates. 3. **Review allowed templates carefully**: Only add templates to a project that have been reviewed for security implications. Avoid using "All Templates" unless all available templates are appropriately secured. -4. **Limit admin access**: Only grant project admin or platform admin roles to users who need the ability to create virtual clusters without templates. +4. **Limit admin access**: Only grant project admin or platform admin roles to users who need the ability to create tenant clusters without templates. ## Add templates @@ -116,23 +116,23 @@ name `my-project-space-1` being created for the space instance named `space-1` f -### Available variables for virtual clusters +### Available variables for tenant clusters The variables available for templating `namespacePattern.virtualCluster` are: - `.Values.loft.user.name`: The name of the owner, if the owner is a user - `.Values.loft.team.name`: The name of the owner, if the owner is a team -- `.Values.loft.name`: The name of the space or virtual cluster instance +- `.Values.loft.name`: The name of the space or tenant cluster instance - `.Values.loft.project`: The name of the project -- `.Values.loft.space`: The name of the space containing the virtual cluster +- `.Values.loft.space`: The name of the space containing the tenant cluster - `.Values.loft.cluster`: The name of the connected cluster the space is scheduled to -- `.Values.loft.virtualClusterName`: The name of the virtual cluster -- `.Values.loft.virtualClusterNamespace`: The name of the space containing the virtual cluster +- `.Values.loft.virtualClusterName`: The name of the tenant cluster +- `.Values.loft.virtualClusterNamespace`: The name of the space containing the tenant cluster ### Available variables for spaces The variables available for templating `namespacePattern.space` are: - `.Values.loft.user.name`: The name of the owner, if the owner is a user - `.Values.loft.team.name`: The name of the owner, if the owner is a team -- `.Values.loft.name`: The name of the space or virtual cluster instance +- `.Values.loft.name`: The name of the space or tenant cluster instance - `.Values.loft.project`: The name of the project - `.Values.loft.cluster`: The name of the connected cluster the space is scheduled to diff --git a/platform/administer/projects/create.mdx b/platform/administer/projects/create.mdx index e841594987..c741acdc7f 100644 --- a/platform/administer/projects/create.mdx +++ b/platform/administer/projects/create.mdx @@ -13,7 +13,7 @@ import Link from "@docusaurus/Link"; To get started creating a Project, in the vCluster Platform UI: :::info Security recommendation -Keep templates required for projects where non-admin users create virtual clusters. This prevents users from configuring sync settings that could grant elevated access to host cluster resources. See security best practices for more information. +Keep templates required for projects where non-admin users create tenant clusters. This prevents users from configuring sync settings that could grant elevated access to control plane cluster resources. See security best practices for more information. ::: diff --git a/platform/administer/projects/quotas.mdx b/platform/administer/projects/quotas.mdx index ecbe5d6aeb..5786085daa 100644 --- a/platform/administer/projects/quotas.mdx +++ b/platform/administer/projects/quotas.mdx @@ -17,8 +17,8 @@ import FeatureTable from '@site/src/components/FeatureTable'; Quotas allow you to set resource usage and count limits for the project. This works similarly to Kubernetes `ResourcesQuotas`, but applies across multiple clusters. Quotas can be defined across the whole project or on a per-user/per-team basis. -:::info Project quotas with multiple virtual clusters -Please be aware that when you create multiple virtual cluster instances, the individually used resources count toward the shared project quota. +:::info Project quotas with multiple tenant clusters +When you create multiple tenant cluster instances, the individually used resources count toward the shared project quota. ::: ## Quotas on Active Resources @@ -70,8 +70,8 @@ Users may be able to exceed the quota by small amounts by simultaneously creatin ## Adding Quotas for a User/Team When using a quota for a user or team, it applies to **all** users or teams in the project and cannot -be applied to specific users and teams. For example, this project defines a total virtual cluster instance quota of 20, but -prevents any user or team from using more than 5 virtual cluster. By adjusting these quotas, you can ensure that no user or +be applied to specific users and teams. For example, this project defines a total tenant cluster instance quota of 20, but +prevents any user or team from using more than 5 tenant cluster. By adjusting these quotas, you can ensure that no user or team uses more than their fair share of cluster resources. @@ -102,7 +102,7 @@ team uses more than their fair share of cluster resources. :::note Team and Team Member Quotas -If a team is the owner of a space or virtual cluster, the usage will be counted by the team and not count against +If a team is the owner of a space or tenant cluster, the usage will be counted by the team and not count against each member of the team, nor will the usage of a team member count towards the team's quota. ::: diff --git a/platform/administer/secrets/global/create.mdx b/platform/administer/secrets/global/create.mdx index d09cb767d4..c93d572475 100644 --- a/platform/administer/secrets/global/create.mdx +++ b/platform/administer/secrets/global/create.mdx @@ -9,10 +9,10 @@ import Button from "@site/src/components/Button"; import Label from "@site/src/components/Label"; import NavStep from "@site/src/components/NavStep"; -Global Secrets allow you to define and share secrets for virtual clusters and spaces across all registered clusters. Native Kubernetes secrets that reference these global secrets can then be created and vCluster Platform will synchronize the secret's data with the global secret. +Global Secrets allow you to define and share secrets for tenant clusters and spaces across all registered clusters. Native Kubernetes secrets that reference these global secrets can then be created and vCluster Platform will synchronize the secret's data with the global secret. -:::note Space secrets, but not Virtual Cluster secrets -Global secrets are not synchronized to secrets created within virtual clusters, however project secrets are. To use a global secret to manage secret data in virtual clusters, you can first create a project secret that is synchronized by a global secret. +:::note Space secrets, but not Tenant Cluster secrets +Global secrets are not synchronized to secrets created within tenant clusters, however project secrets are. To use a global secret to manage secret data in tenant clusters, you can first create a project secret that is synchronized by a global secret. ::: ## Create a Global Secret diff --git a/platform/administer/secrets/project/create.mdx b/platform/administer/secrets/project/create.mdx index dd5a98b3b5..faf82515db 100644 --- a/platform/administer/secrets/project/create.mdx +++ b/platform/administer/secrets/project/create.mdx @@ -10,7 +10,7 @@ import Label from "@site/src/components/Label"; import NavStep from "@site/src/components/NavStep"; Project secrets allow you to define and share secrets across the allowed clusters -where namespace and virtual cluster instances of the project are deployed. There are two ways to utilize project secrets: +where namespace and tenant cluster instances of the project are deployed. There are two ways to utilize project secrets: 1. Create project secrets and populate it with its own secret data. 2. Create a project secret that syncs with a shared secret. diff --git a/platform/administer/templates/create-templates.mdx b/platform/administer/templates/create-templates.mdx index 1e9b189511..f2196382e1 100644 --- a/platform/administer/templates/create-templates.mdx +++ b/platform/administer/templates/create-templates.mdx @@ -13,7 +13,7 @@ import NavStep from "@site/src/components/NavStep"; import PartialVirtualClusterCreateOptionalTemplateUI from "../../_partials/vcluster/create-ui-optional-fields-template.mdx"; -Templates standardize virtual cluster, namespace, and app configurations. Create templates through the vCluster Platform UI or by applying manifests directly to your cluster. +Templates standardize tenant cluster, namespace, and app configurations. Create templates through the vCluster Platform UI or by applying manifests directly to your cluster.
@@ -24,18 +24,18 @@ You can create templates directly in the UI:
- + In the vCluster Platform, select Templates from the left menu. - From the **Templates** menu, select the Virtual Clusters option. + From the **Templates** menu, select the Tenant Clusters option. - Click **Add Virtual Cluster Template**. + Click **Add Tenant Cluster Template**. - Provide your virtual cluster template with a name by replacing the `my-template` placeholder name, or by + Provide your tenant cluster template with a name by replacing the `my-template` placeholder name, or by updating the manifest YAML `metadata.name` field. @@ -51,7 +51,7 @@ You can create templates directly in the UI: -Apps are Helm charts, Kubernetes manifests, or bash scripts that define an application to be deployed into a cluster, namespace, or virtual cluster. +Apps are Helm charts, Kubernetes manifests, or bash scripts that define an application to be deployed into a cluster, namespace, or tenant cluster. App templates can be created through the UI. @@ -64,7 +64,7 @@ App templates can be created through the UI. Click . - Provide your virtual cluster template with a name by replacing the `my-template` placeholder name, or by + Provide your tenant cluster template with a name by replacing the `my-template` placeholder name, or by updating the manifest YAML `metadata.name` field. @@ -97,7 +97,7 @@ Namespace templates can be created directly in the UI to define default labels, Click **Add Namespace Template** . - Provide your virtual cluster template with a name by replacing the `my-template` placeholder name, or by + Provide your tenant cluster template with a name by replacing the `my-template` placeholder name, or by updating the manifest YAML `metadata.name` field. @@ -149,7 +149,7 @@ For example, to create a `VirtualClusterTemplate` manifest: -#### Example virtual cluster manifest +#### Example tenant cluster manifest ```yaml apiVersion: management.loft.sh/v1 @@ -223,7 +223,7 @@ spec: ## Configure template options {#template-configuration-options} -Templates include configuration sections that define behavior, content, and access. The following options apply to both virtual cluster templates and namespace templates. +Templates include configuration sections that define behavior, content, and access. The following options apply to both tenant cluster templates and namespace templates. ### Template parameters @@ -235,16 +235,16 @@ Parameters can include validation rules such as allowed options, required fields ### Apps and objects -The **Apps** section lets you select pre-built applications that install automatically when virtual clusters are created from the template. Choose from available apps such as ArgoCD, Prometheus Stack, Ingress controllers, or custom applications specific to your organization. +The **Apps** section lets you select pre-built applications that install automatically when tenant clusters are created from the template. Choose from available apps such as ArgoCD, Prometheus Stack, Ingress controllers, or custom applications specific to your organization. -Selected apps deploy immediately after virtual cluster creation. Development teams have required tools and services available without manual installation. This approach standardizes the application stack across virtual clusters. It also reduces setup time for development teams. +Selected apps deploy immediately after tenant cluster creation. Development teams have required tools and services available without manual installation. This approach standardizes the application stack across tenant clusters. It also reduces setup time for development teams. -The **Objects** section defines Kubernetes manifests that are applied during virtual cluster creation. These include ConfigMaps, Secrets, NetworkPolicies, or custom ClusterRoles that establish baseline configurations. For an example of injecting a custom ClusterRole to control in-cluster permissions, see [Custom ClusterRoles](../users-permissions/permissions/vcluster.mdx#custom-clusterroles). +The **Objects** section defines Kubernetes manifests that are applied during tenant cluster creation. These include ConfigMaps, Secrets, NetworkPolicies, or custom ClusterRoles that establish baseline configurations. For an example of injecting a custom ClusterRole to control in-cluster permissions, see [Custom ClusterRoles](../users-permissions/permissions/vcluster.mdx#custom-clusterroles). ### Management access -Management access defines who can view, edit, or delete the template. It applies to the template itself, not to the virtual clusters created from it. +Management access defines who can view, edit, or delete the template. It applies to the template itself, not to the tenant clusters created from it. You can assign an owner with full permissions and grant view-only or full-access roles to other users or teams. This ensures that only authorized administrators can modify templates while allowing teams to use them for deployment. @@ -255,11 +255,11 @@ The access model follows role-based access control (RBAC) to prevent unauthorize If a template is outdated, misconfigured, or no longer needed, you can remove it to keep your workspace clean and reduce confusion for users. Deleting a template removes it from the platform and prevents it from being used for future cluster creation. -This does not affect any virtual clusters or resources that were already created from the template. +This does not affect any tenant clusters or resources that were already created from the template. :::warning Delete a template -If you delete a template, any virtual cluster, app, or namespace that references it can no longer be edited or upgraded through the Platform UI’s form-based editor. +If you delete a template, any tenant cluster, app, or namespace that references it can no longer be edited or upgraded through the Platform UI’s form-based editor. To make changes, you must manually update the corresponding custom resource, by making direct edits to the relevant CustomResourceDefinition (CRD). ::: @@ -283,19 +283,19 @@ To make changes, you must manually update the corresponding custom resource, by ## Security hardening -When creating templates for production environments, configure sync settings to prevent users from gaining unintended access to host cluster resources. +When creating templates for production environments, configure sync settings to prevent users from gaining unintended access to control plane cluster resources. ### Restrict sync configurations -The vCluster sync configuration determines which resources are shared between the virtual cluster and host cluster. Unrestricted sync settings can allow users to: +The vCluster sync configuration determines which resources are shared between the tenant cluster and control plane cluster. Unrestricted sync settings can allow users to: -- Access secrets or configmaps from the host cluster +- Access secrets or configmaps from the control plane cluster - Create resources in the host namespace that affect other workloads - Sync custom resources that grant elevated permissions ### Hardened template example -The following sync configuration restricts what can be synced to and from the host cluster: +The following sync configuration restricts what can be synced to and from the control plane cluster: ```yaml title="Hardened sync configuration" helmRelease: @@ -320,7 +320,7 @@ helmRelease: ### Policy enforcement -Use the `policies` section to enforce security standards within the virtual cluster: +Use the `policies` section to enforce security standards within the tenant cluster: ```yaml title="Security policies" helmRelease: @@ -346,9 +346,9 @@ For more information on vCluster configuration options, see the [vCluster config ## Examples
-Virtual cluster template +Tenant cluster template -The following template creates a virtual cluster with ResourceQuota and LimitRange objects to control resource usage. It configures persistent storage, includes RBAC rules for operational tasks, and enables ingress support for apps. +The following template creates a tenant cluster with ResourceQuota and LimitRange objects to control resource usage. It configures persistent storage, includes RBAC rules for operational tasks, and enables ingress support for apps. ```yaml title="Template" apiVersion: management.loft.sh/v1 @@ -554,7 +554,7 @@ spec:
-Argo CD virtual cluster template +Argo CD tenant cluster template The following template automatically installs Argo CD with ApplicationSet controller and configures TLS-enabled ingress with team-based RBAC. It includes scheduled auto sleep, enterprise features with embedded etcd and CoreDNS, and provides custom links for quick access to Argo CD UI and GitOps repository. @@ -701,7 +701,7 @@ spec:
-Parameterized virtual cluster template +Parameterized tenant cluster template The following template demonstrates parameters for auto sleep timeout and Kubernetes version selection during deployment. Users can choose from predefined options with default values, and the template uses embedded etcd and CoreDNS for resource efficiency. @@ -778,7 +778,7 @@ spec:
-Versioned virtual cluster template +Versioned tenant cluster template The following template demonstrates versioning with a default base template and versioned variations. Version 1.0.0 includes enhanced features such as auto sleep configuration, custom links to Helm Dashboard, pre-installed helm-dashboard app, and user-configurable parameters for Kubernetes version and environment selection. diff --git a/platform/administer/templates/overview.mdx b/platform/administer/templates/overview.mdx index d80917f68c..c1c30a8e61 100644 --- a/platform/administer/templates/overview.mdx +++ b/platform/administer/templates/overview.mdx @@ -14,28 +14,28 @@ import NavStep from "@site/src/components/NavStep"; # Templates overview -Templates define reusable configurations for creating virtual clusters, applications, and namespaces. They allow platform teams to standardize resource provisioning while giving users a controlled way to customize certain settings. Templates are implemented using Kubernetes custom resources (`VirtualClusterTemplate`, `AppTemplate`, and `SpaceTemplate`) and can be managed with tools such as `kubectl`, Helm, or ArgoCD. +Templates define reusable configurations for creating tenant clusters, applications, and namespaces. They allow platform teams to standardize resource provisioning while giving users a controlled way to customize certain settings. Templates are implemented using Kubernetes custom resources (VirtualClusterTemplate, AppTemplate, and SpaceTemplate) and can be managed with tools such as `kubectl`, Helm, or ArgoCD. -Each template type serves a specific purpose. Virtual cluster templates define the base configuration for virtual clusters, including the Kubernetes version, control plane, networking, storage settings, and sync behavior. App templates provide reusable application configurations using Helm charts or Kubernetes manifests. Namespace templates predefine configurations for new namespaces, including role-based access control, resource quotas, and labels. +Each template type serves a specific purpose. Tenant cluster templates define the base configuration for tenant clusters, including the Kubernetes version, control plane, networking, storage settings, and sync behavior. App templates provide reusable application configurations using Helm charts or Kubernetes manifests. Namespace templates predefine configurations for new namespaces, including role-based access control, resource quotas, and labels. Templates allow team administrators to define which settings users can modify through parameters. For example, you can expose only specific fields, such as the number of replicas or a set of approved storage classes, while keeping the rest of the configuration fixed. This approach reduces the risk of misconfiguration, while enabling flexibility, and helps with security. -Virtual cluster and app templates can include pre-installed components, such as monitoring agents or ingress controllers. Additional Kubernetes resources like ConfigMaps, RBAC, or [NetworkPolicies](/vcluster/configure/vcluster-yaml/policies/network-policy) can be applied to either the host cluster or the virtual cluster itself. +Tenant cluster and app templates can include pre-installed components, such as monitoring agents or ingress controllers. Additional Kubernetes resources like ConfigMaps, RBAC, or [NetworkPolicies](/vcluster/configure/vcluster-yaml/policies/network-policy) can be applied to either the control plane cluster or the tenant cluster itself. Because templates can be versioned, they support upgrade workflows. When a template is updated, those changes can be manually or automatically propagated to any resources based on it. This allows teams to configure and update clusters, applications, and namespaces in a repeatable way across multiple environments. ## Template types -vCluster Platform includes templates for virtual clusters, applications, and namespaces. +vCluster Platform includes templates for tenant clusters, applications, and namespaces.
| Template type | Custom resource | Purpose | Common Use Cases | | ---------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -| Virtual cluster | `VirtualClusterTemplate` | Specifies how virtual clusters are provisioned, including control plane settings, synchronization behavior, and metadata. | Provision virtual clusters with consistent architecture, features, and default settings. | -| App | `AppTemplate` | Defines reusable application configurations, such as Helm charts or Kubernetes manifests . | Deploy standard applications across projects or spaces using consistent settings. | -| Namespace | `SpaceTemplate` | Predefines configurations for new namespaces, including role-based access control, resource quotas, and labels. | Automatically apply baseline policies when a namespace is created. | +| Tenant cluster | VirtualClusterTemplate | Specifies how tenant clusters are provisioned, including control plane settings, synchronization behavior, and metadata. | Provision tenant clusters with consistent architecture, features, and default settings. | +| App | AppTemplate | Defines reusable application configurations, such as Helm charts or Kubernetes manifests . | Deploy standard applications across projects or spaces using consistent settings. | +| Namespace | SpaceTemplate | Predefines configurations for new namespaces, including role-based access control, resource quotas, and labels. | Automatically apply baseline policies when a namespace is created. |
@@ -48,7 +48,7 @@ Templates support optional parameterization and versioning. Optionally, you can - [Parameters](/docs/platform/next/administer/templates/parameters) - Enable dynamic customization of template fields, allowing users to specify values for CPU limits, labels, environment types, and other configuration options during vCluster provisioning. -- [Versioning](/docs/platform/next/administer/templates/versioning) - Manage and iterate template configurations across different releases, providing version control for your cluster templates. It allows for automatic updates for virtual clusters based on versioned templates. Templates without versions do not support automatic updates. +- [Versioning](/docs/platform/next/administer/templates/versioning) - Manage and iterate template configurations across different releases, providing version control for your cluster templates. It allows for automatic updates for tenant clusters based on versioned templates. Templates without versions do not support automatic updates. ## Next steps diff --git a/platform/administer/templates/parameters.mdx b/platform/administer/templates/parameters.mdx index fae3cd6d05..4f32ae05be 100644 --- a/platform/administer/templates/parameters.mdx +++ b/platform/administer/templates/parameters.mdx @@ -7,9 +7,9 @@ import Flow, { Step } from "@site/src/components/Flow"; # Parameters -Template parameters enable customization of virtual cluster templates. Platform administrators define a set of parameters that expose specific fields to users during virtual cluster creation. These parameters allow customization of values like replica counts, image tags, or ingress domains without granting access to the full configuration. +Template parameters enable customization of tenant cluster templates. Platform administrators define a set of parameters that expose specific fields to users during tenant cluster creation. These parameters allow customization of values like replica counts, image tags, or ingress domains without granting access to the full configuration. -When a user creates a virtual cluster from a parameterized template, the platform presents a form that collects values for each parameter. These values are injected into the rendered configuration using Go templating syntax (`{{ .Values.parameterName }}`). +When a user creates a tenant cluster from a parameterized template, the platform presents a form that collects values for each parameter. These values are injected into the rendered configuration using Go templating syntax (`{{ .Values.parameterName }}`). This provides some flexibility within defined boundaries. You can adjust some behaviors, such as increasing memory requests or enabling optional apps, while platform teams can still retain control over foundational settings like network configuration, cluster version, and permissions. @@ -40,7 +40,7 @@ Templates support basic parameter types for collecting user input during cluster ### Validation options -You can apply validation rules to ensure that users provide valid, safe, and expected input when filling out template parameters. These rules improve consistency and reduce configuration errors during virtual cluster creation. +You can apply validation rules to ensure that users provide valid, safe, and expected input when filling out template parameters. These rules improve consistency and reduce configuration errors during tenant cluster creation. - **Required fields**: Mark a parameter as required to prevent users from submitting the form without entering a value. This is useful for mandatory inputs like cluster names or resource sizes. @@ -395,9 +395,9 @@ The platform automatically provides built-in parameter values based on the deplo | ----------------------- | ------------------------- | -------------------------------------------- | | Project | `project` | Name of the project that owns the deployment | | Space | `space` | Name of the space (if applicable) | -| VirtualCluster | `virtualClusterName` | Name of the virtual cluster (if applicable) | +| VirtualCluster | `virtualClusterName` | Name of the tenant cluster (if applicable) | | Cluster | `cluster` | Name of the physical Kubernetes cluster | -| VirtualClusterNamespace | `virtualClusterNamespace` | Namespace of the virtual cluster | +| VirtualClusterNamespace | `virtualClusterNamespace` | Namespace of the tenant cluster | You can access these platform-specific values in your template: @@ -408,9 +408,9 @@ labels: cluster: "{{ .Values.loft.cluster }}" ``` -### Connected host cluster parameter values +### Connected control plane cluster parameter values -In addition to Platform-specific parameter values, annotations on the Platform connected host cluster `Cluster` resource are available under the `loft.clusterAnnotations` key for the `clusterRef.cluster` selected to deploy the virtual cluster instance. +In addition to Platform-specific parameter values, annotations on the Platform connected control plane cluster `Cluster` resource are available under the `loft.clusterAnnotations` key for the `clusterRef.cluster` selected to deploy the tenant cluster instance. You can access these `loft.clusterAnnotations` based values in your template. A `Cluster` resource annotation of `example.vcluster.com/timezone: America/New_York` might be used as follows: diff --git a/platform/administer/templates/versioning.mdx b/platform/administer/templates/versioning.mdx index a667f7ee09..2053e6a288 100644 --- a/platform/administer/templates/versioning.mdx +++ b/platform/administer/templates/versioning.mdx @@ -13,19 +13,19 @@ import FeatureTable from '@site/src/components/FeatureTable'; -Versioning a template allows you to make changes over time to a template while retaining the current version/iteration. Resources (for example virtual clusters, namespaces) that are deployed with templates that have updated versions show up with a warning +Versioning a template allows you to make changes over time to a template while retaining the current version/iteration. Resources (for example tenant clusters, namespaces) that are deployed with templates that have updated versions show up with a warning indicating that a newer template version is available. ## Template version strings -When creating a virtual cluster from a template, you can specify a template version string. If omitted, the latest available version is selected by default. +When creating a tenant cluster from a template, you can specify a template version string. If omitted, the latest available version is selected by default. -You can use the `X` wildcard in the major, minor, or patch components of the version string to enable automatic upgrades. This allows virtual clusters to automatically update to newer compatible versions of the template. +You can use the `X` wildcard in the major, minor, or patch components of the version string to enable automatic upgrades. This allows tenant clusters to automatically update to newer compatible versions of the template. For example given a template version `1.0.0`: -- If you set the version string to `1.X.X`, and a new template version `1.1.0` is added, the virtual cluster will automatically upgrade to `1.1.0`. -- If a version `2.0.0` is added instead, the virtual cluster is not upgraded, because the major version does not match. +- If you set the version string to `1.X.X`, and a new template version `1.1.0` is added, the tenant cluster will automatically upgrade to `1.1.0`. +- If a version `2.0.0` is added instead, the tenant cluster is not upgraded, because the major version does not match. To always upgrade to the latest available version, you can `X.X.X` as the version string. diff --git a/platform/administer/users-permissions/managing-teams/create.mdx b/platform/administer/users-permissions/managing-teams/create.mdx index c46958be29..9db880cbe2 100644 --- a/platform/administer/users-permissions/managing-teams/create.mdx +++ b/platform/administer/users-permissions/managing-teams/create.mdx @@ -95,7 +95,7 @@ Teams in the platform integrate directly with Kubernetes Role-Based Access Contr 1. The platform creates corresponding RBAC objects in the underlying Kubernetes cluster. 2. Any cluster roles assigned to the team automatically apply to all team members. -3. Team memberships propagate to all virtual clusters managed by the platform. +3. Team memberships propagate to all tenant clusters managed by the platform. This integration means that teams defined in vCluster platform affect permissions across all managed environments while maintaining Kubernetes-native security controls. diff --git a/platform/administer/users-permissions/managing-users/impersonate.mdx b/platform/administer/users-permissions/managing-users/impersonate.mdx index 93e63857e0..96c498a1ff 100644 --- a/platform/administer/users-permissions/managing-users/impersonate.mdx +++ b/platform/administer/users-permissions/managing-users/impersonate.mdx @@ -190,9 +190,9 @@ cluster: :::tip Next Steps With access to a cluster, users can typically: -- **[Create Virtual Clusters](../../../use-platform/virtual-clusters/create/create-no-template.mdx)** +- **[Create Tenant Clusters](../../../use-platform/virtual-clusters/create/create-no-template.mdx)** vCluster Platform allows you to: -- **[Configure sleep mode for virtual clusters](/docs/vcluster/next/configure/vcluster-yaml/sleep)** +- **[Configure sleep mode for tenant clusters](/docs/vcluster/next/configure/vcluster-yaml/sleep)** ::: diff --git a/platform/administer/users-permissions/managing-users/suspend.mdx b/platform/administer/users-permissions/managing-users/suspend.mdx index 875aa0e66e..108e84e591 100644 --- a/platform/administer/users-permissions/managing-users/suspend.mdx +++ b/platform/administer/users-permissions/managing-users/suspend.mdx @@ -10,7 +10,7 @@ import Button from "@site/src/components/Button"; import Label from "@site/src/components/Label"; Users can be locked, to temporarily suspend their access to vCluster Platform. By doing so, the user won't be -able to login or access any spaces / virtual clusters anymore. Access keys generated for the +able to login or access any spaces / tenant clusters anymore. Access keys generated for the user won't work anymore as long as the user is locked. This is a useful feature to temporarily lock an user if you want to preserve the users environments without deleting the user. diff --git a/platform/administer/users-permissions/permissions/namespace.mdx b/platform/administer/users-permissions/permissions/namespace.mdx index 0eb2d8433c..fe198caed1 100644 --- a/platform/administer/users-permissions/permissions/namespace.mdx +++ b/platform/administer/users-permissions/permissions/namespace.mdx @@ -14,7 +14,7 @@ import PartialNamespaceShareCLI from '../../../_partials/namespace/share-cli.mdx Namespace access can be managed through the 'Permissions' section inside the namespace drawer. There are a couple of special cases: 1. Global Loft Admins & Project Admins have access and can change **all** namespaces within a project. -2. Virtual Cluster owners always have access and can change their namespaces. +2. Tenant Cluster owners always have access and can change their namespaces. 3. Every user or team within the management cluster that has the RBAC permission on the resource "spaceinstances" in api group "management.loft.sh" for the verb "use" can access the namespace. ## How does Access within a namespace work? diff --git a/platform/administer/users-permissions/permissions/project.mdx b/platform/administer/users-permissions/permissions/project.mdx index 0838c4890e..190743cd9a 100644 --- a/platform/administer/users-permissions/permissions/project.mdx +++ b/platform/administer/users-permissions/permissions/project.mdx @@ -20,11 +20,11 @@ If you don't have a project, you can create one by following instructions [here] There are 3 default roles available for every project. -| Name | Create New Spaces / Virtual Clusters | Access Spaces / Virtual Clusters | Create Without Template | Create With Template | Access to Project Secrets | +| Name | Create New Spaces / Tenant Clusters | Access Spaces / Tenant Clusters | Create Without Template | Create With Template | Access to Project Secrets | | -------------- | ------------------------------------ | --------------------------------------- | ----------------------- | -------------------- | --------------------------------------------------- | -| Project admin | Yes | All Spaces and Virtual Clusters | Yes | Yes | Yes | +| Project admin | Yes | All Spaces and Tenant Clusters | Yes | Yes | Yes | | Project User | Yes | Only owned and with explicit permission | No | Yes | Yes | -| Project Viewer | No | Only with explicit permission | No | No | Only in Spaces and Virtual Clusters with permission | +| Project Viewer | No | Only with explicit permission | No | No | Only in Spaces and Tenant Clusters with permission | Global admins can change these existing roles as well as add new project roles in the Users section of the platform. diff --git a/platform/administer/users-permissions/permissions/vcluster.mdx b/platform/administer/users-permissions/permissions/vcluster.mdx index 65b9ee2998..51af92a8af 100644 --- a/platform/administer/users-permissions/permissions/vcluster.mdx +++ b/platform/administer/users-permissions/permissions/vcluster.mdx @@ -1,5 +1,5 @@ --- -title: Manage access to the virtual cluster +title: Manage access to the tenant cluster sidebar_label: vCluster sidebar_position: 3 @@ -12,32 +12,32 @@ import NavStep from "@site/src/components/NavStep"; import Label from "@site/src/components/Label"; import Button from "@site/src/components/Button"; -# Management access to the virtual cluster +# Management access to the tenant cluster -Management access controls who can view, edit, or configure the virtual cluster object in the platform. It is separate from in-cluster access, which governs permissions inside the Kubernetes environment of the virtual cluster. +Management access controls who can view, edit, or configure the tenant cluster object in the platform. It is separate from in-cluster access, which governs permissions inside the Kubernetes environment of the tenant cluster. ## Default management access -By default, the following users and roles have management access to a virtual cluster: +By default, the following users and roles have management access to a tenant cluster: -* **Global administrators**—Access all virtual clusters on the platform. -* **Project administrators**—Access all virtual clusters within their assigned projects. -* **Virtual cluster owners**—Automatically receive access to the specific virtual cluster they create or own. -* **Users with physical cluster permissions**—Any user or team with RBAC permissions on the underlying (physical) cluster and the `use` verb on the `virtualclusterinstances` resource in the `management.loft.sh` API group can access virtual clusters running on that cluster. +* **Global administrators**—Access all tenant clusters on the platform. +* **Project administrators**—Access all tenant clusters within their assigned projects. +* **Tenant cluster owners**—Automatically receive access to the specific tenant cluster they create or own. +* **Users with physical cluster permissions**—Any user or team with RBAC permissions on the underlying (physical) cluster and the `use` verb on the `virtualclusterinstances` resource in the `management.loft.sh` API group can access tenant clusters running on that cluster. ## Grant management access using the UI -To extend access to additional users or teams, use the **Permissions** section for each virtual cluster in the platform UI: +To extend access to additional users or teams, use the **Permissions** section for each tenant cluster in the platform UI: - Open the **Project** dropdown in the top-left corner and select the project that contains the virtual cluster. + Open the **Project** dropdown in the top-left corner and select the project that contains the tenant cluster. - Click **Virtual Clusters** in the sidebar to view the list. + Click **Tenant Clusters** in the sidebar to view the list. - Click **Edit** on the target virtual cluster. + Click **Edit** on the target tenant cluster. Open the **Permissions** tab. @@ -49,30 +49,30 @@ To extend access to additional users or teams, use the **Permissions** section f If the user or team does not appear, confirm that they have access to the project. - Choose a **ClusterRole** to assign (e.g., `cluster-admin`, `edit`, or `view`). This role determines the user's Kubernetes permissions inside the virtual cluster. + Choose a **ClusterRole** to assign (e.g., `cluster-admin`, `edit`, or `view`). This role determines the user's Kubernetes permissions inside the tenant cluster. Click **Save changes**. -The platform grants the selected user or team management access to the virtual cluster object. +The platform grants the selected user or team management access to the tenant cluster object. ## vCluster roles -vCluster roles define what users and teams can do inside the virtual cluster. Kubernetes RBAC governs this access. +vCluster roles define what users and teams can do inside the tenant cluster. Kubernetes RBAC governs this access. ### Default cluster role assignment -By default, the platform assigns the `cluster-admin` Kubernetes ClusterRole to users with virtual cluster access. This role grants full access in all namespaces. +By default, the platform assigns the `cluster-admin` Kubernetes ClusterRole to users with tenant cluster access. This role grants full access in all namespaces. ### Change the default cluster role -Administrators can override the default role in the virtual cluster template or in the virtual cluster configuration. +Administrators can override the default role in the tenant cluster template or in the tenant cluster configuration. - Open the virtual cluster or template configuration. + Open the tenant cluster or template configuration. Locate the **Default Cluster Role** field. @@ -97,7 +97,7 @@ Use mapping rules to assign specific users or teams to specific cluster roles. - Open the virtual cluster or template YAML configuration. + Open the tenant cluster or template YAML configuration. Locate or create the `access.rules` section. @@ -143,7 +143,7 @@ In this example: - Person 1, if part of DevTeam, receives both roles. - All other users default to `cluster-admin`. -Custom mapping rules allow more precise and secure access control inside the virtual cluster. +Custom mapping rules allow more precise and secure access control inside the tenant cluster. ### Custom ClusterRoles diff --git a/platform/how-to/use-go-template.mdx b/platform/how-to/use-go-template.mdx index 5fe02e470b..dd8b8306fb 100644 --- a/platform/how-to/use-go-template.mdx +++ b/platform/how-to/use-go-template.mdx @@ -63,7 +63,7 @@ spec: parameters: cpu: "{{ .Values.cpuLimit }}" ``` -For example, You can use [connected host cluster parameter values](../administer/templates/parameters.mdx#connected-host-cluster-parameter-values) to specify the sleep mode timezone automatically: +For example, You can use [connected control plane cluster parameter values](../administer/templates/parameters.mdx#connected-control-plane-cluster-parameter-values) to specify the sleep mode timezone automatically: ```yaml sleepMode: enabled: true