I'm building an automation suite to handle some of the day to day for our storage administrators. In doing so I want to grant the service user the least privilege necessary to achieve the desired outcome. Since updating my Ansible machine to the current dev release even na_ontap_gather_facts doesn't work without some sort of write permissions.
clustername::*> security login role show -role ansible-user
Role Command/ Access
Vserver Name Directory Query Level
---------- ------------- --------- ----------------------------------- --------
clustername ansible-user DEFAULT readonly
system node autosupport all
2 entries were displayed.
Note that I've added the 'autosupport / all' component as that's the first change I want to test.
I could sift through the Ansible code, but it seems to me that there should be a more straightforward way from the audit log to identify the specific privilege requested that's being denied. This is what is in the audit log:
Tue Mar 19 14:24:15 2019 clustername-2 [kern_audit:info:14677] 8503e9000000081c :: clustername:ontapi :: 10.170.38.66:34252 :: clustername:unknown :: Error: POST /servlets/netapp.servlets.admin.XMLrequest_filer HTTP/1.1 401 Unauthorized
Tue Mar 19 14:24:15 2019 clustername-2 [kern_audit:info:2152] 8503e9000000081d :: clustername:ontapi :: 10.170.38.66:34254 :: clustername:ansible-user :: <netapp xmlns="http://www.netapp.com/filer/admin" version="1.110" vfiler="clustername"><ems-autosupport-log><computer-name>Ansible</computer-name><event-id>12345</event-id><event-source>na_ontap_gather_facts</event-source><app-version>2.8.0.dev0</app-version><category>Information</category><event-description>setup</event-description><log-level>6</log-level><auto-support>false</auto-support></ems-autosupport-log></netapp> :: Pending
Tue Mar 19 14:24:15 2019 clustername-2 [kern_audit:info:2152] 8503e9000000081d :: clustername:ontapi :: 10.170.38.66:34254 :: clustername:ansible-user :: Insufficient privileges: user 'ansible-user' does not have write access to this resource :: ONTAPI :: Error
I recall having the capability to see privileges denied at a very granular level in 7-mode then being able to correct them as they come up. Where is this functionality in cDOT, or am I just not reading the audit logs the way they're meant to be read?