> For the complete documentation index, see [llms.txt](https://run-ai-docs.nvidia.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://run-ai-docs.nvidia.com/self-hosted/2.25/infrastructure-setup/authentication/permissions.md). # Permissions This page provides a reference of the permissions available in the NVIDIA Run:ai platform. Use it when building [custom roles](/self-hosted/2.25/infrastructure-setup/authentication/roles.md) to understand what each permission controls and how permission names in the API map to the names shown in the user interface. ## About Permissions A permission is the actions (View, Edit, Create and Delete) that the user can perform over a NVIDIA Run:ai entity (resource type). These actions map to the API actions `read`, `update`, `create`, and `delete` respectively. Related permissions are grouped into [permission sets](#permission-sets), and a [role](/self-hosted/2.25/infrastructure-setup/authentication/roles.md) is defined as a collection of permission sets assigned to a subject in a scope. NVIDIA Run:ai provides predefined roles that are system-defined and cannot be edited or deleted. Administrators can also create custom roles via the API. When you build a custom role through the API, permissions are referenced by their **API name** (for example, `compute-resources`). The NVIDIA Run:ai user interface presents the same permission under a **display name** (for example, "Compute resources"). The tables below map the two and describe what each permission controls. {% hint style="info" %} **Note** * Some permissions are system-internal and are not shown in the Roles view in the user interface. These are noted in the tables below. * **Deprecated:** The `apps` API name is deprecated. Use `service-account` for managing service accounts. {% endhint %} ## Permission Reference The following table lists all permissions, mapping each permission's API name to its user interface display name and describing what it controls. | API name | Display name | Description | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `access-keys` | [Access Keys](/self-hosted/2.25/settings/user-settings/user-access-keys.md) | Access keys are used for API integrations with NVIDIA Run:ai. An access key contains a client ID and a client secret. This permission is not shown in the Roles view. | | `access_rules` | [Access rules](/self-hosted/2.25/infrastructure-setup/authentication/accessrules.md) | Access rules provide users, groups, or service accounts privileges to system entities. An access rule is the assignment of a role to a subject in a scope. | | `tenant` | Account | The top-level organizational node headed by the account, comprised of clusters, departments, and projects. | | `applications` | [AI Applications](/self-hosted/2.25/ai-applications/ai-applications.md) | An AI application represents a high-level logical grouping of all Kubernetes resources that together deliver a functional AI solution. | | `apps` | [Applications](/self-hosted/2.25/infrastructure-setup/authentication/service-accounts.md) | Deprecated. Superseded by `service-account`. Distinct from `applications` (AI Applications). | | `branding-settings` | [Branding settings](/self-hosted/2.25/settings/general-settings.md#branding) | Custom logo displayed in the top-right corner of the NVIDIA Run:ai platform interface. | | `cluster-config` | [Cluster configuration](/self-hosted/2.25/infrastructure-setup/advanced-setup/cluster-config.md) | Governs synchronization of cluster configuration between a cluster and the control plane. This permission is system-internal: it is not shown in the Roles view and is not held by tenant administrators. Do not include `cluster-config` in a custom role. A role that includes it cannot be assigned, and access rule creation fails with `403 Insufficient permissions`. | | `cluster` | [Clusters](/self-hosted/2.25/infrastructure-setup/procedures/clusters.md) | A registered Kubernetes cluster that the NVIDIA Run:ai control plane manages, schedules workloads on, and monitors. | | `clusters-minimal` | [Clusters minimal](/self-hosted/2.25/infrastructure-setup/procedures/clusters.md) | Provides read-only access to a lightweight subset of cluster metadata (name, ID, status). Automatically included by the platform when a role grants cluster read access, to support resource display in the user interface. | | `compute-resources` | [Compute resources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/compute-resources.md) | A compute resource is a workload asset template that simplifies how workloads are submitted and can be used by AI practitioners when they submit their workloads. | | `credentials` | [Credentials](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/credentials.md) | Credentials are workload assets that mask sensitive access information, such as passwords, tokens, and access keys, necessary for accessing protected resources. | | `pvc-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md#pvc) | A data source asset backed by a Persistent Volume Claim (PVC), a Kubernetes concept for managing cluster storage provisioned by an administrator or dynamically using a StorageClass. | | `git-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md) | A data source asset that copies code from a Git branch into a dedicated folder in the container, providing the workload with the latest code repository. | | `nfs-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md) | A data source asset backed by a Network File System (NFS), used for sharing storage among pods in the cluster; content is preserved outside the lifecycle of a single pod. | | `s3-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md) | A data source asset that maps a remote S3 bucket into the workload's file system, accessible across different workload executions. | | `host-path-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md) | A data source asset that mounts a host path file or directory on the workload's file system; data persists across workloads. | | `cm-volume-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md) | A data source asset backed by a Kubernetes ConfigMap, used to store non-confidential data such as environment variables and command-line arguments. | | `secret-volume-assets` | [Data sources](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/datasources.md) | A data source asset that maps a credential into the workload's file system to provide sensitive access information such as passwords, tokens, and access keys. | | `datavolumes` | [Data volumes](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/data-volumes.md) | Data volumes are workload assets that offer a solution for storing, managing, and sharing AI training data across scopes and workloads. | | `department` | [Departments](/self-hosted/2.25/platform-management/aiinitiatives/organization/departments.md) | Departments group multiple projects under a shared organizational scope for quota management, policy enforcement, and asset sharing. | | `environments` | [Environments](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/environments.md) | An environment is a workload asset consisting of a configuration that simplifies how workloads are submitted and can be used by AI practitioners. | | `events-history` | [Event history](/self-hosted/2.25/infrastructure-setup/procedures/event-history.md) | An audit log of all changes to business objects (clusters, projects, assets, and more) in the NVIDIA Run:ai platform, accessible to system administrators with tenant-wide permissions. | | `inferences` | [Inferences](/self-hosted/2.25/workloads-in-nvidia-run-ai/using-inference.md) | Inference workloads deploy trained models to make real-time or batch predictions in a production environment. | | `network-topologies` | [Network topologies](/self-hosted/2.25/infrastructure-setup/procedures/clusters.md) | Named configurations of node labels that describe the physical network structure of a cluster (racks, blocks, NVLink domains), used by the scheduler to minimize latency for distributed workloads. | | `nodepools` | [Node pools](/self-hosted/2.25/platform-management/aiinitiatives/resources/node-pools.md) | A node pool is a NVIDIA Run:ai construct representing a set of nodes grouped into a bucket of resources using a predefined or administrator-defined node label. | | `nodepools-minimal` | [Node pools minimal](/self-hosted/2.25/platform-management/aiinitiatives/resources/node-pools.md) | Provides read-only access to a lightweight subset of node pool metadata. Automatically included by the platform when a role grants node pool, department, or project read access. | | `nodes` | [Nodes](/self-hosted/2.25/platform-management/aiinitiatives/resources/nodes.md) | Nodes are Kubernetes elements automatically discovered by the NVIDIA Run:ai platform and registered for scheduling and administrator visibility. | | `policies` | [Policies](/self-hosted/2.25/platform-management/policies/workload-policies.md) | Workload policies allow administrators to set best practices, enforce limitations, and standardize workload submission processes within their organization. | | `project` | [Projects](/self-hosted/2.25/platform-management/aiinitiatives/organization/projects.md) | Projects are the primary organization management unit in NVIDIA Run:ai, used to control how resources are allocated and prioritized across teams and initiatives. | | `registries` | [Registries](/self-hosted/2.25/workloads-in-nvidia-run-ai/assets/environments.md#adding-a-new-environment) | Stored connection configurations for private container image registries, used when selecting images in environment assets. | | `roles` | [Roles](/self-hosted/2.25/infrastructure-setup/authentication/roles.md) | A role defines a set of permissions that can be assigned to a subject in a scope, determining which actions the subject is allowed to perform on NVIDIA Run:ai entities. | | `security-settings` | [Security settings](/self-hosted/2.25/settings/general-settings.md#security) | Platform-level identity provider (SSO) configuration and session security settings. | | `service-account` | [Service accounts](/self-hosted/2.25/infrastructure-setup/authentication/service-accounts.md) | Service accounts are used for API integrations with NVIDIA Run:ai. A service account contains a client ID and a client secret. | | `settings` | [Settings](/self-hosted/2.25/settings/general-settings.md) | Centralized controls for enabling or disabling key NVIDIA Run:ai platform features across resources, workload types, and security. | | `storage-class-configuration` | [Storage class configuration](https://run-ai-docs.nvidia.com/api/2.25/workload-assets/storage-class-configuration) | Kubernetes storage classes define how storage is provisioned for AI workloads, used when creating PVC data sources and data volumes. | | `templates` | [Templates](/self-hosted/2.25/workloads-in-nvidia-run-ai/workload-templates.md) | A workload template is a reusable setup that defines all the required configuration fields for submitting a workload, allowing users to predefine settings. | | `trainings` | [Trainings](/self-hosted/2.25/workloads-in-nvidia-run-ai/using-training.md) | Training workloads run resource-intensive, batch-mode model development jobs, often requiring distributed computing across multiple nodes. | | `users` | [Users](/self-hosted/2.25/infrastructure-setup/authentication/users.md) | Users can be managed locally or via an identity provider (IdP) and are assigned permissions through access rules. | | `workload-integration-metrics` | Workload integration metrics | System-internal. Used by the platform to collect workload metrics from integrations. Not intended to be assigned when building custom roles. | | `workload-properties` | [Workload properties](/self-hosted/2.25/workloads-in-nvidia-run-ai/workloads.md#managing-workload-properties) | The priority, preemptibility, and workload category assigned to each workload type by default. | | `workloads` | [Workloads](/self-hosted/2.25/workloads-in-nvidia-run-ai/workloads.md) | Workloads are the fundamental building blocks for consuming resources, enabling AI practitioners to support the entire lifecycle of an AI initiative. | | `workspaces` | [Workspaces](/self-hosted/2.25/workloads-in-nvidia-run-ai/using-workspaces/running-workspace.md) | The workspace is where data scientists conduct initial research, experiment with data sets, and test algorithms — the most flexible stage in the ML lifecycle. | {% hint style="info" %} **Note** The seven `*-assets` API names above all appear under the single **Data sources** display name in the user interface. When building a custom role via the API, grant the specific asset types your users need using the relevant permission sets. {% endhint %} ## Permission Sets Permissions are bundled into **permission sets** - reusable building blocks that group the actions for a particular functional area (for example, viewing workloads or managing clusters). Permission sets are used through the [Roles](/self-hosted/2.25/infrastructure-setup/authentication/roles.md) API to define both predefined and custom roles, and are referenced by the API names below. Most permission sets come in a **read** variant (view only) and an **edit** variant (create, read, update, and delete). The following permission sets are available: | API name | Description | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `workspaceEditAccess` | Grants full permissions to create, read, update, and delete workspaces, and to access all related data and resources required for their management. | | `trainingEditAccess` | Grants full permissions to create, read, update, and delete training workloads, and to access all related data and resources required for their management. | | `inferenceEditAccess` | Grants full permissions to create, read, update, and delete inference workloads, and to access all related data and resources required for their management. | | `yamlWorkloadEditAccess` | Grants full permissions to create, read, update, and delete workloads defined in YAML, and to access all related data and resources required for their management. | | `workloadReadAccess` | Grants permissions to view workloads, including all related data and resources associated with them. | | `workloadPropertiesEditAccess` | Grants full permissions to create, read, update, and delete workload properties, and to access all related data and resources required for their management. | | `workloadPropertiesReadAccess` | Grants permissions to view workload properties, including all related data and resources associated with them. | | `templatesEditAccess` | Grants full permissions to create, read, update, and delete workload templates, and to access all related data and resources required for their management. | | `templatesReadAccess` | Grants permissions to view workload templates, including all related data and resources associated with them. | | `dataAndStorageEditAccess` | Grants full permissions to create, read, update, and delete data and storage, and to access all related data and resources required for their management. | | `dataAndStorageReadAccess` | Grants permissions to view data and storage, including all related data and resources associated with them. | | `policiesEditAccess` | Grants full permissions to create, read, update, and delete policies, and to access all related data and resources required for their management. | | `policiesReadAccess` | Grants permissions to view policies, including all related data and resources associated with them. | | `projectsEditAccess` | Grants full permissions to create, read, update, and delete projects, and to access all related data and resources required for their management. | | `projectsReadAccess` | Grants permissions to view projects, including all related data and resources associated with them. | | `departmentsEditAccess` | Grants full permissions to create, read, update, and delete departments, and to access all related data and resources required for their management. | | `departmentsReadAccess` | Grants permissions to view departments, including all related data and resources associated with them. | | `clustersEditAccess` | Grants permissions to create, read, update, and delete clusters. | | `clustersReadAccess` | Grants permissions to view clusters. | | `networkTopologyEditAccess` | Grants full permissions to create, read, update, and delete network topologies, and to access all related data and resources required for their management. | | `networkTopologyReadAccess` | Grants permissions to view network topologies, including all related data and resources associated with them. | | `nodesReadAccess` | Grants permissions to view nodes, including all related data and resources associated with them. | | `nodePoolsEditAccess` | Grants full permissions to create, read, update, and delete node pools, and to access all related data and resources required for their management. | | `nodePoolsReadAccess` | Grants permissions to view node pools, including all related data and resources associated with them. | | `quotaManagementDashboardReadAccess` | Grants permissions to view the quota management dashboard, including all related data and resources associated with them. | | `usersEditAccess` | Grants permissions to create, read, update, and delete users. | | `usersReadAccess` | Grants permissions to view users. | | `serviceAccountsEditAccess` | Grants permissions to create, read, update, and delete service accounts. | | `serviceAccountsReadAccess` | Grants permissions to view service accounts. | | `accessRulesEditAccess` | Grants full permissions to create, read, update, and delete access rules, and to access all related data and resources required for their management. | | `accessRulesReadAccess` | Grants permissions to view access rules, including all related data and resources associated with them. | | `rolesEditAccess` | Grants permissions to create, read, update, and delete roles. | | `rolesReadAccess` | Grants permissions to view roles. | | `settingsEditAccess` | Grants permissions to create, read, update, and delete settings. | | `settingsReadAccess` | Grants permissions to view settings. | | `securitySettingsEditAccess` | Grants permissions to create, read, update, and delete security settings. | | `securitySettingsReadAccess` | Grants permissions to view security settings. | | `brandingSettingsEditAccess` | Grants permissions to create, read, update, and delete branding settings. | | `brandingSettingsReadAccess` | Grants permissions to view branding settings. | | `eventHistoryReadAccess` | Grants permissions to view event history. | | `accountEditAccess` | Grants permissions to create, read, update, and delete accounts. | | `accountReadAccess` | Grants permissions to view accounts. | | `accessKeysEditAccess` | Grants full permissions to create, read, update, and delete user access keys. | | `storageClassConfigurationEditAccess` | Grants full permissions to create, read, update, and delete storage class configurations used by volume and PVC assets. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://run-ai-docs.nvidia.com/self-hosted/2.25/infrastructure-setup/authentication/permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.