#Endpoint Validation issue when creating a rest-role

1 messages · Page 1 of 1 (latest)

astral pasture
#

Hi beautiful people, I'm trying to create a rest-role to limit a particular user to only operate on the /protocols/s3/buckets API, however, looks like there's something wacky going on in Ontap as it wont let me create the role because it wont recognize the endpoint:


Error: command failed: Specified URI path is invalid or not supported. Verify that the URI contains only valid characters.```
To me it looks like it's the `"3"` part of the endpoint that is causing an issue, almost like Ontap is tring to validate the URL with a regex that only allows non-numeric or non-special characters.
Infact, if I try to create the same role with an endpoint `/api/protocols/cifs`, or any other protocol that dont have a digit in the endpoint, all is well:
```cluster1::> security login rest-role create -role s3only -api "/api/protocols/cifs" -access read_create_modify -vserver svm1_cluster1

Warning: This operation will also affect the following commands:
    "vserver cifs create"
    "vserver cifs modify"

cluster1::> security login rest-role show -role s3only
               Role                                    Access
Vserver        Name            API                     Level
----------     -------------   -------------------     ------
svm1_cluster1
               s3only          /api/protocols/cifs     read_create_modify

My reasoning on the wrong validation is supported by the fact that if i try to create a role with a non-existant endpoint (but without any digits in the endpoint), the error-message shown is very different:


Error: command failed: URI does not exist.

I'm testing this on Ontap version 9.14.1 atm.
Anyone else sumbled on this? Any feedback is greatly appreciated

#

Endpoint Validation issue when creating a rest-role

rustic bay
#

Try creating the role and adding this to the role (separate steps).

astral pasture
# rustic bay Try creating the role and adding this to the role (separate steps).

hey James, thank you for the link, looks like I missed that article.
Unfortunately, the workaround provided there is not really a workaround for our environment... giving access to /api/protocols/ instead of /api/protocols/s3/buckets/ is not really the level of granularity we were trying to achieve with the principle of least privilege in mind...
I will try to create the role and add the endpoint at a later time, and see if it changes anything. thank you will report back

astral pasture