Passing key storage path to secure text job option

[ross.a...@capita.com]

Hi all,

I've tried to pass a key storage path as an argument in a reference job step but it simply exposes the path itself within the referenced job, not the password.  Is this possible?

I'm building an automation framework of sorts that'll allow easy duplication of jobs between Rundeck instances in isolated networks.  Imagine a job that simply sends emails through a relay that requires authentication.  The SMTP relay server is different for each network, each requiring unique credentials.

In each Rundeck instance I've set global framework variables for things like relay IP address and username and refered to these in the job which of course works as expected.  I'd also like the password to use to be defined in a similar way.  I've created another global variable that holds the key storage path but when I refer to that in the argument for a reference job step it simply exposes the path, not the password value.

I know I could just make sure that the password key name and it's path is identical (like "smtprelayuser") but we may already have the required creds stored under another name.

I hope I'm being stupid as seems a miss for Rundeck to not support this workflow.  Even if it worked, passing the key path as an argument would feel like a bit a kludge too.

TIA

[rac...@rundeck.com]

Hi Ross,

Let me share with you a job definition to test.

This example (JobA) gets a password from the key storage (at keys/mypassword path) and passes it to another job (JobB) as an argument using the job reference step. The key here is to add an option on the JobB to "receive" the secure option from the JobA.

Similarly to this.

Greetings!

[Ross Aveling]

Thanks, appreciate it but I've still got my problem. How do I dynamically populate the password option in JobA using a global variable at the framework level?  Only JobB needs to "know" the password key in the end, JobA shouldn't need to know it, I only tried passing it as a job step argument from JobA because that seemed like the only way it might work (the kludge I mention).

Appears that Rundeck only supports changing the default key password option in a job if it's imported from another job's key password option.

[Ross Aveling]

Perhaps not clear but I'd like to specifically make use of the password masking goodness of Rundeck.  The only option I've got is to store the password as clear text in the global variable and simply refer to that in the script step in the job, obviously exposing it in the logs - not an option really.  I'd take the JobA > JobB kludge though if it worked using a global variable as the source key path.

[rac...@rundeck.com]

Hi Ross,

Now I understand your point. The only way to use Key Storage passwords is to use secure options like my first post in this thread (not possible to call them from framework globals directly).

Now, considering this:

Imagine a job that simply sends emails through a relay that requires authentication.  The SMTP relay server is different for each network, each requiring unique credentials.

In each Rundeck instance I've set global framework variables for things like relay IP address and username and refered to these in the job which of course works as expected.

I suppose that you're using multiple Rundeck instances, so, a good approach could be to "centralize" the Key Storage and use the secure option as I suggested (in this way, your Rundeck instances can use the same Keys Storage). You can do this using Vault. Please take a look at this.

Hope it helps!

[Ross Aveling]

Cheers for that, I didn't consider a central vault and that'll be a viable solution for most of our instances but we still will have some that are completely air-gapped.

Interstingly, have noticed the text "Password values are obscured. You can enter a new value or you can leave the entire line with key=***** to preserve the original value when saving. Note: If you modify the key name of an obscured property, the value will not be preserved, and you must enter a new value." at the top of the project configuration file UI.  I wonder how one obscures a global variable value (if that's even possible) in the project config and whether that can be done at the framework level too?  Scouring the documentation but found nothing so far, doubt it'd tie into the password masking anyway.

Anyhoo, thanks again for your help

[rac...@rundeck.com]

Hi Ross,

That is for plugins with password fields defined at project level (e.g: a node executor plugin that defines a password). If you change any node executor parameter, you will see that config defined at project configuration (if your plugin uses a password field, you will se that "obscured"). So, it seems another approach :-)

Regards!