Access & Permissions

Notebook access is controlled through the RBAC system using per-resource permissions and optional object-level ownership.

Permission Levels

Notebook access is controlled through the RBAC system. The following permissions apply to the jupyter resource:

Permission	Description
jupyter:read	See all notebooks in the cluster
jupyter:read_own	See only notebooks where you are the owner
jupyter:write	Create new notebook instances
jupyter:delete	Delete notebook instances

Object-Level Access (read_own)

The jupyter:read_own permission enables object-level security: users can only see and open notebooks where their user account is set as the owner.

This is the recommended setting for multi-tenant deployments where each user should only access their own environment.

Setting Up read_own

1. Go to Settings → Roles
2. Create or edit a role (e.g., “Notebook User”)
3. Under the Jupyter section, enable Read Own
4. Assign this role to users

Assigning Ownership

When creating a notebook, select the owner from the Owner dropdown. A notebook without an owner is not visible to users with read_own — only admins can see it.

To reassign ownership, use the Admin Chat:

Assign notebook "data-analysis" to user alice@example.com

Or update the Kubernetes annotation directly:

kubectl annotate deployment/data-analysis \
  ftn-ai.io/owner=alice@example.com \
  -n apps --overwrite

Admin Access

Users with the admin role always have full access to all notebooks regardless of ownership. The jupyter:read permission (without _own) also grants visibility into all notebooks.

URL Security

Each Jupyter instance uses a unique token for authentication. The auto-login URL contains this token and is specific to each instance. Users should treat the auto-login URL as a password and not share it publicly.

The token is regenerated each time the notebook pod restarts.