Ability to store credentials/secrets

[mannharleen]

Summary

Ability to store credentials/secrets, and use them in plugins. This is a feature request, unless it already exists and I am not aware of.

An example

Take urlplug for example. I want users to be able to use basic auth without having the knowledge of the credentials. If there were a "secrets manager", I could create the credential set in it and have a custom-urlplug to have a new parameter of type = "secret" that is a dropdown to select the secret - lets call it secret-param-1. My users can then select the secret by selecting the dropdown secret-param-1 and refer to it in the Authorization header like follows:

Authorization: Bearer [/params/secret-param-1]

We can go more complex by allowing JSON structures as part of the secret itself. in which case, [/params/secret-param-1/bearerToken] would work.

This is probably a separate request: but having a parameter type of JSON would help in some circumstances as well

PS. Another example would be if we were to develop a plugin to invoke AWS Lambda, and would need a central 'secrets manager' to store the AWS secrets

[mikeTWC1984]

If you add hidden parameter to that HTTP plugin, it would work exactly as you mention Say add parameter with id "token1", type hidden, value 123456 Then user can specify it (in header or body section) as [/params/token1] I think this way you can access any value sent by cronicle to that plugin's stdin.

As a general purpose secret management I think things like dotenv work just fine if you are using shell plugin (you can run anything from it), although it implies that you trust to people you are giving access to run jobs.

[mikeTWC1984]

you can also pass custom json to HTTP plugin from other job via chaining. Say create shell plugin job that outputs object like

{ "chain_data": { "token1":123456 } }

it should be single line json

Make sure you checked "interpret json" box

Then chain http plugin job to it. Then use [/chain_data/token1] to refer to it

[mannharleen]

If you add hidden parameter to that HTTP plugin, it would work exactly as you mention Say add parameter with id "token1", type hidden, value 123456 Then user can specify it (in header or body section) as [/params/token1] I think this way you can access any value sent by cronicle to that plugin's stdin.

As a general purpose secret management I think things like dotenv work just fine if you are using shell plugin (you can run anything from it), although it implies that you trust to people you are giving access to run jobs.

"Hidden" seems to be one way sure. However, I just realized that the problem with using /params/xxx is that the secrets will end up in all kinds of logs. Unless the logger has some logic to identify and hide the secret before logging output

[mannharleen]

you can also pass custom json to HTTP plugin from other job via chaining. Say create shell plugin job that outputs object like

{ "chain_data": { "token1":123456 } }

it should be single line json

Make sure you checked "interpret json" box

Then chain http plugin job to it. Then use [/chain_data/token1] to refer to it

Its a valid workaround, however, seems like we an overkill to spawn a process just for this purpose.

[mikeTWC1984]

Yeah, it's more like obscuring. User can explore all these parameters in browser dev tools (even if it's not displayed in logs or UI). User also can modify url to the server he owns and read all the headers from there. To my mind cronicle is just nice a way to ssh/set cron jobs, and not meant to be exposed to general public. If security is important you probably need some gateway or custom plugin (baking in secret management). It's actually very easy to create a plugin, in any language (check the docs), just make sure user won't be able to read content of it via shell plugin :)

[mannharleen]

@mikeTWC1984 there are two issues at hand:

issue # 1 The first issue is users having access to the secret. I agree with you that here users = admins that is managing the cron/schedules that may already know the secret. This may seem like its not an issue, however, I've seen this in practice in most Enterprise tools where the secrets can be edited by anyone who has access to edit it, but once saved cannot be viewed via the UI. Moreover, having a shared secrets manager reduces duplicity.

issue # 2 The second issue is how the logger logs all args passed onto the child process. It is not ideal to have secrets floating around in logs that would generally be persisted, achieved, mined etc.

[mannharleen]

@mikeTWC1984 My knowledge is still limited here so I may wrong: The plugins are really powerful way for extension, I agree. While they can possible solve issue#1, issue#2 would exist.

[spali]

I think the simplest way for issue#2 would be to have a checkbox on argument or job parameter level to mark it as hidden. This way no unreliable logic is needed to identify passwords or tokens. But let the user specifically set what should be hidden in logs. But it would maybe require to allow parameters to be reused as args or args have to be somehow presented not just as a list but as individual configurable.