nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Using REST API for snapmirror update

korvemaker

I have a ZAPI script that makes one call to 'snapmirror-update' so that a client can trigger a snapmirror after their data is written. One permissions granted through security login role: 'snapmirror update -destination-path SVMNAME:VOLUMENAME' with access all.

In trying to convert this to REST using the python client library, additional permissions were added:

'snapmirror show -destination-path SVMNAME:VOLUMENAME' with access readonly(which also granted 'snapmirror create')
'job show' with access readonly

The script is effectively:

config.CONNECTION = HostConnection(connect, username=user, password=password, verify=verify)
relationship=SnapmirrorRelationship.find(**{'destination.path':f'{svm}:{volume}'})
transfer=SnapmirrorTransfer(relationship=relationship)
transfer.post()

However, when the post is issued, it fails with:

HTTPError('403 Client Error:
Forbidden for url: https://filer:443/api/snapmirror/relationships/e8b27bcf-8bee-11eb-94d0-00a098aad316/transfers',): not
authorized for that command

If I change 'snapmirror show' from readonly access to all access, it works, but that introduces privilege concerns since that now allows the user to create snapmirror relationships.

Any ideas what I'm missing here?

Find more posts tagged with

ONTAP REST APIs

Accepted answers

RobertBlackhart

This seems to be a limitation for the way the RBAC is defined between the snapmirror/relationships endpoint and the /transfers endpoint under that. The implementation for both of these endpoints specifies that a user must have permissions on the snapmirror command to access both of these endpoints. Since you're doing a POST on the transfers endpoint, that means you need all access on the snapmirror command which then allows relationship creation as well.

I do agree that it could be beneficial for a user/role to have one and not the other. I don't know of a workaround though. I think a request to the development team through support would be needed to assess if this granularity could be added.

All comments

RobertBlackhart

korvemaker

Thanks. Is there a reference somewhere that shows what permissions under 'security login role' are needed for a given REST call? I made educated guesses in this particular case, but it continues to come up.

RobertBlackhart

Not that I know of. I inferred this from looking at the source code. Generally speaking, it shouldn't be necessary for a user to know more granularly than the endpoint itself. The "security login rest-role create" command accepts a "-api" argument which is the endpoint you want to give permissions to and that seems to be the expected interface. When that isn't working as expected, I think it should be treated as a support ticket and a bug.

korvemaker

Thanks. We're heavily using 'security login role' because 'security login rest-role' lacks the necessary granularity to limit access to a subset of volumes and SVMs for most commands. Maybe we'll get something similar to 'show-ontapi' eventually.