> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubeflow Profiles

> Explains Kubeflow Profiles, workspace isolation by mapping to Kubernetes namespaces, and RBAC role bindings for creating, granting, and verifying team and user access

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).

<Callout icon="lightbulb" color="#1CB2FE">
  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.
</Callout>

<Callout icon="warning" color="#FF6B6B">
  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.
</Callout>

## 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):

```yaml theme={null}
apiVersion: kubeflow.org/v1
kind: Profile
metadata:
  name: team1
spec:
  owner:
    kind: User
    name: jane@example.com
```

Apply the manifest:

```bash theme={null}
kubectl apply -f team1-profile.yaml
```

Verify the Profile and its namespace were created:

```bash theme={null}
# List Profiles
kubectl get profiles

# Confirm the namespace exists
kubectl get namespaces | grep team1
```

Example `kubectl get profiles` output:

```bash theme={null}
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/](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)

## Granting Access to Other Users

You can grant access in two main ways:

1. 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.
2. 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:

```yaml theme={null}
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:

```bash theme={null}
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:

```bash theme={null}
kubectl -n team1 get rolebindings
```

To inspect a specific RoleBinding:

```bash theme={null}
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/](https://www.kubeflow.org/docs/components/misc/profiles/)
* Kubernetes RBAC reference: [https://kubernetes.io/docs/reference/access-authn-authz/rbac/](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
* Kubernetes Namespaces: [https://kubernetes.io/docs/concepts/overview/working-with-objects/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`.

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/kubeflow/module/ba7a7596-0520-4e6b-b3ff-5838082881a0/lesson/f2ad57f9-543c-4897-8572-20876fe7e773" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.