> For the complete documentation index, see [llms.txt](https://docs.pipekit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pipekit.io/why-pipekit/governance.md).

# Governance

Argo Workflows ships with Kubernetes-native RBAC. That works for small teams; it scales poorly when many teams share clusters, when access changes weekly, and when an auditor wants to know who submitted what. Pipekit adds an access layer above Argo that maps cleanly to how organizations already manage identity.

## How Pipekit enforces governance

### Workspaces bind `{cluster, namespace}` pairs to teams

A [workspace](/concepts/access-control.md#workspaces) is a named scope that contains one or more `{cluster, namespace}` pairs. Every Pipe, Run, and Template belongs to exactly one workspace. Each `{cluster, namespace}` pair belongs to one workspace, so workspaces are non-overlapping and you can't accidentally double-bind a namespace.

This lets you carve a single cluster into team-shaped slices without giving every team cluster-admin rights.

### IdP-backed roles, not local users

Pipekit integrates with [Okta](/organizations-and-access/sso/okta.md) and [Microsoft Entra](/organizations-and-access/sso/entra.md). Once SSO is configured, password login is disabled for your domain. Users authenticate exclusively through your IdP, and access is determined by their IdP group membership.

Group membership changes propagate automatically: remove a user from your IdP and they lose Pipekit access immediately. No accounts to deprovision, no orphan logins.

### Five roles, two binding scopes

Pipekit ships with five roles (Org Admin, Workspace Admin, Editor, Runner, Viewer), bound at either org scope (applies to every workspace) or workspace scope (one workspace). When a user holds bindings at both scopes, the higher-privilege role applies. See the full [permission reference](/concepts/access-control.md#permission-reference) for the exact action set per role.

### Default-deny, enforced at submission

No access is granted implicitly. Namespaces added to a cluster are inaccessible until an Org Admin binds them to a workspace.

Submission is validated at the Pipekit API layer. When a Workflow is submitted via UI, CLI, or [Python SDK](/reference/python-sdk.md), Pipekit checks the authenticated user's bindings cover the target cluster and namespace. If not, the submission is rejected before reaching Argo.

### Per-environment secrets

Secrets are scoped per workspace and per environment. A Pipe in `team-data-prod` can reference different secret values than the same Pipe definition would resolve to in `team-data-dev`, without forking the workflow YAML. See [Pipes > Edit > Secrets](/using-pipekit/pipes/edit/secrets.md).

### Audit trail by design

Every submission carries an authenticated user identity. Pipekit doesn't modify the workflow spec. It validates access and either allows or rejects, so your existing Argo audit and admission controls remain in place underneath.

## See it in practice

The [Infrastructure as Code with OpenTofu](/use-cases/infrastructure-as-code.md) use case shows the governance model in action: per-team workspaces, mutual-exclusion guarantees on the `tofu plan` step, and a separately-scoped `apply` Template that only authorized users can submit.