From 451267310bd228b8a9cb9b048d995a70dfc34330 Mon Sep 17 00:00:00 2001 From: Nick Volynkin Date: Fri, 23 May 2025 14:36:20 +0300 Subject: [PATCH 1/2] [docs] Tenants cannot have dashes in the names Gave examples of tenant naming. Part of cozystack/cozystack#971 Signed-off-by: Nick Volynkin --- packages/apps/tenant/README.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/packages/apps/tenant/README.md b/packages/apps/tenant/README.md index f43db79a..bc33b6a3 100644 --- a/packages/apps/tenant/README.md +++ b/packages/apps/tenant/README.md @@ -4,13 +4,19 @@ A tenant is the main unit of security on the platform. The closest analogy would Tenants can be created recursively and are subject to the following rules: -### Higher-level tenants can access lower-level ones. +### Tenant naming -Higher-level tenants can view and manage the applications of all their children. +Tenant names must be alphanumeric. +Using dashes (`-`) in tenant names is not allowed, unlike with other services. +This limitation exists to keep consistent naming in tenants, nested tenants, and services deployed in them. + +For example: + +- The root tenant is named `root`, but internally it's referenced as `tenant-root`. +- A nested tenant could be named `foo`, which would result in `tenant-foo` in service names and URLs. +- However, a tenant can not be named `foo-bar`, because parsing names such as `tenant-foo-bar` would be ambiguous. -### Each tenant has its own domain -By default (unless otherwise specified), it inherits the domain of its parent with a prefix of its name, for example, if the parent had the domain `example.org`, then `tenant-foo` would get the domain `foo.example.org` by default. Kubernetes clusters created in this tenant namespace would get domains like: `kubernetes-cluster.foo.example.org` From 119d58237982a514bf10a90ba120b93336852987 Mon Sep 17 00:00:00 2001 From: Nick Volynkin Date: Fri, 23 May 2025 14:48:51 +0300 Subject: [PATCH 2/2] [docs] Review the Tenant app documentation * Brush up some formatting * Explain the relations of nested tenants in more detail Signed-off-by: Nick Volynkin --- packages/apps/tenant/README.md | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/packages/apps/tenant/README.md b/packages/apps/tenant/README.md index bc33b6a3..cc26c830 100644 --- a/packages/apps/tenant/README.md +++ b/packages/apps/tenant/README.md @@ -16,30 +16,43 @@ For example: - A nested tenant could be named `foo`, which would result in `tenant-foo` in service names and URLs. - However, a tenant can not be named `foo-bar`, because parsing names such as `tenant-foo-bar` would be ambiguous. +### Unique domains +Each tenant has its own domain. +By default, (unless otherwise specified), it inherits the domain of its parent with a prefix of its name. +For example, if the parent had the domain `example.org`, then `tenant-foo` would get the domain `foo.example.org` by default. Kubernetes clusters created in this tenant namespace would get domains like: `kubernetes-cluster.foo.example.org` Example: -``` +```text tenant-root (example.org) └── tenant-foo (foo.example.org) └── kubernetes-cluster1 (kubernetes-cluster1.foo.example.org) ``` -### Lower-level tenants can access the cluster services of their parent (provided they do not run their own) +### Nesting tenants and reusing parent services -Thus, you can create `tenant-u1` with a set of services like `etcd`, `ingress`, `monitoring`. And create another tenant namespace `tenant-u2` inside of `tenant-u1`. +Tenants can be nested. +A tenant administrator can create nested tenants using the "Tenant" application from the catalogue. + +Higher-level tenants can view and manage the applications of all their children tenants. +If a tenant does not run their own cluster services, it can access ones of its parent. + +For example, you create: +- Tenant `tenant-u1` with a set of services like `etcd`, `ingress`, `monitoring`. +- Tenant `tenant-u2` nested in `tenant-u1`. Let's see what will happen when you run Kubernetes and Postgres under `tenant-u2` namespace. -Since `tenant-u2` does not have its own cluster services like `etcd`, `ingress`, and `monitoring`, the applications will use the cluster services of the parent tenant. +Since `tenant-u2` does not have its own cluster services like `etcd`, `ingress`, and `monitoring`, +the applications running in `tenant-u2` will use the cluster services of the parent tenant. + This in turn means: -- The Kubernetes cluster data will be stored in etcd for `tenant-u1`. -- Access to the cluster will be through the common ingress of `tenant-u1`. -- Essentially, all metrics will be collected in the monitoring from `tenant-u1`, and only it will have access to them. - +- The Kubernetes cluster data will be stored in `etcd` for `tenant-u1`. +- Access to the cluster will be through the common `ingress` of `tenant-u1`. +- Essentially, all metrics will be collected in the `monitoring` from `tenant-u1`, and only that tenant will have access to them. Example: ```