
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 regulated, multi-team AI workloads, you don’t need another toy UI—you need SSO, RBAC, audit logs, and centralized secrets wired into the same layer that orchestrates your ML and GenAI pipelines.
ZenML Pro is that layer. It takes the open-source core your engineers already use and adds the enterprise controls security and platform teams expect: SAML/OIDC single sign-on, workspace-level RBAC, audit-ready run histories, and governed secret handling. Your VPC, your data; ZenML just becomes the metadata and control plane on top.
Quick Answer: To set up ZenML Pro for enterprise controls, you deploy a managed or self-hosted Pro control plane, connect it to your IdP via SAML/OIDC, define roles and workspaces, centralize secrets in the ZenML control plane or a backing vault, and enable the Pro dashboard features that expose audit trails, model views, and CI/CD triggers.
The Quick Overview
- What It Is: ZenML Pro is the enterprise edition of ZenML—a managed, multi-tenant control plane that layers SSO, RBAC, auditability, and governance on top of your existing ML and GenAI workflows.
- Who It Is For: ML platform teams, security/compliance groups, and AI product teams that need reproducible, auditable pipelines spanning Scikit-learn training jobs and complex LangGraph agent loops—without giving up their orchestrators or their VPC boundaries.
- Core Problem Solved: It removes the “shadow MLOps” problem: ad‑hoc scripts, unmanaged API keys, and untraceable runs. Instead you get a standardized metadata layer where access, secrets, lineage, and approvals are all centrally controlled.
How It Works
At a high level, ZenML Pro adds a managed control plane on top of your existing infrastructure. Engineers still define pipelines in Python; Airflow, Kubeflow, or other orchestrators still run jobs in your clusters. The Pro layer sits above this to:
- Authenticate users via your SAML/OIDC provider.
- Segment projects and teams into workspaces.
- Enforce role-based permissions across pipelines, stacks, and models.
- Store and govern secrets for tools and APIs.
- Provide an enhanced dashboard with model views, pipeline triggers, CI/CD hooks, and rich run/audit views.
Think of it as: “metadata + governance + control,” not “new orchestrator you must adopt.”
1. Provision the ZenML Pro Control Plane
You start by deploying or subscribing to a ZenML Pro control plane:
-
Choose deployment mode:
- Managed ZenML Pro: Multi-tenant, fully-managed by ZenML. You get separated dev/staging/prod servers and workspaces out of the box.
- Self-hosted in your VPC: For stricter sovereignty, deploy the ZenML Pro control plane into your own Kubernetes cluster. Your VPC, your data.
-
Create environments:
- Stand up dev, staging, and production servers to mirror your SDLC.
- Use workspaces to segment teams (e.g., “Risk-Scoring,” “Customer-Support-Agent,” “Recommendation-Engine”).
-
Connect your compute & storage:
- Register stacks pointing at your existing infrastructure: Kubernetes, Slurm, cloud storage, experiment tracking, etc.
- Keep Airflow, Kubeflow, or other orchestrators in place; ZenML Pro integrates as the metadata layer and control panel, not a replacement.
2. Integrate SSO via SAML/OIDC
Next, you connect ZenML Pro to your identity provider (IdP) so you stop managing local accounts and passwords.
- Choose protocol: ZenML Pro supports SAML and OIDC.
- Create an application in your IdP:
- In Okta, Azure AD, Google Workspace, or your chosen IdP, create a new SAML/OIDC app named “ZenML Pro.”
- Set the redirect/callback URL to the ZenML Pro control plane URL (provided by ZenML or your self-hosting deployment).
- Configure claims/mappings:
- Map IdP attributes to ZenML user fields:
email→ user emailname→ display name- Optional:
groups→ ZenML roles or workspace memberships.
- Map IdP attributes to ZenML user fields:
- Exchange metadata:
- From ZenML Pro, export or copy the SP/Client metadata (ACS URL, Entity ID, Client ID/Secret for OIDC).
- From your IdP, paste the IdP metadata (Issuer, SSO URL, certificate or JWKS).
- Test login:
- Log out of ZenML Pro.
- Select “Sign in with SSO” and verify that users can authenticate using your enterprise identity.
Once SSO is connected, all user access is centrally controlled by your IdP. Disable a user in Okta, and they lose access to ZenML immediately.
3. Define RBAC: Roles, Workspaces, and Permissions
Orchestration without access control is just a friendly chaos engine. ZenML Pro adds built-in roles and permissions on top of the open-source product.
-
Enable workspaces for multi-team isolation:
- Create workspaces per domain or program:
fraud-detection,genai-support,marketing-ml. - Restrict workspace membership so teams don’t see each other’s stacks, pipelines, or artifacts by default.
- Create workspaces per domain or program:
-
Configure roles: Typical role patterns you’ll want:
- Viewer: Read-only access to runs, artifacts, models, and logs. Great for auditors and stakeholders.
- Contributor: Can run pipelines, register stacks, and manage their own secrets; cannot modify global settings.
- Workspace Admin: Full control within a workspace: manage stacks, secrets, and pipeline triggers.
- System Admin: Cross-workspace control: manage users, roles, SSO config, and global integrations.
-
Map IdP groups to roles:
- Map security groups like
ml-platform-admins,ds-contributors,ml-viewersto ZenML roles per workspace. - This gives you “RBAC as code” at the IdP level: adjust membership in your directory; permissions flow automatically.
- Map security groups like
-
Enforce principle of least privilege:
- Only ML platform and infra engineers get admin.
- Researchers get contributor or viewer rights; they shouldn’t be able to tweak production stacks or secrets.
4. Centralize Secrets and Tool Credentials
Stop spreading API keys across notebooks, YAML files, and CI variables. ZenML Pro gives you a centralized secret management layer integrated with stacks and pipelines.
-
Choose a backing store (optional):
- You can use ZenML’s built-in secret store.
- Or integrate with your existing vault (e.g., HashiCorp Vault, cloud KMS) and let ZenML act as a governance and access shim.
-
Create secret scopes:
- Secrets for LLM providers (OpenAI, Anthropic, Azure OpenAI).
- Secrets for vector DBs (Pinecone, Weaviate, Elastic).
- Secrets for data sources (Postgres, Snowflake, S3).
- Declare them once in the ZenML Pro dashboard, not in code.
-
Bind secrets to stacks and steps:
- Attach relevant credentials to the stack or step that needs them (e.g., retrieval step using LlamaIndex, reasoning with LangChain, training with PyTorch).
- Pipelines reference secret names, not raw keys. Code stays clean; rotation is centralized.
-
Control access via RBAC:
- Limit who can view, create, or update secrets.
- Ensure auditors can verify which pipelines had access to which credentials without exposing values.
5. Turn On Auditability: Run History, Lineage, and Logs
The goal is not “visibility” as a buzzword; it’s a complete, audit-ready picture: who ran what, where, with which code and data.
ZenML Pro extends the open-source lineage and metadata with an enhanced dashboard and control features:
-
Execution traces and lineage:
- For every pipeline run, ZenML snapshots:
- The exact code executed.
- Dependency versions (including Pydantic, frameworks, libraries).
- Container state and environment.
- Artifacts produced at each step (datasets, models, evaluation metrics, agent logs).
- This gives you a full chain from raw data to final model or agent response.
- For every pipeline run, ZenML snapshots:
-
Model control plane:
- Use the Pro dashboard’s model view to see all ML models across workspaces.
- Track versions, promotions (dev → staging → prod), and which pipelines produced each model artifact.
-
Audit trails and user activity:
- Inspect who triggered which pipelines, from where (CLI, CI, UI), and with what configuration overrides.
- Use run history to answer regulatory questions like “Which model version was serving responses on date X?” or “What changed when latency or accuracy dropped?”
-
Diff and rollback workflows:
- When a library update breaks an agent workflow, compare runs:
- Diff code, dependency manifest, and container images.
- Roll back to a previous, known-good environment with a controlled release pipeline instead of guesswork.
- When a library update breaks an agent workflow, compare runs:
6. Integrate CI/CD and Production Controls
Once enterprise controls are in place, you wire ZenML Pro into your CI/CD so that production changes flow through governed pipelines, not ad-hoc runs.
-
Pipeline triggers and CI integrations:
- Use the Pro dashboard to trigger pipelines from the UI or hook them into your CI system (GitHub Actions, GitLab CI, Jenkins).
- Push events (e.g., new commit on main, new dataset version) to ZenML to kick off training, evaluation, and deployment pipelines.
-
Environment separation:
- Use dev/staging/prod servers and workspaces to model your release process.
- Promote models via governed pipelines instead of copying files or hand-editing configs.
-
Guardrails and approvals (process-level):
- Combine RBAC and audit logs with your internal approvals:
- Only specific roles can trigger prod deployments.
- Every run is logged, including who approved and from which change request.
- Combine RBAC and audit logs with your internal approvals:
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| Managed Pro Control Plane | Provides a multi-tenant, fully-managed ZenML server with dev/staging/prod environments. | Standardizes AI workflows without rebuilding infra; keeps your data in your VPC. |
| SSO (SAML/OIDC) + RBAC | Connects to your IdP and enforces role-based permissions across workspaces and resources. | Centralizes identity and access control; passes security reviews without heroics. |
| Centralized Secrets Management | Stores and governs API keys and credentials for tools, data, and LLM providers. | Eliminates credential sprawl; simplifies rotation and access governance. |
| Enhanced Observability Dashboard | Adds model control plane, triggerable pipelines, CI/CD hooks, and rich run/audit views. | Makes every run traceable, diffable, and rollbackable from one interface. |
| Artifact & Environment Lineage | Snapshots code, dependencies, container state, and artifacts for every pipeline step. | Reproducible, audit-ready history of ML and GenAI workflows across orchestrators. |
Ideal Use Cases
- Best for regulated teams (finance, healthcare, gov): Because it gives you SSO, RBAC, full lineage, and auditable logs across all ML and GenAI pipelines without forcing you to move data out of your VPC.
- Best for multi-team platform scenarios: Because it allows you to split work into workspaces, connect Airflow or Kubeflow, and standardize secrets and release workflows while keeping teams decoupled but governed.
Limitations & Considerations
- Requires initial coordination with security/IT: SAML/OIDC integration and RBAC design involve your IdP owners. Plan for a short joint implementation window rather than treating it as a developer-only task.
- Not a replacement for all infra tooling: ZenML Pro is the metadata and control layer. You still need orchestrators, clusters, and storage; Pro makes them manageable and auditable, it doesn’t replace them.
Pricing & Plans
ZenML Pro sits on top of the open-source ZenML core. You start with OSS, and when you upgrade to Pro, your existing pipelines keep running exactly as they are—only now they’re governed and observable from a centralized control plane.
Typical plan patterns:
- Team / Pro Plan: Best for ML teams needing SSO, workspaces, and basic RBAC to standardize ML and GenAI workflows across a few environments.
- Enterprise Plan: Best for organizations needing multi-tenant deployments (dev/staging/prod servers), advanced RBAC, integration with existing vaults and IdPs, and support for SOC2/ISO 27001-level compliance workflows.
For exact pricing, deployment models, and feature tiers, use the signup flow or talk to ZenML directly.
Frequently Asked Questions
Do I have to replace my existing orchestrator (Airflow, Kubeflow) to use ZenML Pro?
Short Answer: No. ZenML Pro is a metadata and control layer that works with your existing orchestrators.
Details: ZenML deliberately avoids taking a hard opinion on orchestration. If you already run Airflow for scheduling and Kubeflow for training workloads, keep them. ZenML Pro sits above those systems to standardize how you define pipelines in Python, track artifacts and environments, and enforce RBAC, secrets, and auditability. Your DAGs still run where they run today; you just get a unified view and control plane on top.
How does ZenML Pro help with compliance and audits?
Short Answer: It gives you SSO, RBAC, centralized secrets, and full run lineage so you can answer “who ran what, with which data and model” on demand.
Details: For every pipeline, ZenML Pro records execution traces, artifacts, code snapshots, dependency manifests, and container state. Combined with SAML/OIDC-backed identities and workspace-level RBAC, you can show auditors exactly which users had access to which secrets, which model version was serving at a given time, and what changed between two deployments. Deployed in your VPC and aligned with SOC2 Type II and ISO 27001 practices, ZenML Pro becomes the audit-ready metadata backbone for your ML and GenAI estate.
Summary
If you’re serious about ML and GenAI in production, “it worked on my machine” and “the key is in that notebook” are not acceptable operating models. ZenML Pro turns your existing stack into a governed platform: SSO and RBAC for who can do what, centralized secrets for how tools talk to each other, and audit-ready lineage for every run. You keep your orchestrators, clusters, and data where they are; ZenML becomes the missing metadata layer that makes everything traceable, reproducible, and controllable.