Access Policies

Storage provisioners control which members of an organization can access, create, or use ephemeral volumes. Each provisioner defines three independent policies, and each policy may name groups, individual users, or everyone.

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, nobody has that permission. You must explicitly grant access.

Warning

create also governs deletion. Deleting a persistent volume requires create permission on its provisioner and being the volume's creator, an account owner, or an organization owner. Widening create therefore widens who can remove volumes, which is why it is usually granted to named groups or users rather than with all.

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 specific users

A policy may name individual users by email address, in addition to or instead of groups:


my-provisioner:
  driver:
    type: nfs
    target: "nfs-server:/export/data"
  access:
    groups:
      - engineering
    users:
      - alice@example.com
  create:
    users:
      - alice@example.com

Groups and users are additive: a caller is admitted if either list names them. Either may be given alone.

Tip

Prefer a user grant when the permission belongs to a person rather than to a team. A group grant follows whichever group the user currently has selected, so it stops applying as soon as they switch with fuzzball account use. A user grant follows the person.

This is worth knowing because each user's default group is named after their email address, so listing an email under groups appears to work — right up until that user switches to a shared group, at which point it silently stops.

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

all decides the policy on its own and cannot be combined with groups or users — attempting to do so is rejected. Omit the policy entirely to deny it to everyone.

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.

Configuring policies in the Web UI

The Fuzzball Web UI provides a graphical policy editor when creating or editing a storage provisioner. You can configure access, create, and ephemeral policies without writing YAML.

Using the policy field

Each policy (access, create, ephemeral) has a mode selector: choose All groups to grant to everyone, or Specific groups to add individual group names. When you choose Specific groups, click Add group to add each group name in its own input field (and Remove group to delete one).

To deny a policy to all groups, choose Specific groups and add no groups.

Example: Web UI policy configuration

To replicate the "Read-only provisioner with restricted creation" example from the YAML section:

Set the Access policy to All groups.
Set the Create policy to Specific groups and add data-ops.
Leave the Ephemeral policy as needed.

This grants all groups the ability to mount existing volumes, while restricting persistent volume creation to the data-ops group.

Tip

You can copy a provisioner's policy configuration by exporting it via the CLI (fuzzball volume provisioner info <name> -o yaml) and then entering those group names in the Web UI form fields.

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

Overview