Start a new topic

Custom Property override on Dynamic Folders

We use dynamic folders in a shared document. I'd like each user to be able to pass a unique parameter to the dynamic folder script. Currently this param is recorded in the Custom Properties. Is there any way to override a Custom Property on a folder? Or any other means of feeding a per-user token value to a Dynamic Folder script?


Thanks


Hi Matt,


in this case, we would recommend using config files, by defining a path to the config file (e.g. ~/.config/MyDynFolderConfig.json) within your Dynamic Folder script.

This config file can then be adjusted by each user to hold their personal configuration, since currently there is no option within the application to define user specific overrides, apart from credentials.

Alternatively, you can assign credentials via name to the Dynamic Folder (https://www.royalapps.com/go/kb-all-teamsharing), and select these via $EffectiveUsername/Password$.

Theoretically, this gives you the possibility to use these two fields for different purposes, but we recommend using the config variant, as described earlier.


I also attached sample Dynamic Folder scripts created by our lead dev, to give you a better idea of this.


I hope this helps!


best regards,

Christoph

rdfe
rdfe

We are using the Dynamic Folder's credential setting already to provide inheritance of a named credential to all the hosts produced by the script. This might be a tangent to the original question... We don't use the Dynamic Credentials function at all, possibly due to mis-understanding it. Is the intent to produce a credential spec (un/pw,named, etc) for the inventory build process? Or is it a dynamic means of producing/selecting a credential at connection time for each of the hosts in the generated list? 


I currently use the DynFolder's credential setting to default to a named "user.key". With the DynFolder script, if the host is a Windows host (in AWS inventory), it will build an RDP conn and set the credentials to a named "user.domain".


The core problem I'm trying to address here is that the AWS API creds that the DynFolder script is using are assumed to be in the user's OS config. They are typically poorly managed. I wanted to have a way to store API creds encrypted in Royal and pass them to the DynFolder script, but understood this was not a feature.


I'm trying to implement aws-vault and set a flag to the DynFolder script so that it adds the prepended aws-vault command to the fetch of AWS inventory. The flag is needed as not all users using this shared document have configured aws-vault yet. 


If DynCreds script is about delivering creds to the DynFolder process, that would mean AWS API creds could be stored and used within Royal. If DynCreds are building connect-time creds for each host, it might just be a smarter way to handle my SSH/Windows if-then.

Hi Matt,


please have a look at the following documentation, which should give you a better idea regarding Dynamic Credentials:

https://docs.royalapps.com/r2021/scripting/rjson/dynamic-credentials.html


Regarding the original problem:


May I ask if each user of the Dynamic Folder script is using the same login data for AWS, or if they are using different ones?

If the credentials used are always the same, you could add an encrypted custom property and reference to this field via a token within the script. (https://docs.royalapps.com/r2021/royalts/advanced/tokens.html)


If each user has their own credentials, you could have them add a credential with the same name (but different user/passwords pairs) to Royal TSX and assign the credential to the Dynamic Folder, using the 'Specify a credential name' option (https://www.royalapps.com/go/kb-all-teamsharing). 


This would however lead to the problem, that your current method, which assigns credentials to the connections within the Dynamic Folder, would not work anymore, since the credentials which are assigned to the Dynamic Folder are not used for the target connections but for the AWS login.


You can bypass this issue, by not using inheritance but instead assigning each connection the correct credential via CredentialName:

https://docs.royalapps.com/r2021/scripting/rjson/available-properties/royaljsonobject.html#credentialname


Please let me know if this helped!


br,

Christoph

@Christoph,


Thanks for the ideas and links. It spurred me to look at the problem a different way and I found that I completely missed a solution that solves all my problems.


The AWS CLI has the `credential_process` setting in profiles. I can point that at the aws-vault command, which then requires only a profile be passed. Which we can arrange to be the same name pattern across all users and pass as a CustomParameter for the various top-level nodes in Royal.


That way I achieve more secure storage of AWS API creds in a native way that Royal doesn't need to know about.


That all said, feature ideas that I think are worth considering; CustomProperty overrides, and/or a Token to reference a different Named Credential. 


Your example of the Named Credential to then use the Username and Password tokens for the AWS API creds is helpful. One could easily build the credential references in the Dynamic Folder script.


One possible bug I saw, though I didn't get to chase it down. The Preference setting for Dynamic Folders has a setting for Evaluate Shell Profile. It was unclear if this is only for shell-based scripts or also for interpreters. I have a ~/.zshrc env var that did not seem to be available to a cmd executed by a python script. The help text mentions various bash profile locations but not ~/.zshrc, I assumed that is just old or incomplete text. Or do I have it wrong and shell profiles are not for python? Either a bug, or maybe more specific explanation in the text. (or my misunderstand of something else!).


Best,

Matt


Hi Matt,


you are welcome, glad you found a solution.


Regarding the 'Evaluate Shell Profile' setting:

This setting affects all script interpreters and controls whether the script is executed within a login session or not.

The bash profile is only listed as an example, since not all shells with their locations can be listed.  Therefore, the tab name of the setting is also named 'Common', instead of a specific interpreter (e.g. Bash).


I hope this helps!


best regards,

Christoph

Login or Signup to post a comment