Skip to main content
Version: v1.2.x

Roles and Permissions

PaletteAI manages permissions using standard Kubernetes Role-Based Access Control (RBAC), with one consistent extension: every role in PaletteAI is bound to OpenID Connect (OIDC) groups rather than to individual users. When you create a Tenant or Project, PaletteAI generates the underlying roles and role bindings automatically and connects them to the OIDC groups you specify in the Tenant's tenantRoleMapping or the Project's roleMapping. Group membership in your identity provider grants or revokes access; there are no per-user resources to maintain inside the cluster.

The roles fall into three groups: a Tenant admin role that spans every Project in a Tenant, three Project-scoped roles that follow a Viewer / Editor / Admin progression, and a small set of read-only platform bindings that let Project users view shared platform definitions. System administrators sit above this model. The full Kubernetes permission matrix for every role is documented in the Role Permissions reference; this page focuses on what each role is for.

System Administrator​

System administrators manage the System scope (pai-system), including System Settings and creating Tenants. Local Dex users are bound to cluster-admin automatically by the mural chart (every static password user when impersonation is disabled; users mapped to system-admin via dexGroupMap when it is enabled). External OIDC users and groups are never auto-bound — create an explicit binding to the built-in cluster-admin ClusterRole, whether or not impersonation is enabled. See Grant System Administrators cluster-admin.

kubectl create clusterrolebinding mural-system-admin \
  --clusterrole=cluster-admin \
  --group=<system-admin-oidc-group>

Replace <system-admin-oidc-group> with the OIDC group name your identity provider emits for system administrators, or bind a specific user with --user=<email> instead.

Platform operators can adjust the default Viewer, Editor, and Admin permission sets after installation by editing Tenant-scoped RBAC policy ConfigMaps. For the workflow and upgrade behavior, refer to Project RBAC policy templates.

Tenant Admin Role​

A Tenant admin has full control over the Tenant and every Project that belongs to it. PaletteAI provisions three role/binding pairs for Tenant admins when the Tenant is created: a namespace-scoped Role and RoleBinding in each Project that grant full access to Project resources, a cluster-scoped ClusterRole and ClusterRoleBinding with create-only access to Project, Settings, ComputeConfig, and Secret resources, and a view-only Role and RoleBinding in the Tenant namespace for reading Tenant-level integrations and Secrets. Together, they grant Tenant admins full Project management without needing per-Project group membership.

Tenant admins are typically platform engineers responsible for onboarding new Projects and configuring Tenant-scoped policies (such as default integrations and GPU quotas).

Project Roles​

Projects create three default roles that map to the day-to-day work performed inside them. Every role is scoped to the Project's namespace. The platform is designed to support additional custom RBAC personas that operators can define via ConfigMaps, extending the system beyond the built-in three-tier model.

Viewer​

The Viewer role is read-only. Viewers can list and inspect every PaletteAI resource in the Project — Compute Pools, App Deployments, Model Deployments, Profile Bundles, Workload Profiles, integrations, and so on — but cannot create, modify, or delete anything. This role is intended for auditors, observers, and stakeholders who need visibility without operational responsibility.

Editor​

The Editor role is the working role for data scientists and machine learning engineers. Editors create and manage App Deployments and Model Deployments, author Profile Bundles and Workload Profiles, and manage the supporting Compute Configs, Repositories, Scaling Policies, and Secrets they depend on. Editors deliberately cannot create or modify Compute Pools, change the Project's integrations, or alter the platform-level Definitions that govern how workloads are rendered — those operations stay with Project admins or Tenant admins.

Admin​

The Project admin role has full control over every Project-scoped resource, including Compute Pools, App Deployments, Model Deployments, Profile Bundles, Workload Profiles, Definitions, Scaling Policies, integrations, Variables, Repositories, Secrets, and the Project resource itself. Project admins set the Project's GPU quotas, configure the Project's integrations, and manage the OIDC group bindings for the Project's Viewer, Editor, and Admin roles.

Platform Role Bindings​

PaletteAI installs a set of shared platform resources — built-in Definitions, default Scaling Policies, feature flags, and similar — into the platform namespace (mural-system by default). This is separate from the System scope (pai-system). Every Project user needs read access to these platform resources so the Project's workloads can reference them, but no Project user should be able to modify them.

To handle this, PaletteAI creates one read-only role per Project tier in the platform namespace and binds them to the same OIDC groups as the Project-scoped roles. The bindings are created automatically for each Project, so a user who belongs to a Project's Editor group automatically gains read access to the platform definitions they need to reference. These platform roles never grant write access regardless of tier.

The three default tiers (Viewer, Editor, Admin) receive platform role bindings automatically. When operators define additional custom personas through ConfigMap templates, those personas follow the same pattern: each custom persona receives its own platform-namespace role with read-only access to shared definitions, and a per-project binding connects it to the corresponding OIDC groups.

Access to Shared Tenant-Scoped Resources​

When a Tenant admin shares a tenant-scoped Compute Pool, deployment, or Profile Bundle with a Project, PaletteAI grants that Project's OIDC groups read access to the specific shared resource through a per-resource Role and RoleBinding in the Tenant namespace. This is separate from the Project and platform roles described above. For the access model, refer to Tenant-Scoped Resources.

For the exact resources and verbs each role grants, refer to the Role Permissions reference.