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.

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

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.

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

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

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.

Use this table to determine which policies a group needs:

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.

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.

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

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

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