3c9e50a4df
<img width="1675" alt="Screenshot 2024-12-23 at 13 40 30" src="https://github.com/user-attachments/assets/cc123697-4efd-4a4f-909c-793cec8d91bd" /> <img width="1673" alt="Screenshot 2024-12-23 at 13 40 45" src="https://github.com/user-attachments/assets/3be63e8d-9ee6-487d-90d0-3583dc968dfc" /> Signed-off-by: Andrei Kvapil <kvapss@gmail.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new `pluginConfig` section in the Kubeapps dashboard configuration for managing a broader range of applications. - **Bug Fixes** - Enhanced URL generation logic to ensure proper encoding of package identifiers. - **Chores** - Updated image digests in the configuration for both the dashboard and kubeappsapis sections. - Removed unnecessary patch application steps from the build process. - Upgraded the Go version used for building the application. - Updated the application version for the tenant package from `1.6.3` to `1.6.4`. - Added a new version `1.6.4 HEAD` for the tenant package. - Adjusted RBAC configuration to streamline permissions and enhance group-based access management. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: Andrei Kvapil <kvapss@gmail.com> Co-authored-by: klinch0 <68821526+klinch0@users.noreply.github.com>
Tenant
A tenant is the main unit of security on the platform. The closest analogy would be Linux kernel namespaces.
Tenants can be created recursively and are subject to the following rules:
Higher-level tenants can access lower-level ones.
Higher-level tenants can view and manage the applications of all their children.
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:
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)
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.
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.
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.
Example:
tenant-u1
├── etcd
├── ingress
├── monitoring
└── tenant-u2
├── kubernetes-cluster1
└── postgres-db1
Parameters
Common parameters
| Name | Description | Value |
|---|---|---|
host |
The hostname used to access tenant services (defaults to using the tenant name as a subdomain for it's parent tenant host). | "" |
etcd |
Deploy own Etcd cluster | false |
monitoring |
Deploy own Monitoring Stack | false |
ingress |
Deploy own Ingress Controller | false |
seaweedfs |
Deploy own SeaweedFS | false |
isolated |
Enforce tenant namespace with network policies | false |