Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:Kserve Kserve Kubeflow Integration

From Leeroopedia
Knowledge Sources
Domains Kubernetes, Security, Platform_Integration
Last Updated 2026-02-13 00:00 GMT

Overview

A role-based access control integration pattern that aligns KServe resource permissions with Kubeflow's multi-tenant profile and namespace isolation model.

Description

Kubeflow Integration bridges KServe's custom resource access model with Kubeflow's multi-tenancy framework. Kubeflow organizes users into profiles, each mapped to a Kubernetes namespace, and uses ClusterRoles and RoleBindings to control what resources users can access within their namespace.

For KServe resources (InferenceService, ServingRuntime, TrainedModel, InferenceGraph) to work within Kubeflow's permission model, dedicated ClusterRoles must be defined that grant the appropriate verb permissions (get, list, watch, create, update, patch, delete) on KServe custom resource types. These ClusterRoles are then bound to Kubeflow's standard role aggregation labels, so that when Kubeflow creates a RoleBinding for a user in their profile namespace, the KServe permissions are automatically included.

Usage

Use this principle when:

  • Deploying KServe as a component within a Kubeflow platform
  • Configuring multi-tenant access to inference services
  • Ensuring data scientists in one namespace cannot access models in another
  • Extending Kubeflow's RBAC model to cover new KServe resource types

Theoretical Basis

# Kubeflow RBAC integration pattern (NOT implementation code)
Kubeflow's role aggregation model:
  1. Kubeflow defines aggregate ClusterRoles with labels:
     - rbac.authorization.kubeflow.org/aggregate-to-kubeflow-admin
     - rbac.authorization.kubeflow.org/aggregate-to-kubeflow-edit
     - rbac.authorization.kubeflow.org/aggregate-to-kubeflow-view
  2. Component-specific ClusterRoles carry these labels
  3. Kubernetes automatically aggregates rules into parent ClusterRoles

KServe ClusterRoles:
  kserve-admin:
    labels: aggregate-to-kubeflow-admin
    rules:
      - apiGroups: ["serving.kserve.io"]
        resources: [inferenceservices, servingruntimes, ...]
        verbs: [get, list, watch, create, update, patch, delete]
  kserve-edit:
    labels: aggregate-to-kubeflow-edit
    rules: (same resources, same verbs)
  kserve-view:
    labels: aggregate-to-kubeflow-view
    rules:
      - apiGroups: ["serving.kserve.io"]
        resources: [inferenceservices, servingruntimes, ...]
        verbs: [get, list, watch]

Permission flow:
  User → Kubeflow Profile → Namespace → RoleBinding → Aggregated ClusterRole
    → KServe ClusterRole rules included → access to InferenceServices

Related Pages

Implemented By

Related Principles

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment