ClearML/clearml-docs
1
0
Fork 0
mirror of https://github.com/clearml/clearml-docs synced 2025-06-12 09:32:12 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update multi-tenant setup guide

Browse Source
This commit is contained in:
revital 2025-05-26 10:05:15 +03:00
parent 54229b2be3
commit 37f938ba01
1 changed files with 144 additions and 157 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

301
docs/deploying_clearml/enterprise_deploy/multi_tenant_k8s.md
View File

@ -4,22 +4,9 @@ title: Multi-Tenant Service on Kubernetes
This guide provides step-by-step instructions for installing a ClearML multi-tenant service on a Kubernetes cluster.
Ready, missing links in TODOs
---
TODO:
Control Plane:
- Link: SSO login
- Additional envs for control-plane multi-tenancy
## ClearML Server
Workers:
- Link: basic Agent installation
- Link: basic AI App Gateway installation
---
## Control Plane
For installing the ClearML control-plane, follow [this guide](k8s.md).
To install the ClearML Server, follow the [ClearML Kubernetes Installation guide](k8s.md).
Update the Server's `clearml-values.override.yaml` with the following values:
@ -50,25 +37,22 @@ apiserver:
value: "true"
```
The credentials specified in `<SUPERVISOR_USER_KEY>` and `<SUPERVISOR_USER_SECRET>` can be used to log in as the
supervisor user from the ClearML Web UI accessible using the URL `app.<BASE_DOMAIN>`.
The `<SUPERVISOR_USER_KEY>` and `<SUPERVISOR_USER_SECRET>` can be used to log in as the
supervisor user from the ClearML Web UI via `app.<BASE_DOMAIN>`.
Note that the `<SUPERVISOR_USER_EMAIL>` value must be explicitly quoted. To do so, put `\"` around the quoted value.
Example `"\"email@example.com\""`.
You will want to configure SSO as well. For this, follow the [SSO (Identity Provider) Setup guide](extra_configs/sso_login.md).
For configuring SSO, see the [SSO (Identity Provider) Setup guide](extra_configs/sso_login.md).
### Create a Tenant
The following section will address the steps required to create a new tenant in the ClearML Server using a series of API
calls.
This section explains how to create a new tenant (company) in the ClearML Server using the ClearML API.
Note that placeholders (`<PLACEHOLDER>`) in the following configuration should be substituted with a valid domain based
on your installation values.
#### Create a New Tenant in the ClearML Control-plane
* Define variables to use in the next steps:*
* **Define variables to use in the next steps:**
```bash
APISERVER_URL="https://api.<BASE_DOMAIN>"
@ -76,11 +60,11 @@ on your installation values.
APISERVER_SECRET="<APISERVER_SECRET>"
```
:::note
The apiserver key and secret should be the same as those used for installing the ClearML Enterprise server Chart.
:::
:::note
The apiserver key and secret should be the same as those used for installing the ClearML Enterprise Server Chart.
:::
*Create a Tenant (company):*
* **Create a Tenant (company):**
```bash
curl $APISERVER_URL/system.create_company \
@ -89,15 +73,15 @@ The apiserver key and secret should be the same as those used for installing the
-d '{"name":"<TENANT_NAME>"}'
```
The result returns the new Company ID (`<COMPANY_ID>`).
The result returns the new Company ID (`<COMPANY_ID>`).
If needed, list existing tenants (companies) using:
To view existing tenants:
```bash
curl -u $APISERVER_KEY:$APISERVER_SECRET $APISERVER_URL/system.get_companies
```
*Create an Admin User for the new tenant:*
* **Create an Admin User for the Tenant:**
```bash
curl $APISERVER_URL/auth.create_user \
@ -106,9 +90,9 @@ If needed, list existing tenants (companies) using:
-d '{"name":"<ADMIN_USER_NAME>","company":"<COMPANY_ID>","email":"<ADMIN_USER_EMAIL>","role":"admin","internal":"true"}'
```
The result returns the new User ID (`<USER_ID>`).
The result returns the new User ID (`<USER_ID>`).
*Create Credentials for the new Admin User:*
* **Create Credentials for the new Admin User:**
```bash
curl $APISERVER_URL/auth.create_credentials \
@ -117,21 +101,24 @@ The result returns the new User ID (`<USER_ID>`).
-u $APISERVER_KEY:$APISERVER_SECRET
```
The result returns a set of key and secret credentials associated with the new Admin User.
The result returns a set of key and secret credentials associated with the new Admin User.
:::note
You can use this set of credentials to set up an Agent or App Gateway for the newly created Tenant.
:::
:::note
You can use this set of credentials to set up a [ClearML Agent](agent_k8s.md) or [App Gateway](appgw.md) for the new Tenant.
:::
#### Create IDP/SSO Sign-in Rules
To map new users signing into the system to existing tenants, you can use one or more of the following route methods to route new users (based on their email address) to an existing tenant.
You can configure how new users are assigned to tenants upon first signing in to the system using one or more of the
following methods:
*Route an email to a tenant based on the email's domain:*
* **Route an email to a tenant based on the email's domain:**
This will instruct the server to assign any new user whose email domain matches the domain provided below to this specific tenant.
Automatically assign new users to a tenant based on their email domain.
Note that providing the same domain name for multiple tenants will result in unstable behavior and should be avoided.
:::caution
Note that providing the same domain name for multiple tenants will result in unstable behavior and should be avoided.
:::
```bash
curl $APISERVER_URL/login.set_domains \
@ -141,49 +128,57 @@ Note that providing the same domain name for multiple tenants will result in uns
-d '{"domains":["<USERS_EMAIL_DOMAIN>"]}'
```
`<USERS_EMAIL_DOMAIN>` is the email domain set up for users to access through SSO.
* `<USERS_EMAIL_DOMAIN>` is the email domain set up for users to access through SSO.
* All new users with matching domains will be routed to the associated tenant.
*Route specific email(s) to a tenant:*
* **Route specific email(s) to a tenant:**
This will instruct the server to assign any new user whose email is found in this list to this specific tenant. You can use the is_admin property to choose whether these users will be set as admins in this tenant upon login.
Assign specific email addresses to a tenant. You can
use the `is_admin` property to choose whether these users will be set as admins in this tenant upon login.
Note that you can create more than one list per tenant (using multiple API calls) to create one list for admin users and another for non-admin users.
Note that you can create more than one list per tenant (using multiple API calls). This way you can create one list
for admin users and another for non-admin users.
Note that including the same email address in more than a single tenant’s list will result in unstable behavior and should be avoided.
:::caution
Note that including the same email address in more than a single tenant's list will result in unstable behavior and
should be avoided.
:::
```bash
curl $APISERVER_URL/login.add_whitelist_entries \
-H "Content-Type: application/json" \
-H "X-Clearml-Act-As: <USER_ID>" \
-u $APISERVER_KEY:$APISERVER_SECRET \
-d '{"emails":["<email1>", "<email2>", ...],"is_admin":false}'
```
```bash
curl $APISERVER_URL/login.add_whitelist_entries \
-H "Content-Type: application/json" \
-H "X-Clearml-Act-As: <USER_ID>" \
-u $APISERVER_KEY:$APISERVER_SECRET \
-d '{"emails":["<email1>", "<email2>", ...],"is_admin":false}'
```
To remove existing email(s) from these lists, use the following API call. Note that this will not affect a user who has already logged in using one of these email addresses:
To remove an email(s) from these lists, use the following API call. Note that this will not affect a user who has
already logged in using one of these email addresses:
```bash
curl $APISERVER_URL/login.remove_whitelist_entries \
-H "Content-Type: application/json" \
-H "X-Clearml-Act-As: <USER_ID>" \
-u $APISERVER_KEY:$APISERVER_SECRET \
-d '{"emails":["<email1>", "<email2>", ...]}'
```
```bash
curl $APISERVER_URL/login.remove_whitelist_entries \
-H "Content-Type: application/json" \
-H "X-Clearml-Act-As: <USER_ID>" \
-u $APISERVER_KEY:$APISERVER_SECRET \
-d '{"emails":["<email1>", "<email2>", ...]}'
```
*Get the current login routing settings:*
##### View Current Login Routing Rules
To get the current IDP/SSO login rule settings for this tenant:
```bash
curl $APISERVER_URL/login.get_settings \
-H "X-Clearml-Act-As: <USER_ID>" \
-u $APISERVER_KEY:$APISERVER_SECRET
```
### Limit Features for all Users in a Group
### Feature Control by User Group
The server's `clearml-values.override.yaml` can control some tenants configurations, limiting the features available to some users or groups in the system.
The server's `clearml-values.override.yaml` can control the features available to
some users or groups in the system.
Example: with the following configuration, all users in the users group will only have the `applications` feature enabled.
Example: with the following configuration, all users in the `users` group will only have the `applications` feature enabled.
```yaml
apiserver:
@ -192,31 +187,34 @@ apiserver:
value: "[\"applications\"]"
```
A list of available features is available at the Appendix of this page: [Available Features](#available-features)
See a list of available features under [Available Features](#available-features).
## Workers
Refer to the following pages for installing and configuring the [ClearML Enterprise Agent](agent_k8s.md) and [App Gateway](appgw.md).
To install and configure the ClearML components that run user workloads, refer to:
* [ClearML Enterprise Agent](agent_k8s.md)
* [App Gateway](appgw.md).
:::note
Make sure to set up Agent and App Gateway using a Tenant's admin user credentials created with the Tenant creation APIs described above.
Make sure to set up Agent and App Gateway using a Tenant's admin user credentials created with the Tenant creation APIs
described [above](#create-a-tenant).
:::
### Tenants Separation
### Tenant Separation
In multi-tenant setups, you can separate the tenants workers in different namespaces.
In multi-tenant setups, you can separate the tenant workers in different namespaces:
Create a Kubernetes Namespace for each tenant and install a dedicated ClearML Agent and AI Application Gateway in each Namespace.
A tenant Agent and Gateway need to be configured with credentials created on the ClearML server by a user of the same tenant.
* Create a Kubernetes Namespace for each tenant
* Deploy a dedicated ClearML Agent and AI Application Gateway in each Namespace.
* Configure a tenant Agent and Gateway with credentials created on the ClearML Server by a user of the same tenant.
Additional network separation can be achieved via Kubernetes Network Policies.
## Additional Configuration
### Override Options When Creating a New Tenant
### Override Options for New Tenants
When creating a new tenant company, you can specify several tenant options. These include:
When creating a new tenant company, you can configure the following tenant options:
* `features` - Add features to a company.
* `exclude_features` - Exclude features from a company.
@ -229,11 +227,12 @@ curl $APISERVER_URL/system.create_company \
-d '{"name":"<TENANT_NAME>", "defaults": { "allowed_users": "10", "features": ["experiments"], "exclude_features": ["app_management", "applications", "user_management"] }}'
```
### Limit Features for all Users
### Global Features Limits
This value in the `clearml-values.override.yaml` will have priority over all tenants, and will limit the features available to any user in the system. This means that even if the feature is enabled for the tenant, if it's not in this list, the user will not see it.
The following setting in `clearml-values.override.yaml` defines a global feature whitelist. It overrides all tenant-specific
configurations, ensuring that only the listed features are available to any user in the system.
Example: all users will only have the applications feature enabled.
Example: Restrict all users to only the `applications` feature:
```yaml
apiserver:
@ -242,37 +241,36 @@ apiserver:
value: "[\"applications\"]"
```
A list of available features is available at the Appendix of this page: [Available Features](#available-features)
For the complete list of available features, see [Available Features](#available-features).
### Configuring Groups
Groups in ClearML are used to manage user permissions and control access to specific features within the platform.
The following section explains the different types of groups and how to configure them, with a focus on configuration-based, cross-tenant groups.
ClearML groups are used to control user permissions and access to platform.
This section described the types of groups available and how to configure them--especially cross-tenant groups.
#### Types of Groups
#### Group Types
ClearML utilizes several types of groups:
* **Built-in Groups** - These groups exist by default in every ClearML installation:
* **`users`**: All registered users automatically belong to this group. It typically defines the baseline set of
* **Built-in Groups** (default in every ClearML installation):
* **`users`**: All registered users belong to this group. It defines the baseline set of
permissions and features available to everyone.
* **`admins`**: Users in this group have administrative privileges.
* **`queue_admins`**: Users in this group have specific permissions to manage execution queues.
* **Tenant-Specific Groups (UI)** - Additional groups can be created specific to a tenant (organization workspace)
* **`queue_admins`**: Users in this group can manage task execution queues.
* **Tenant-Specific Groups (via UI)** - Additional tenant-specific groups can be created
directly through the ClearML Web UI (under **Settings > Users & Groups**). Users can be assigned to these groups via
the UI. These groups are managed *within* a specific tenant. For more information, see [Users & Groups](../../webapp/settings/webapp_settings_users.md).
the UI. For more information, see [Users & Groups](../../webapp/settings/webapp_settings_users.md).
* **Cross-Tenant Groups (Configuration)** - These groups are defined centrally in the ClearML configuration files
(e.g., Helm chart values, docker-compose environment variables). They offer several advantages:
* **Cross-Tenant Definition:** Defined once in the configuration, applicable across the deployment.
* **Fine-Grained Feature Control:** Allows precise assignment of specific ClearML features to groups.
* **Automation:** Suitable for infrastructure-as-code and automated deployment setups.
* Reusable across tenants
* Fine-grained control over enabled features
#### Configuring Cross-Tenant Groups
To define a cross-tenant group, you need to set specific configuration variables. These are typically set as environment
variables for the relevant ClearML services (like `apiserver`). The naming convention follows this
pattern: `CLEARML__services__auth__default_groups__<GroupName>__<Property>`.
Cross-tenant groups are defined using environment variables (e.g., in `apiserver`). The naming convention is:
```
CLEARML__services__auth__default_groups__<GroupName>__<Property>
```
Replace `<GroupName>` with the desired name for your group (e.g., `my_group_name`, `Data_Scientists`, `MLOps_Engineers`).
@ -280,37 +278,14 @@ Replace `<GroupName>` with the desired name for your group (e.g., `my_group_name
For each group you define in the configuration, you need to specify the following properties:
* **`id`**: A unique identifier for the group. This **must** be a standard UUID (Universally Unique Identifier). You can
generate one using various online tools or libraries.
* Variable Name: `CLEARML__services__auth__default_groups__<GroupName>__id`
* Example Value: `"abcd-1234-abcd-1234"`
| Property | Description | Variable Name | Example Value |
| ------------ | -------------------------------------------------------------------------- | ------------------------------------ | ------------------------------- |
| `id` | A unique identifier for the group. This **must** be a standard UUID (Universally Unique Identifier). You can generate one using various online tools or libraries. | `CLEARML__services__auth__default_groups__<GroupName>__id` | `"abcd-1234-abcd-1234"` |
| `name` | Display name for the group (should match `<GroupName>` used in the variable path) | `CLEARML__services__auth__default_groups__<GroupName>__name` | `"My Group Name"`, `"MLOps Team"` |
| `features` | JSON list of features to enable for this group . For the complete list of available features, see [Available Features](#available-features). Note that the features must be defined for the tenant or for the entire server in order to affect the group. By default, all the features of the tenant are available to all users. | `CLEARML__services__auth__default_groups__<GroupName>__features` | `'["applications", "experiments", "pipelines", "reports", "show_dashboard", "show_projects"]'` (Note the single quotes wrapping the JSON string if setting via YAML/environment variables). |
| `assignable` | Whether admins can assign users to this group from the ClearML Web UI (`true`/`false`). If `false`, group membership is managed externally or implicitly. | `CLEARML__services__auth__default_groups__<GroupName>__assignable` | `"false"` |
| `system` | Always set to `"false"` for custom groups | ``CLEARML__services__auth__default_groups__<GroupName>__system` | `"false"` |
* **`name`**: The display name of the group. This should match the `<GroupName>` used in the variable path.
* Variable Name: `CLEARML__services__auth__default_groups__<GroupName>__name`
* Example Value: `"My Group Name"`
* **`features`**: A JSON-formatted list of strings, where each string is a feature name to be enabled for this group. See
[Available Features](#available-features) for a list of valid feature names. Note that the features must be defined
for the tenant or for the entire server in order to affect the group. By default, all the features of the tenant are
available to all users.
* Variable Name: `CLEARML__services__auth__default_groups__<GroupName>__features`
* Example Value: `'["applications", "experiments", "pipelines", "reports", "show_dashboard", "show_projects"]'` (Note
the single quotes wrapping the JSON string if setting via YAML/environment variables).
* **`assignable`**: A boolean (`"true"` or `"false"`) indicating whether administrators can add users to this group via
the ClearML Web UI. If `false`, group membership is managed externally or implicitly. Configuration-defined groups
often have this set to `false`.
* Variable Name: `CLEARML__services__auth__default_groups__<GroupName>__assignable`
* Example Value: `"false"`
* **`system`**: A boolean flag. This should **always be set to `"false"`** for custom-defined groups.
* Variable Name: `CLEARML__services__auth__default_groups__<GroupName>__system`
* Example Value: `"false"`
##### Example Configuration
@ -343,6 +318,9 @@ that cannot be assigned via the UI:
### Feature Assignment Strategy
ClearML uses a feature-based permission model, where each user’s access is determined by the groups they belong to.
This section explains how feature assignment works and how to configure it effectively.
#### Combining Features
If a user belongs to multiple groups (e.g., the default `users` group and a custom `my_group_name` group), their
@ -350,31 +328,34 @@ effective feature set is the **union** (combination) of all features from all gr
#### Configuring the Default 'users' Group
Because all users belong to the `users` group, and features are combined, it's crucial to configure the `users` group
Since all users belong to the `users` group, you should configure the `users` group
appropriately. You generally have two options:
1. **Minimum Shared Features:** Assign only the absolute minimum set of features that *every single user* should have to
the `users` group.
1. **Minimum Shared Features:** Only assign features that every user should always have.
2. **Empty Feature Set:** Assign an empty list (`[]`) to the `users` group's features. This means users only get features
explicitly granted by other groups they are members of. This is often the cleanest approach when using multiple custom groups.
explicitly granted to groups they are members of.
**Example: Disabling all features by default for the `users` group:**
```yaml
- name: CLEARML__services__auth__default_groups__users__features
value: '[]'
```
```yaml
- name: CLEARML__services__auth__default_groups__users__features
value: '[]'
```
:::note
You typically don't need to define the id, name, assignable, or system properties for built-in groups like users unless
you need to override default behavior, but you do configure their features.
For built-in groups like users, you typically only need to define the `features` property. You do not need to redefine
`id`, `name`, `assignable`, or `system` unless you need to override defaults.
:::
#### Setting Server-Level or Tenant-level Features
Features must be enabled for the entire server or for the tenant in order to allow setting it for specific groups.
Setting server wide feature is done using a different configuration pattern: `CLEARML__services__organization__features__<FeatureName>`.
To assign a feature to a group, that feature must first be enabled globally (server-level) or per tenant.
##### Enabling Features Globally
To enable a feature for the entire deployment, use:
```
CLEARML__services__organization__features__<FeatureName>`
```
Setting one of these variables to `"true"` enables the feature globally.
@ -385,6 +366,8 @@ Setting one of these variables to `"true"` enables the feature globally.
value: "true"
```
##### Enabling Features Per Tenant
To enable a feature for a specific tenant, use the following API call:
```bash
@ -397,9 +380,9 @@ curl $APISERVER_URL/system.update_company_settings \
}'
```
By default, all users have access to all features, but this can be changed by setting specific features set per group as described above.
By default, all users have access to all features. You can restrict this by explicitly setting feature lists per group.
#### Example: Defining Full Features for Admins
#### Example: Granting All Features for Admins
While the `admins` group has inherent administrative privileges, you might want to explicitly ensure they have access to
*all* configurable features defined via the `features` list, especially if you've restricted the default `users` group
@ -433,12 +416,14 @@ restart the relevant ClearML services after applying configuration changes.
### Per-Tenant Applications Settings
You may want your users' applications in different tenants to have their own configuration and template on Kubernetes. For this reason, the ClearML Enterprise Server and Agent support different queue modes:
You may want your users' applications in different tenants to have their own configuration and template on Kubernetes.
The ClearML Enterprise Server and Agent support different queue modes:
- `global` (default) - A single Apps Agent on the control-plane. The application's controllers will start on the control-plane.
- `per_tenant` - Multiple Apps Agents, one per tenant (will need `agentk8sglue.appsQueue.enabled=true` on Agents). The application's controllers will start on the worker.
- `global` (default) - A single Apps Agent on the server. The application's controllers will start on the server.
- `per_tenant` - Multiple Apps Agents, one per tenant (will need `agentk8sglue.appsQueue.enabled=true` on Agents). The
application's controllers will start on the worker.
Configure the Server’s `clearml-values.override.yaml`:
Configure the Server's `clearml-values.override.yaml`:
```yaml
clearmlApplications:
@ -456,33 +441,35 @@ agentk8sglue:
# templateOverrides:
```
**Note**: this feature requires the Agent to be configured using an internal admin credentials as previously mentioned in the "Create an Admin User for the new tenant" section, making sure to pass `"internal":"true"` and using the output credentials for `clearml.agentk8sglueKey` and `clearml.agentk8sglueSecret` (or `existingAgentk8sglueSecret`).
:::note
This feature requires the Agent to be configured using an internal admin credentials as previously mentioned in the
"Create an Admin User for the new tenant" section, making sure to pass `"internal":"true"` and using the output
credentials for `clearml.agentk8sglueKey` and `clearml.agentk8sglueSecret` (or `existingAgentk8sglueSecret`).
:::
## Appendix
### Available Features
## Available Features
The following features can be assigned to groups via the `features` configuration variable:
| Feature Name | Description | Notes |
| :---- | :---- | :---- |
| `user_management` | Allows viewing company users and groups, and editing group memberships. | Only effective if the group is `assignable`. |
| `user_management_advanced` | Allows direct creation of users (bypassing invites) by admins and system users. | Often requires enabling at the organization level too. |
| `user_management_advanced` | Allows direct creation of users (bypassing invites) by admins and system users. | Often also requires enabling at the organization level. |
| `permissions` | Enables editing of Role-Based Access Control (RBAC) rules. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `applications` | Allows users to work with ClearML Applications (viewing, running). | Excludes management operations (upload/delete). |
| `applications` | Allows users to work with [ClearML Applications](../../webapp/applications/apps_overview.md) (viewing, running). | Excludes management operations (upload/delete). |
| `app_management` | Allows application management operations: upload, delete, enable, disable. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `experiments` | Allows working with experiments. | *Deprecated/Not Used.* All users have access regardless of this flag. |
| `queues` | Allows working with queues. | *Deprecated/Not Used.* All users have access regardless of this flag. |
| `queue_management` | Allows create, update, and delete operations on queues. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `data_management` | Controls access to Hyper-Datasets. | Actual access might also depend on `apiserver.services.excluded`. |
| `config_vault` | Enables the configuration vaults feature. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `data_management` | Controls access to [Hyper-Datasets](../../hyperdatasets/overview.md). | Access may also depend on `apiserver.services.excluded`. |
| `config_vault` | Enables the [configuration vaults](../../webapp/settings/webapp_settings_profile.md#configuration-vault) feature. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `pipelines` | Enables access to Pipelines (building and running). | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `reports` | Enables access to Reports. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `resource_dashboard` | Enables access to the compute resource dashboard feature. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `reports` | Enables access to [Reports](../../webapp/webapp_reports.md). | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `resource_dashboard` | Enables access to the [orchestration dashboard](../../webapp/webapp_orchestration_dash.md) feature. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `sso_management` | Enables the SSO (Single Sign-On) configuration wizard. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `service_users` | Enables support for creating and managing service users (API keys). | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `resource_policy` | Enables the resource policy feature. | May default to a trial feature if not explicitly enabled. |
| `model_serving` | Enables access to the model serving endpoints feature. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `resource_policy` | Enables the [Resource Policies](../../webapp/resource_policies.md) feature. | May default to a trial feature if not explicitly enabled. |
| `model_serving` | Enables access to the [Model Endpoints](../../webapp/webapp_model_endoints.md) feature. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `show_dashboard` | Makes the "Dashboard" menu item visible in the UI sidebar. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `show_model_view` | Makes the "Models" menu item visible in the UI sidebar. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |
| `show_projects` | Makes the "Projects" menu item visible in the UI sidebar. | <img src="/docs/latest/icons/ico-optional-no.svg" alt="No" className="icon size-md center-md" /> |