Kubeflow Profiles

In this lesson we’ll explain Kubeflow Profiles: what they are, how they map to Kubernetes primitives, and how to grant and verify access for teams and users. When Kubeflow runs on a shared Kubernetes cluster, multiple users and teams create resources (notebooks, training jobs, experiments, etc.). To prevent teams from interfering with each other, you need isolation and role-based access control (RBAC) so Team A cannot list, modify, or delete Team B’s resources. Kubeflow Profiles provide that isolation. A Profile represents a workspace for a team or user; it maps to Kubernetes objects (typically a Namespace) and the RBAC RoleBindings required to control access. Conceptually:

Create one Profile per team or workspace (for example, team1).
Members granted access to that Profile can operate within its workspace.
You can assign different privileges per member (admin, edit, view).

Profiles are implemented by the Kubeflow profiles controller. Creating a Profile typically results in a Kubernetes Namespace being created (one-to-one with the Profile name) plus RoleBindings that grant kubeflow-admin, kubeflow-edit, and kubeflow-view roles inside that namespace.

Before creating Profiles, ensure the Kubeflow Profiles CRD and profiles controller are installed and running on your cluster. Creating Profiles usually requires cluster-admin privileges for the controller to create namespaces and RoleBindings.

Creating a Profile

A Profile is a Kubernetes custom resource of kind Profile. The spec.owner field sets the initial owner who receives admin privileges for the workspace. Example Profile manifest (team1-profile.yaml):

apiVersion: kubeflow.org/v1
kind: Profile
metadata:
  name: team1
spec:
  owner:
    kind: User
    name: jane@example.com

Apply the manifest:

kubectl apply -f team1-profile.yaml

Verify the Profile and its namespace were created:

# List Profiles
kubectl get profiles

# Confirm the namespace exists
kubectl get namespaces | grep team1

Example kubectl get profiles output:

NAME                         AGE
kubeflow-user-example-com    44h
team1                        155m

The spec.owner (jane@example.com in the example) receives kubeflow-admin privileges inside the team1 namespace and can manage access for other users.

Roles and Permissions

Kubeflow relies on Kubernetes RBAC and defines (or uses) a set of common ClusterRoles per Profile. Typical roles are:

Role	Scope	Typical permissions
`kubeflow-admin`	Namespace (per-profile)	Full administrative privileges in the Profile namespace; can manage RoleBindings and access.
`kubeflow-edit`	Namespace (per-profile)	Create, update, and delete most ML workloads and resources in the namespace; cannot manage access.
`kubeflow-view`	Namespace (per-profile)	Read-only access to view resources and status in the namespace.

When the profiles controller creates a namespace it usually also creates RoleBindings that grant the spec.owner the kubeflow-admin role for that namespace. For more on RBAC concepts see the Kubernetes docs: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Granting Access to Other Users

You can grant access in two main ways:

Kubeflow UI (Dashboard) — quick, user-friendly way to add users with the Edit role for a Profile. The UI typically handles creating the underlying RoleBinding.
Kubernetes manifests (RoleBinding / ClusterRoleBinding) — gives you precise control over which ClusterRole is bound and to which Subject (User, Group, or ServiceAccount).

Example: grant the user alice@example.com the kubeflow-edit role in the team1 namespace by creating a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team1-edit-alice
  namespace: team1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubeflow-edit
subjects:
- kind: User
  name: alice@example.com
  apiGroup: rbac.authorization.k8s.io

Apply it with:

kubectl apply -f team1-edit-alice.yaml

You can similarly bind kubeflow-view for read-only access or kubeflow-admin for additional admins. To list RoleBindings in the namespace:

kubectl -n team1 get rolebindings

To inspect a specific RoleBinding:

kubectl -n team1 describe rolebinding team1-edit-alice

Troubleshooting & Best Practices

Ensure the profiles controller is healthy and the Profile CRD exists:
- kubectl get crd profiles.kubeflow.org
- kubectl -n <kubeflow-system-namespace> get pods (look for the profiles controller)
Use fine-grained RoleBindings when you need precise access control. Use Groups (if available in your identity provider) instead of many individual user bindings for easier management.
Keep a naming convention for Profiles and namespaces (for example, team-<name> or kubeflow-<team>) to avoid collisions and to make RBAC audits easier.

Links and References

Kubeflow Profiles (official docs): https://www.kubeflow.org/docs/components/misc/profiles/
Kubernetes RBAC reference: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Kubernetes Namespaces: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/

Summary

Profiles isolate Kubeflow workspaces by mapping to Kubernetes namespaces and creating RBAC bindings.
A Profile manifest declares an owner who initially receives kubeflow-admin rights for that workspace.
Use the Kubeflow UI for quick role assignments or Kubernetes RoleBindings for precise control.
Typical per-profile roles are kubeflow-admin, kubeflow-edit, and kubeflow-view.

Course Introduction

Fundamentals of Kubeflow

Working With Kubeflow

KServe and Katib

Profiles and Multi-Tenancy

Bringing It All Together

Creating a Profile

Roles and Permissions

Granting Access to Other Users

Troubleshooting & Best Practices

Links and References

Summary

Watch Video

​Creating a Profile

​Roles and Permissions

​Granting Access to Other Users

​Troubleshooting & Best Practices

​Links and References

​Summary

Watch Video

Creating a Profile

Roles and Permissions

Granting Access to Other Users

Troubleshooting & Best Practices

Links and References

Summary