Provide Admin API access to flow credentials

[knolleary]

As a strict rule, the admin API (GET /flow and GET /flows) does not return password credentials included in the flow.
This ensures they cannot be accidentally accessed if the admin api is left unsecured.

However there are cases where it would be useful to export a full flow - including credentials - from the editor. For example, where you want to export your flows, including credentials, to copy them to another instance of NR, but you don't have CLI access to copy the files.

I want to explore how we could expose credentials, securely, via the admin api.

The general idea is:

1. add a flag to the GET /flow and GET /flows endpoints to request credentials are included - the default would remain to not return the credentials.
2. the flag would only be honoured if the user making the request has explicitly been granted the appropriate permission (eg credentials.read). Unlike other permissions, this would be handled as a special case - a user with * permission (currently full read/write access) would not have this new permission by default.
3. A consequence of update API to ES5 style #2 is that adminAuth must be enabled

This would ensure the administrator of the NR instance is in control of who is able to access credentials remotely.

[sammachin]

How would they be exported? as a separte file/object still encrypted or would they be embedded in the flow?

[knolleary]

They would be in the flow JSON returned by the API.

The POST API already supports individual nodes having a credentials property to set the values, so I think this would do the same.

Another consideration is whether the properties could/should be optionally encrypted.

One possible extra consideration is whether the APIs support lllcredentials are encrypted a

[sammachin]

So when you then import that into a new instance are they re-created as shared credentials objects or unique ones?
For example if I had 3 nodes that all used the same creds and then exprted/imported would I then end up with 3 duplicate sets of creds?

[knolleary]

Credentials are just a type of node property - they aren't an object in their own right.

If you have 3 nodes using the same credentials then you either have:

1. 3 nodes where you have typed in the same credentials for each node
2. 3 nodes that use a shared Config Node that contains the credentials

So the question of what you end up with will depend on which of those models you have - and whether the config node is also exported/imported. Remember we now prompt you if you are importing nodes you've already got to ask if you want to import a copy, or use the existing nodes.

[sammachin]

Ah right yes, sorry my mistake I always get config nodes and credentials mixed up (mostly because config nodes usually hold credentials!)
Yes so when you export the config nodes in the flow they would have the credentials in them, that makes sense

[TotallyInformation]

Seems like a sensible approach. Though maybe some warnings in the documentation about not allowing this over a remote connection unless it is encrypted would be useful.

The optional encryption certainly something to think about. Also what about projects? If this feature is on, is there an impact on projects and the use of git? I don't think so but I don't really use projects so I'm not certain.

[knolleary]

Doesn't have any impact on Projects. This is about how the editor may export credentials from the editor - which is distinct from how they are stored by the runtime (in a project or otherwise).

[natcl]

I also feel it would be nice to have the option (and perhaps that should be the default) to have those encrypted, upon export the user can choose a password to encrypt.