# Access Control {% hint style="warning" %} This feature is in alpha. Behavior may change before general availability. {% endhint %} Access is enforced at the Pipekit API level and tied to your existing identity provider. ## Core concepts ### Workspaces A workspace is a named scope that binds **one or more** `{cluster, namespace}` pairs and serves as the unit of access control. Every pipe, run, and template in Pipekit belongs to exactly one workspace. **Each `{cluster, namespace}` pair can only belong to one workspace.** Users and groups are granted access at the workspace level. A user with access to `team-data` has no visibility into `team-ml`. Workspaces are fully isolated in both the UI and API. | Workspace | Cluster | Namespace | | -------------- | ------------ | --------- | | `team-data` | cluster-dev | data-dev | | | cluster-prod | data-prod | | `team-ml` | cluster-dev | ml-dev | | `team-ml-prod` | cluster-prod | ml-prod | ### Roles Each user or group is assigned one role per workspace. Bindings are additive — when a user holds access at both org scope and workspace scope, the higher-privilege role applies. An org-scoped Admin is always an Admin in every workspace; a workspace-scoped Viewer binding cannot reduce that. | Role | Binding scope | What they can do | | ------------------- | ---------------- | -------------------------------------------------------------------------------------------------- | | **Org Admin** | Org only | Manage users, clusters, workspaces, SSO mappings, and role bindings across the entire organization | | **Workspace Admin** | Org or Workspace | Manage workspace settings, users, secrets, and alerts | | **Editor** | Org or Workspace | Create, edit, and delete WorkflowTemplates and CronWorkflows; submit and manage workflow runs | | **Runner** | Org or Workspace | Submit workflows; stop, terminate, retry, and restart runs; view logs | | **Viewer** | Org or Workspace | Read-only access to pipes, runs, logs, and templates (no secrets visibility) | Org Admin is the only role restricted to *org scope* — it manages org-level entities that don't exist at workspace level. ### Groups and binding scopes {% hint style="info" %} Roles are assigned to IdP groups rather than individual users. {% endhint %} When a user's group membership changes in your identity provider, their Pipekit access updates automatically — no manual intervention required. Bindings operate at two scopes: * **Org scope** — applies to all workspaces automatically. Use this for platform, ops, or admin groups that need cross-workspace access. Binding at org scope is a scale convenience — one binding instead of one per workspace. * **Workspace scope** — applies to a single named workspace. Use this for team-level access where different groups need different roles in different environments. ``` # Org-scoped — applies to all workspaces idp:team:platform → Org Admin → all workspaces idp:team:ops → Viewer → all workspaces idp:team:shared-tools → Editor → all workspaces # Workspace-scoped — applies to one workspace only idp:team:data-engineers → Runner → team-data-dev idp:team:data-engineers → Viewer → team-data-prod ``` The role's action set is unchanged regardless of scope. For cross-workspace read-only access — for example a platform ops team that monitors all teams — bind Viewer at *org scope*. When a user belongs to both an org-scoped group and a workspace-scoped group, the higher-privilege role applies: ``` idp:team:platform → Org Admin → all workspaces idp:team:foo → Viewer → team-foo-dev # A platform engineer in both groups gets Admin in team-foo-dev, not Viewer ``` Org-level access is never silently reduced by a workspace binding. If a group should not have elevated access in a specific workspace, do not give them an org-scoped role — use explicit workspace bindings instead. {% hint style="info" %} Individual user overrides are not supported in the current release. Access is managed at the group level. {% endhint %} ## SSO and identity provider integration Pipekit integrates with Okta and Microsoft Entra. Once SSO is configured for your organization: * Users authenticate exclusively via your identity provider — password login is disabled for your domain * Users must be invited to Pipekit by an Org Admin before their first login; once accepted, their access is determined by their IdP group membership * Removing a user from your IdP revokes their ability to authenticate with Pipekit * Users who are not members of any mapped group can log in but will have no access — they will see an empty Pipekit with a prompt to contact their Org Admin SSO is configured once by an Org Admin. Setup instructions are available for [Okta](https://docs.pipekit.io/pipekit/authentication/okta) and [Microsoft Entra](https://docs.pipekit.io/pipekit/authentication/entra). ## Permission reference | Action | Org Admin | WS Admin | Editor | Runner | Viewer | | -------------------------------------------------- | :-------: | :------: | :----: | :----: | :----: | | **Org management** | | | | | | | Invite & remove users | ✓ | | | | | | Manage clusters | ✓ | | | | | | Manage RBAC (workspaces, bindings, SSO mappings) | ✓ | | | | | | **Workspace settings** | | | | | | | Manage workspace settings & alerts | | ✓ | | | | | **Pipes** | | | | | | | View pipes & cron schedules | | ✓ | ✓ | ✓ | ✓ | | Create / edit pipes | | ✓ | ✓ | | | | Delete pipes | | ✓ | | | | | Rotate pipe deploy key | | ✓ | | | | | **Secrets** | | | | | | | View secret environments | | ✓ | ✓ | ✓ | | | Create / edit secrets | | ✓ | ✓ | | | | Delete secret environments | | ✓ | | | | | **Runs** | | | | | | | View runs & logs | | ✓ | ✓ | ✓ | ✓ | | Submit workflows | | ✓ | ✓ | ✓ | | | Cancel / retry / stop workflows | | ✓ | ✓ | ✓ | | | **Templates & config** | | | | | | | View templates | | ✓ | ✓ | ✓ | ✓ | | Manage workflow templates (create / edit / delete) | | ✓ | ✓ | | | | Manage cron schedules (suspend / resume) | | ✓ | ✓ | | | | Config as code | | ✓ | | | | ## How access is enforced ### Default-deny No access is granted implicitly. A user must have an explicit workspace binding to interact with any pipe, run, or cluster in Pipekit. Namespaces added to a cluster are inaccessible to all users until an Org Admin explicitly binds them to a workspace. ### Workspace isolation in the UI Users see only the workspaces they have access to. Clusters, pipes, runs, and templates from other workspaces are not visible — they are absent from all views, not hidden behind a permission error. ### Submission enforcement When a workflow is submitted — via the UI, CLI, or Python SDK — Pipekit checks that the authenticated user has a binding in a workspace that covers the target cluster and namespace. If not, the submission is rejected before it reaches the workflow engine. Pipekit does not modify the workflow spec; it validates access and either allows or rejects. ### Scope of enforcement Pipekit enforces access at the Pipekit API and UI layer. {% hint style="warning" %} Users who have direct `kubectl` or Argo UI access to a cluster are not constrained by Pipekit RBAC — enforcement at that layer is handled by Kubernetes RBAC, which remains under your platform team's control. {% endhint %} ## Bootstrapping your organization When you first set up Pipekit, the user who creates the organization is automatically assigned Org Admin. From there: 1. **Configure SSO** — connect your identity provider and enforce domain-locked authentication 2. **Connect clusters** — register the Kubernetes clusters Pipekit will submit workflows to 3. **Create workspaces** — define your initial workspaces and bind the relevant `{cluster, namespace}` pairs 4. **Map IdP groups to roles** — assign roles to your IdP groups at org or workspace scope 5. **Invite your first users** — invite Org Admins and Workspace Admins by email; once they accept they can begin onboarding their teams Until SSO is configured, users authenticate with email and password. Once SSO is enforced, password login is disabled for your domain and all new users must go through your identity provider. {% hint style="info" %} Configure SSO and map at least one IdP group to Org Admin before inviting other users. This ensures access management is owned by your identity provider from the start. {% endhint %} ## Setting up a team The typical flow for onboarding a new team: 1. **Create a workspace** — give it a name and bind the relevant `{cluster, namespace}` pairs 2. **Map IdP groups to roles** — e.g. `team-data-engineers` → Runner in dev, Viewer in prod; `team-data-leads` → Editor in both 3. **Invite users** — an Org Admin invites users by email; once they accept and log in via SSO, their access is determined by their IdP group membership ```bash # As Org Admin: see who can submit in a given workspace pipekit rbac who-can submit --workspace=team-data-dev ```