How do I set up ZenML Pro for enterprise controls (SSO SAML/OIDC, RBAC roles, audit logs, centralized secrets)?

The demo era is over. If you’re running ML and GenAI in a regulated or security‑sensitive environment, you need more than a pretty pipeline graph—you need SSO, RBAC, audit logs, and secrets governance wired into your workflow layer from day one.

This guide walks through how to set up ZenML Pro as that “missing layer” for enterprise controls: connecting SAML/OIDC SSO, defining roles and permissions, wiring in centralized secrets, and making every run auditable across your ML and GenAI pipelines.

All examples assume you’re using ZenML Pro’s managed control plane, but the concepts apply the same if you deploy ZenML in your own VPC.

Quick Answer: ZenML Pro adds an enterprise control plane on top of the open‑source ZenML metadata layer, so you can plug in SAML/OIDC SSO, enforce RBAC, centralize secrets, and capture audit‑ready lineage for every ML and GenAI workflow—without rewriting your stack or picking a single orchestrator.

The Quick Overview

What It Is: ZenML Pro is a managed, multi‑tenant control plane on top of ZenML OSS, with built‑in SSO, roles/permissions, enhanced observability, and model governance features.
Who It Is For: Platform, security, and ML engineering teams that need SOC2/ISO‑grade controls around AI workflows running on Kubernetes, Slurm, or existing orchestrators like Airflow and Kubeflow.
Core Problem Solved: It eliminates “shadow MLOps” (ad‑hoc scripts, local secrets, missing lineage) by centralizing authentication, authorization, secrets, and audit trails across all your ML and GenAI pipelines.

How ZenML Pro Enterprise Controls Work

At a high level, you’re layering ZenML Pro’s control plane on top of your existing infrastructure:

Identity flows through your IdP (SAML/OIDC) into ZenML.
Authorization is expressed as roles and permissions attached to workspaces, stacks, and resources.
Secrets (API keys, tool credentials, connection strings) are centralized and injected into runs at execution time.
Every pipeline run (from Scikit‑learn training jobs to LangGraph agent loops) emits metadata and lineage into ZenML, giving you an audit‑ready history.

The rollout usually follows three phases.

Connect Identity (SSO with SAML/OIDC):
Integrate ZenML Pro with your IdP (Okta, Azure AD, Google, etc.) so all access is federated. This gives you centralized authentication, MFA, and lifecycle control.
Define Access (RBAC & Workspaces):
Model your org structure using ZenML workspaces and roles. Assign teams to workspaces and apply least‑privilege permissions to pipelines, stacks, models, and secrets.
Harden Operations (Audit + Secrets):
Turn on centralized secrets, validate audit coverage (who ran what, with which code and dependencies), and wire this into your compliance flows (SOX, GDPR, internal risk).

Phase 1: Connect ZenML Pro to SAML/OIDC SSO

Stop managing ZenML users manually. Let your IdP do the heavy lifting.

1.1 Prepare your ZenML Pro tenant

Once you have a ZenML Pro tenant:

Identify your environments: dev, staging, prod servers (ZenML Pro supports separate servers per environment).
Decide which will be SSO‑enforced only (typically staging/prod) vs also allowing local accounts (dev/experiments).

Your ZenML contact (or admin panel) will expose SSO configuration points for:

SAML or OIDC metadata
Redirect / callback URLs
Allowed email domains / IdP groups

1.2 Configure OIDC (typical for modern IdPs)

For OIDC, you’ll:

Create an application in your IdP (e.g., Okta “OIDC Web App,” Azure AD “App registration”).
Set redirect URIs to ZenML Pro’s callback URL (provided in your tenant).
Enable standard scopes: openid, profile, email as a minimum.
Configure claims mapping (recommended):
- email → user identity in ZenML
- groups or roles → used to map IdP groups to ZenML roles or workspaces
Copy client ID, client secret, and issuer URL into ZenML Pro’s OIDC configuration.

ZenML then:

Validates tokens from your IdP.
Creates or maps users automatically based on email / subject claim.
Optionally auto‑assigns roles based on IdP group membership.

1.3 Configure SAML (common in regulated enterprises)

For a SAML‑based IdP:

Create a SAML app in your IdP.
Import ZenML’s SP metadata (or manually specify ACS URL and Entity ID from your ZenML tenant).
Configure SAML attributes:
- Email → user’s primary email
- FirstName, LastName (optional)
- Groups / Role (optional) for RBAC mapping
Download IdP metadata XML and upload it to ZenML Pro.

Once wired:

All logins go through your IdP’s SAML flow.
MFA, conditional access, and session policies are enforced centrally.
Deprovisioning a user from your IdP instantly removes access to ZenML.

1.4 Recommended SSO deployment pattern

Dev server: Allow both SSO and local accounts (for vendor access, experiments).
Staging / Prod servers: Enforce SSO only, disabled local signup.
Group‑based access: Use IdP groups like ml-engineering, data-science, security for initial role mapping inside ZenML.

Phase 2: Set Up RBAC Roles and Workspaces

Orchestration without access control is theater. You need clear boundaries around who can define stacks, view runs, and touch secrets.

ZenML Pro extends the open‑source product with:

Workspaces: Logical containers for pipelines, stacks, and artifacts (e.g., retail-pricing, customer-support, risk-scoring).
Roles & Permissions: Fine‑grained privileges (read, write, admin) applied to users and service accounts.

2.1 Model your org with workspaces

Start by structuring workspaces along clear boundaries:

By domain: marketing-ml, fraud-ml, ops-forecasting
By product line: search-ranking, recommendations, genai-assistants
By environment: risk-scoring-dev, risk-scoring-prod (for stricter isolation)

For each workspace, decide:

Which teams are allowed to push pipelines (engineers).
Who can only view runs and artifacts (analysts, auditors).
Which environments need the strictest controls.

2.2 Define core roles

While exact role names may vary, a typical setup in ZenML Pro looks like:

Workspace Admin:
Can manage pipelines, stacks, and workspace‑level configuration. Ideal for ML platform leads.
Engineer / Contributor:
Can create and update pipelines, run them, and manage artifacts within a workspace.
Reviewer / Auditor:
Read‑only access to runs, lineage, and logs. No deploy or write privileges.
Secrets Manager (optional):
Can create and manage secrets, but cannot necessarily modify pipelines.

Map these ZenML roles to IdP groups via SAML/OIDC claims:

IdP group ml-platform-admins → ZenML “Workspace Admin”
IdP group ml-engineers → ZenML “Contributor”
IdP group risk-auditors → ZenML “Reviewer / Auditor”

This way, joining/leaving a team in your IdP automatically adjusts ZenML access.

2.3 Enforce least privilege

To avoid “everyone is admin” sprawl:

Make prod workspaces read‑only for most users; limit write and deploy access to a small group.
Use workspace scoping so teams only see pipelines and secrets relevant to their domain.
Avoid placing secrets or high‑risk stacks in “shared” playground workspaces.

RBAC then extends down to:

Pipelines and runs
Stacks and stack components (orchestrators, artifact stores, etc.)
Models and model registry entries
Secrets and credential stores

Phase 3: Audit Logs, Lineage, and Centralized Secrets

Now that identity and access are stable, you can harden the operational surface.

3.1 Make every run auditable

With ZenML’s metadata layer, each pipeline run captures:

Execution trace: Which steps ran, in what order, with which inputs/outputs.
Code & environment snapshots: Versioned code, dependency sets (e.g., Pydantic versions), container state.
Artifact lineage: From raw data input to model artifacts to final GenAI agent response.
Who/what triggered the run: Human user, CI/CD system, or scheduled run.

ZenML Pro enhances this with:

A richer dashboard for observability across workspaces.
A model control plane to view all your ML models, versions, and deployments.
The ability to trigger pipelines and CI/CD directly from the server UI.

This gives auditors and security teams a single place to answer:

“Who changed this pipeline and when?”
“Which training data and dependencies produced this model?”
“Which version of this LangChain or LangGraph agent is serving traffic right now?”

3.2 Integrate audit logs with your compliance stack

Once you rely on ZenML as the metadata layer, you can:

Export or mirror run metadata into your SIEM or data warehouse.
Attach pipeline run IDs to change management tickets.
Use lineage views during model risk committee reviews.

Common patterns:

Link CI/CD pipeline IDs to ZenML run IDs for traceability.
Require a successful audited run in staging before a prod promotion.
Use ZenML’s history to demonstrate SOC2 Type II / ISO 27001 control coverage around AI workflows.

3.3 Centralized secrets: stop scattering API keys

Ad‑hoc .env files and notebook secrets are a liability. ZenML Pro allows you to centralize secrets so that:

API keys for OpenAI, Anthropic, model hosts, or LlamaIndex backends live in a central store.
Database credentials, object storage keys, and internal APIs are injected at execution time into your steps.
Developers never need direct access to production credentials to run pipelines.

Typical setup:

Define secret scopes per workspace and environment (genai-assistants-prod, risk-scoring-staging).
Create secrets for:
- LLM providers and tools (for LangChain/LangGraph agents).
- Data stores (Postgres, Snowflake, S3, GCS).
- Vector DBs and retrieval layers (e.g., used via LlamaIndex).
Attach secrets to stacks or steps using ZenML’s Python configuration. Pipelines reference secret names, not raw credentials.
Restrict who can view or edit secrets via RBAC:
- Engineers can use secrets in pipelines.
- Only a small group can manage or rotate them.

Operationally, this gives you:

Centralized rotation: swap keys once in ZenML, pipelines pick up the new values.
Reduced blast radius: secrets never leak in code repos or notebooks.
Clear audit trail: who created/modified which secret, when, and for which stack.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Managed Control Plane	Provides multi‑tenant, fully managed ZenML servers (dev/staging/prod) with enhanced UI	Centralizes governance and observability without rebuilding your infra or choosing one orchestrator
SSO (SAML/OIDC) Integration	Connects ZenML to your IdP for login, MFA, and lifecycle management	Eliminates local accounts and shadow access; access is fully governed via your IdP
RBAC Roles & Workspaces	Defines fine‑grained roles and workspace boundaries for teams and resources	Enforces least privilege and clean separation between domains and environments
Enhanced Observability & Lineage	Captures execution traces, artifacts, and environment snapshots for every run	Makes every ML/GenAI workflow auditable end‑to‑end, supporting SOC2/ISO and internal risk review
Centralized Secrets Management	Stores and injects credentials and API keys into pipelines and stacks	Removes credentials from code and notebooks; simplifies rotation and compliance

Ideal Use Cases

Best for regulated ML/GenAI workloads: Because it lets you enforce SSO, RBAC, and secrets policies across pipelines without forcing you off Kubernetes, Slurm, Airflow, or Kubeflow.
Best for multi‑team AI platforms: Because you can separate work by workspace and environment, giving different teams autonomy while keeping governance centralized.

Limitations & Considerations

Requires initial RBAC design: You’ll need to invest a bit of upfront time to define workspaces, roles, and IdP group mapping. The workaround is to start with a minimal role set (Admin, Engineer, Auditor) and refine.
SSO plumbing depends on your IdP: SAML/OIDC configuration can be nuanced, especially with complex group mappings or conditional access. Coordinate with your IdP owner and test dev/staging before enforcing in prod.

Pricing & Plans

ZenML follows an “Open Source foundation, Pro for enterprise controls” model:

The open‑source ZenML provides the core metadata layer, pipeline orchestration hooks, and local usage.
ZenML Pro adds the managed multi‑tenant control plane, RBAC, SSO integration, enhanced dashboard, and enterprise governance capabilities described above.

Typical mapping:

ZenML OSS: Best for individuals or small teams prototyping ML/GenAI workflows and proving out the metadata‑layer approach locally.
ZenML Pro: Best for organizations that need multi‑environment deployments (dev/staging/prod), SAML/OIDC SSO, RBAC, auditability, and centralized secrets at scale.

For exact pricing and deployment models (including “your VPC, your data” options), talk directly to the ZenML team.

Frequently Asked Questions

Do I need to change my orchestrator (Airflow/Kubeflow) to use ZenML Pro enterprise controls?

Short Answer: No. ZenML doesn’t replace your orchestrator; it adds a metadata and control layer on top.

Details:
ZenML is explicitly designed to work with your existing infrastructure and orchestrators. You can keep Airflow for scheduling, Kubeflow for some training workloads, and Kubernetes/Slurm as your compute backbone. ZenML Pro sits above that stack:

Orchestrators still run your jobs.
ZenML tracks code, environment, artifacts, and execution traces.
SSO, RBAC, and secrets are enforced at the ZenML layer.

This means you get unified governance and auditability across ML and GenAI workflows without a disruptive migration to a “one true orchestrator.”

How does ZenML Pro help me pass security and compliance reviews?

Short Answer: It centralizes identity, access control, secrets, and lineage so you can prove who did what, with which data and code, for every model and agent.

Details:
Security and compliance teams typically care about:

Authentication & Authorization: SAML/OIDC SSO and RBAC show exactly who can access what.
Secrets Management: Centralized storing and rotation of API keys and credentials avoids ad‑hoc secret sprawl.
Audit Logging & Lineage: Every run is traceable, with code/dependency snapshots and data lineage from input to final output.
Environment Isolation: Separate ZenML Pro servers and workspaces for dev/staging/prod reduce risk and simplify controls.

Combined with ZenML’s SOC2 Type II and ISO 27001 posture, this gives you credible answers to “who changed this,” “how was this model trained,” and “where do these secrets live” during audits and risk reviews.

Summary

If you’re serious about running ML and GenAI in production, you can’t bolt on enterprise controls after the fact. ZenML Pro turns your workflow metadata layer into a control plane: SAML/OIDC SSO for identity, RBAC for access, centralized secrets for credentials, and full auditability for every training job and agent loop.

You keep your orchestrators and infra. ZenML just makes them governable: every run diffable, traceable, and rollbackable, with access and secrets under control.

Next Step

Get Started