topic Re: capabilities for ONTAP WFA user account? in Active IQ Unified Manager Discussions

capabilities for ONTAP WFA user account?

nscherer — Thu, 05 Jun 2025 06:37:35 GMT

Hi,

does the ONTAP user account that WFA is using to connect to the filers need to be a member of the Administrators group?

Is it possible to use a role with a restricted set of capabilities?

Thanks,

Nico

Re: capabilities for ONTAP WFA user account?

fenton — Thu, 12 Jan 2012 12:41:13 GMT

It will depend on which commands you are executing - you will need access to the underlying api's;

My advice would be to create an account wfaroot and place it either in an admin group or a group with api-* capabilities to be used as a service account and then use the WFA Auditing to audit who is running which workflows.

Re: capabilities for ONTAP WFA user account?

hill — Thu, 12 Jan 2012 12:59:07 GMT

Hi Nico,

Rich is right. The answer is "it depends". It really depends on what you want the WFA workflows to do. You can create an ONTAP user with limited capabilities. However, some customers want to have workflows that perform administration tasks on the controllers like changing settings / options, updating /etc/rc, creation of aggregates and so on. The easiest thing is to have a WFA user account as a member of the Administrator group, but it is not the only answer.

Hope this helps.

Kevin

Re: capabilities for ONTAP WFA user account?

nscherer — Thu, 12 Jan 2012 13:09:51 GMT

if using api-* would work for all kind of workflows it would at least disable logging in to the CLI with that user account

Re: capabilities for ONTAP WFA user account?

fenton — Thu, 12 Jan 2012 13:14:41 GMT

Yes - it would also highlight any work that is being driven from WFA within ONTAP; It would be nice for a workflow to identify which API's it will use so you could advise the minimum level of capabilities required - that would be one for Product Management/Engineering though

Re: capabilities for ONTAP WFA user account?

goodrum — Sat, 14 Jan 2012 15:09:43 GMT

This is an interesting question and I thought about providing some of my own feedback. The question about RBAC to the controller comes up often and here are some of my answers:

Q) Should I use root as my WFA credentials for the Array?

A) It is always a good idea to use a different account for WFA Array Credentials. The reason for this is to allow for controller auditing especially if a Syslog server is used on the Array and the audit logs are archived. Though the Execution status is archived it is helpful to see from the Array audit logs which users are executing commands.

Q) Should the WFA Credentials be restricted and if so what limitations?

A) Kevin gave a very good answer with 'it depends'. Though this sounds very vague, it is true. Limiting WFA Array credential capabilities is possible and as nscherer said using the 'api-*' option can add an extra level of security. However, there are a few things to think about. End users do not have access to the WFA Array Credentials. Only Workflow Architects would be able to add new Storage Arrays and Operators will only be able to execute workflows. This adds a different layer of security to WFA. Because the operators can only do what the designers build, you can have a sense of security knowing that the NOC Team or whoever you have execute workflows (end customers) are restricted to only what you allow them to do. Another important note is that future road map conversations would imply that there will be a new level of security. The plan is to limit access to workflows based on user account and category. This will be a huge benefit when considering role based provisioning.

Q) Determining which credentials are necessary?

A) There is no easy way to do this. WFA Array Credentials are global to WFA not a specific workflow. Limiting scope will be based on api's necessary for the Data ONTAP Powershell Toolkit and more importantly which commands will be leveraged.

Q) How are WFA Array Credentials stored?

A) The password entered in the Credentials section will be stored as an encrypted entry in the WFA Database.

The best option is to limit the users that can create workflows to those that are responsible for product development. Create a new account on the controllers with a strong password scheme. Limit the capabilities to api-* initially though bear in mind that you may find as you develop commands that you build wrappers to perform actual CLI calls.

Just my two bits

-Jeremy