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 system bindings that let Project users view shared platform definitions. The full Kubernetes permission matrix for every role is documented in the Role Permissions reference; this page focuses on what each role is for.

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

Each Project has three roles that map to the day-to-day work performed inside it. Every role is scoped to the Project's namespace.

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.

System Role Bindings

PaletteAI installs a set of shared platform resources — system Definitions, default Scaling Policies, system feature flags, and similar — into a dedicated system namespace. Every Project user needs read access to these 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 (Viewer, Editor, Admin) in the system 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 system definitions they need to reference. The system roles never grant write access regardless of tier.

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