Governance
Workspaces, IdP-backed RBAC, audit-quality access enforcement.
Last updated
Workspaces, IdP-backed RBAC, audit-quality access enforcement.
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.
{cluster, namespace} pairs to teamsA workspace 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.
Pipekit integrates with Okta and Microsoft Entra. 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.
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 for the exact action set per role.
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, Pipekit checks the authenticated user's bindings cover the target cluster and namespace. If not, the submission is rejected before reaching Argo.
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.
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.
The Infrastructure as Code with OpenTofu 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.
Last updated