Access Control

Role-based access control (RBAC) lets your organization define who can see, run, and manage workflows — scoped to the teams and environments you define.

This feature is in alpha. Behavior may change before general availability.

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

Roles are assigned to IdP groups rather than individual users.

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.

Individual user overrides are not supported in the current release. Access is managed at the group level.

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 and Microsoft 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.

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.

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.

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.

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

# As Org Admin: see who can submit in a given workspace
pipekit rbac who-can submit --workspace=team-data-dev