Roles and permissions

DonkeyFleet recognizes three realm roles.

Capability	read	approve	administer
View Home, Inventory, Capacity, Audit	Yes	Yes	Yes
View policies and infrastructure	Yes	Yes	Yes
Mark notifications read	Yes	Yes	Yes
Approve, reject, or move eligible work to backlog	No	Yes	Yes
Bind an adopted relationship to a profile	No	Yes	Yes
Register or archive infrastructure	No	No	Yes
Create or change policy	No	No	Yes
Change runtime safety controls	No	No	Yes
Reset local development data	No	No	Yes, when deployment unlocks it

Assign only the lowest role needed. A person who approves deletion should not share accounts, and the identity provider should preserve stable subjects for audit.

ONTAP permissions

Use separate credentials or roles for source and destination clusters:

• source-role credentials need observation (read) access only;
• destination-role credentials need observation plus the specific volume and SnapMirror operations DonkeyFleet manages.

The precise minimum ONTAP RBAC command set is not yet published as a stable product contract. Validate permissions in dry-run and a non-production destination before rollout.

Capability matrix — verifying a credential

Infrastructure → Capabilities probes each registered cluster and reports, per call, whether its stored credential can perform it. Nothing is ever written to a cluster to test this: read calls are checked with a live read, and write capability is read from the credential's own ONTAP role (a side-effect-free read), so a wrong or swapped credential is caught before any relationship is created.

Status	Meaning
Ok	A read succeeded, or a destination write is granted by the role.
Read-only	A source write is correctly denied — a source must never write.
Not available	A destination write is denied by the role — provisioning will fail; use a credential with write access.
Writable	A source write is granted — a source must be read-only, so this is likely a destination credential entered in the source slot.
Deferred	The credential cannot read its own role, so write capability is confirmed on the first Apply instead — honest, not a fault.

A correctly configured pair reads Ok on the destination's volume_create, snapmirror_create, and snapmirror_initialize, and Read-only on the source's. Not available or Writable (shown in red, with a warning banner) means the credential is wrong for that cluster's role — fix it before creating policy.

Letting the probe verify writes (resolving "Deferred")

To report a write as Ok / Read-only / Not available rather than Deferred, the credential must be able to read its own ONTAP role — GET /api/security/accounts and GET /api/security/roles. A strictly least-privilege account cannot, so it reads Deferred. Grant read-only access to those two endpoints to enable verification; this exposes only login and role metadata and adds no operational privilege.

On-premises ONTAP cluster — classic (command-directory) role:

security login role create -role <role> -cmddirname "security login" -access readonly

If that returns "This role is mapped to a rest-role", grant it the REST-role way instead:

security login rest-role create -role <role> -api /api/security/accounts -access readonly
security login rest-role create -role <role> -api /api/security/roles    -access readonly

Add -vserver <svm> for an SVM-scoped role. (A single -api /api/security -access readonly works too, but is broader than needed.)

Amazon FSx for ONTAP cluster (destination):

• Using fsxadmin — it already has this read access, so no change is required.
• Using a dedicated custom role — grant it the same read-only access with the commands above. The built-in fsxadmin and fsx-oncall-* roles cannot be modified, so create a custom role for a least-privilege service account rather than trying to edit fsxadmin.

After granting, click Probe again on the cluster to refresh the matrix.