Tried a half dozen ways to protect service/user creds in scripts, but it seems the working directory is the RO /run/vco-polyglot/function for whatever vra node is running it, and not the powershell host... Hardly optimal. Whats the proper way to do this?
I normally use this approach & it's not terrible
1. Store credentials in a ConfigurationElement - Password can be a SecureString there if you want it to be
2. Use an action such as the below to locate the ConfigurationElement in the presentation action for the form. Once you have the configuration element you can get the value using
In your presentation action you can call any other action using
System.getModule("com.<my>.<package>.<name>").<actionName>(p1, p2, p3.....);
e.g., for my action above its
var credentialsConf = System.getModule("com.triangle.util").getConfigurationElement("Library/StoredCredentials", "SomeRESTAPI", false);
OP stated that he's using a custom form? So, an approach might be to add an input for the credentials and use a JS action like mine to resolve them. At this point then they would be present in the input set to the Powershell action?
Sorry, I don't have a Powershell enabled instance to play with this to confirm but it sounds workable...? The issue might be creds passing OTW in the clear and perhaps in log files so probably not a production/public solution
The only other alternative would be an external system (database, file store, REST API) and write your action to resolve from there (which technically you could do for the vRO ConfigurationElement even but then you're back to where to get credentials from.... unless the workflow context has a pre-authorised token buried in it? @iiliev Is this a possibility?)
There must be a way to do this though - the additional runtimes are just shiny islands with limited use otherwise
I am trying to keep a service account private not just from end users, but also from any accidental exposure through a source code repository, which I am attempting to use to query different services to populate dropdowns for compute resources/services the end-users have rights to.
It seems one of the issues I attributed to the failure of everything I've tried so far, was in fact an issue with vRO and latest PowervRA module. I'll retry some of these ideas today with simpler code and see what happens.