Access Policies

Storage provisioners use a group-based permission model to control which groups in an organization can access, create, or use ephemeral volumes. Each provisioner defines three independent policies that together determine what operations a group's members can perform.

The three access policies

Policy	YAML Key	Allows	Implies
Access	`access`	Mount existing persistent volumes	—
Create	`create`	Create new persistent volumes	Implies access and ephemeral
Ephemeral	`ephemeral`	Create and use ephemeral (workflow-scoped) volumes	—

Warning

Policies are default-deny. If a policy is not set or is empty, no groups have that permission. You must explicitly grant access.

How implied permissions work

The create policy is the most permissive — groups granted create access can also mount existing volumes and use ephemeral volumes. The access and ephemeral policies are independent of each other.


create  ──► access
create  ──► ephemeral

(access and ephemeral are independent)

A group listed only under access can mount existing persistent volumes but cannot create new volumes or use ephemeral volumes. A group listed only under ephemeral can use ephemeral volumes but cannot mount existing persistent volumes. A group that needs both must be listed under both policies (or under create, which implies both). A group listed under create can do all three.

Granting access

Grant to all groups

Use the all keyword to grant a policy to every group in the organization, including groups created after the provisioner is configured:


my-provisioner:
  driver:
    type: nfs
    target: "nfs-server:/export/data"
  access: all
  ephemeral: all

Grant to specific groups

List group names to restrict a policy to specific groups:


my-provisioner:
  driver:
    type: nfs
    target: "nfs-server:/export/data"
  access:
    - engineering
    - datascience
    - research
  create:
    - engineering
  ephemeral:
    - engineering
    - datascience

In this example:

The engineering group can create persistent volumes, use ephemeral volumes, and mount existing volumes (create implies all three)
The datascience group can use ephemeral volumes and mount existing persistent volumes but cannot create new persistent volumes
The research group can mount existing persistent volumes only

Mixing policies

Each policy is independent. You can grant all on one policy while restricting another:


shared-storage:
  driver:
    type: nfs
    target: "nfs-server:/export/shared"
  access: all
  create:
    - storage-admins
  ephemeral: all

This configuration lets every group mount existing volumes and use ephemeral volumes, but only the storage-admins group can create new persistent volumes.

Decision table

Use this table to determine which policies a group needs:

I want group members to...	Required policy
Mount an existing persistent volume by name	`access` (or `create`)
Create a new persistent volume	`create`
Use ephemeral volumes in workflows	`ephemeral` (or `create`)
Use both persistent and ephemeral volumes	`access` + `ephemeral` (or just `create`)
Do everything — create, mount, and use ephemeral	`create`
Have no storage access at all	Do not list the group in any policy

Group name resolution

When a user submits a workflow or creates a volume, Fuzzball resolves their account to a group name. The resolved group name is then matched against the provisioner's policies.

Note

Group names are case-sensitive. A provisioner granting access to Engineering will not match a user whose group is engineering. Verify exact group names with fuzzball group list.

Examples

Open access provisioner

A provisioner where every group can do everything — suitable for development or testing environments:


dev-storage:
  description: "Development storage — open access"
  driver:
    type: hostpath
    path: /mnt/fuzzball-dev
  access: all
  create: all
  ephemeral: all

Read-only provisioner with restricted creation

A production provisioner where data is pre-populated by administrators and most groups can only mount existing volumes:


reference-data:
  description: "Shared reference datasets — read by all, written by data-ops"
  driver:
    type: nfs
    target: "nfs-prod:/export/reference"
  access: all
  create:
    - data-ops

Per-team provisioners

Separate provisioners for different teams, each with their own storage backend and policies:


ml-storage:
  description: "ML team GPU node storage"
  driver:
    type: hostpath
    path: /mnt/nvme-ml
    local: true
  access:
    - ml-training
    - ml-inference
  create:
    - ml-training
  ephemeral:
    - ml-training
    - ml-inference

Driver Types Annotations and Selection