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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

1. Set the Access policy to All groups.
2. Set the Create policy to Specific groups and add data-ops.
3. 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.

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.

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