Access Cypher Secrets for Form / Input / Option Lists

Secrets Management
,
1

Hello Friends! I’m a new Morpheus user, and am playing with Forms.
I’d like to be able to load a secret from Cypher to use as an option list. My secret value would be a JSON structure that I can loop over to provide the options list as name/value pairs.
Is this possible please? I have tried to access Cypher in the Translation Script of a Manual Type Options List, using the syntax <%=cypher.read(‘secret/hello’)%>, but it errors.
Thanks, Geoff

2

Welcome to the forum @Geoffrey_Baldry!

I don’t believe it possible. There are API endpoints to list Cypher Keys, so you could list the keys in an option list, but you can’t access the content.

Could you not use a manual option list, and provide the JSON object there? On the face of it less secure, but data from a cypher would be inspectable in the browser when presented in the form select control anyway, so not sure there’s much difference as far as I can see.

One thing you could explore is creating an option list via a plugin. These can be used in as a option list source in Morpheus and “may” give you programmatic options to access the Cypher in the plugin code.

3

Thanks for the welcome Ollie!

I was trying to put the secrets in Cypher to be a good citizen, but as you say, if they are visible via browser inspection, then that would not be what I want.

The plugin option is my next stop. I have already created a working option list provider plugin this morning, based on Chris’ great video(s). However, I am stuck at the point of trying to access the Cypher store from within the plugin.

I see that I need to use the MorpheusCypherService to access the store via its read() method, which in turn, needs a CypherAccess object. It’s gettgin the CypherAccess object that I am stuck with. I have trawled the example plugins, but can’t find one that I can copy. Do you happen to have any example code that simply accesses a key from the store that I could steal please?

Thanks again,
Geoff

4

Personally, I don’t, but I’ll look. Others may have an example, and I’m sure they’ll post up.

One thing to note before you go this route. The plugin code may give you access to the secret stored in the Cypher key, but the data will still be inspectable in the browser when presented on the form, which brings me back to the point that a manual option list is pretty much equivalent.

5

The following is an example of accessing cypher using a plugin (morpheus-datadog-instance-tab-plugin/src/main/groovy/com/morpheusdata/tab/DataDogTabProvider.groovy at bea98a62352f1f13721ca30c2432b66adaea57d4 · martezr/morpheus-datadog-instance-tab-plugin · GitHub).

The thing to consider is how will the secret be used, is it being passed to an automation task or something entirely. In theory what might work best is if the value of the selected option being a pointer or reference to the path of the cypher secret. In this case it might be possible to have the automation task perform the cypher lookup using the path provided by the option list value. Another option if you are unable to perform a cypher lookup could be encrypting the value outside of cypher and decrypting it on the destination system. This way cypher is used as an intermediary storage and presenting the ciphertext in the option list doesn’t pose a security issue.

6

Thanks both Ollie and mreed!

Just to explain the intended use fully in case others get benefit from the info.
I’m automating a 3rd party file-storage vendor. We have existing VMWare vRO workflows, which do the actual automation work, that we intend to trigger from Morpheus. So, I’m only needing to automate the front-end form so that it collects enough input to be able to send a call to vRO to execute the workflows there.

I intend to use the secret as a way of storing some static data in JSON format. Some of the data in the JSON structure is secret, but other data is not, like simple names of things, etc.

For example :-
[
{
“name_of_device”: “device1”,
“secret_api_key”: “secret_key”,
“other_info” : { etc, etc },
“etc” : “etc”…
},
etc
]

I will use the data from the secret to populate drop-downs in a form. The drop-downs will only have simple information, like just the device_name (i.e "{“name”:“device1”, “value”:“device1”}) created via a translation script ,so no secret info collected in the plugin will be revealed in the browser’s inspector. That drop-down selection made by the user will then be fed back into the plugin as an argument to help populate the next drop-down by doing more API call work, etc within the plugin. Thusly, the drop-downs cascade. All the secret data will be revealed only within the plugin, and only non-secret information provided back to the browser for drop-down population.

This use of static data held in a secret is party to do with storing secrets properly, but also in order to minimise the number of API calls required to the 3rd party vendor’s cloud-based SaaS API to find out info that rarely changes, but makes the drop-downs go slow because each access takes around 300ms, and we require many calls each time to gather enough info to populate a single drop-down.

Please let me know if you think there is a better way under Morpheus. This is the pattern I found worked best with VMWare/CAS/vRO.

I will see if I can use that Datadog example code to make the above work.

Thanks again to both of you for your input! This is an excellent forum with helpful members,
Geoff

7

I can confirm that the example code from the DataDog plugin, which accesses Cypher secrets works perfectly - thanks for that @mreed.

If you find yourself creating an option-list source plugin, and follow Chris Taylor’s video explanation (it’s excellent), then there is a little gotcha I found to do with cascading the drop-downs. In the plugin, if you want to read input from a certain drop-down to populate another, then those inputs are available as ‘args’ that get supplied into your methods. However, the inputs come in as args.config.<some_arg> when using inputs in a workflow (as Chris’ video shows very well), but seem to come in as args.<some_arg> (without the .config.) when used through a form or embedding a form in a Catalog Item. I found this by just printing the args variable to the log and inspecting it. You might need to look for the inputs in both places depending upon how you intend to use your option list.
Someone at Morpheus can point out my mistake if I’m using the above incorrectly, or have made a mistake.

Thanks again,
Geoff

8

…Just also wanted to link in this post, which I stumbled upon, and that answers the question too, but with some additonal info around how to get the account/user that is running the workflow/form.

1 Like