Limit access to /api/storage/volumes/*/files/*

[ThatGuyJ]

I've been working on automating stuff via REST calls and I ran into an uncomfortable security scenario. The account I used has a dedicated rest-role. In this role it has read/write (all via cli) for /api/storage/volumes. This is necessary for creating and modifying volumes which one of the main goals of the REST calls. If you dig a little deeper into that api path there is /api/storage/volumes/{uuid}/files/{path} which allows you to make some changes directly on files or folders inside a volume and ignores any cifs/nfs acls. Yep, it does that. It's even noted in TR-4569 that it's not recorded in the NAS Audit Log. Concerning to say the least.

I've been trying to figure out a what to limit the access this account has on this deeper api path. Via the web gui it doesn't list that deep of path as an option. Using cli I've tried security login rest-role create -vserver <svmName> -role <roleName> -api "/api/storage/volumes/*/files/*" but get the response "specified uri path is invalid or not suppported. I've also tried dropping the last * but it doesn't recognize that path either. I know the * wildcard works in the command because I've successfully added /api/storage/volumes/*/snapshots. 

Anyone have any ideas? Maybe I'm just being paranoid about having the ability to effect changes to files/folders to which I don't have auditable access, or automation having the same access which feels like a sizeable security hole.

[RobertBlackhart · Accepted solution]

The REST documentation for the /api/security/roles/{owner.uuid}/{name}/privileges endpoint (the equivalent endpoint for the "security login rest-role" command) says this:

This API is used to configure the role privileges (tuples of REST URI paths or command/command directory paths, their access levels and optional queries, where the tuples refer to command/command directory paths). It also retrieves all of the privilege tuples for a role and can add a tuple to an existing role. The "path" attribute can be a resource-qualified endpoint. Currently, the only supported resource-qualified endpoints are the following:

Snapshots APIs
– /api/storage/volumes/{volume.uuid}/snapshots

File System Analytics APIs
– /api/storage/volumes/{volume.uuid}/files
– /api/storage/volumes/{volume.uuid}/top-metrics/clients
– /api/storage/volumes/{volume.uuid}/top-metrics/directories
– /api/storage/volumes/{volume.uuid}/top-metrics/files
– /api/storage/volumes/{volume.uuid}/top-metrics/users
– /api/svm/svms/{svm.uuid}/top-metrics/clients
– /api/svm/svms/{svm.uuid}/top-metrics/directories
– /api/svm/svms/{svm.uuid}/top-metrics/files
– /api/svm/svms/{svm.uuid}/top-metrics/users


In the above APIs, wildcard character * could be used in place of {volume.uuid} or {svm.uuid} to denote all volumes or all SVMs, depending upon whether the REST endpoint references volumes or SVMs.

I interpret that to mean that some deeper API paths are handled, but most are not. The documentation would explain why you were able to specify the /snapshots endpoint but not the /files one under volumes.

I believe you'll need to submit a ticket with support asking for this feature to be enhanced to allow for more granular specificity as you need it.

[ThatGuyJ]

Yep, that's basically what I was gathering from other documentation and from trial/error attempts to limit access via cli. Will take it up with support. 👍