This feature request is not limited to RDM but this seemed like the right place to post this.
There are currently 32 different types of `credential` entries.
For example; Dashlane, Keepass, Keeper, Lastpass et cetera
Some make a lot of sense to have special integration for. It helps people getting started without having to write their own implementation.
What seems to be lacking is a basic "Custom credential" entry.
On Windows, RDM does offer a credential type called "Custom". However, this forces the use of Powershell.
In the Linux client this type of credential entry is not offered, despite Powershell being available for Linux.
While enabling this type of entry on Linux (requiring pwsh) technically would make anything possible (you could spawn any other process from pwsh) it would still not be ideal.
Powershell is incredibly slow to start, even without any profile.
In the time it takes pwsh to just start and exit, without any profile, I can launch bash , which additionally calls my password manager to list all available passwords 100 times. It would be hugely annoying to have to constantly wait for a pwsh process to start. And I don't even have to launch bash in order to start my "pass" command.
$ time pwsh -NoProfile -Command "exit"
real 0m0.738s
user 0m1.222s
sys 0m0.156s
$ time bash -c exit
real 0m0.003s
user 0m0.002s
sys 0m0.001s
$ time bash -c "pass ls >/dev/null"
real 0m0.019s
user 0m0.009s
sys 0m0.014s
$ time pwsh -NoProfile -Command "pass ls >/dev/null"
real 0m0.672s
user 0m1.081s
sys 0m0.171s
In DVLS this feature is missing entirely which would make it impossible to retrieve (add or update) credentials when just using DVLS.
I propose to have a "Custom" credential entry which would launch any arbitrary process, with variable substitution and capture STDOUT.
Use-case in general would be to allow anything to be run, to return credentials, without having to provide specific integration.
For example: If using Linux Pass ( https://www.passwordstore.org/ ):
CREDENTIAL_NAME="websites/devolutions/forum"
pass show $CREDENTIAL_NAME | head -n1
pass show $CREDENTIAL_NAME 2>/dev/null | grep -e "^Username:" | cut -d' ' -f2
pass otp $CREDENTIAL_NAME
Anything could be used to get credentials, secrets, otp et cetera.
As long as you can write something for it, like a bash or powershell script, python code, or just a binary, you would be able to launch a process which returns anything.
This custom credential entry would (should) have the following fields:
Command to run, examples:
/usr/bin/myvaultprogram get password $SESSION_ID$
c:\Users\Timmy\Myapps\myvaultprogram.exe get username MyUsernameForDevolutions
Returns: (define what does the command returns)
One of: Username, Password, OTP, Secret, URL, Domain, Email, UPN, Mnemonic
Maybe even arbitrary, any other info field that may be useful (see below)
Platform:
Linux, Windows, DVLS
RDM would pick the Linux or Windows command depending on platform
This allows us to store two different commands, useful in Teams with mixed usage
DVLS option would mean to run it on the DVLS server (see below)
A "Custom credential" entry could have 3 tabs; Windows, Linux and DVLS
Each tab would have one or more rows, with each row representing the command to run and the thing it returns
Instead of a command, you would also be able to select "use command for <OtherPlatform> so someone could write Windows scripts to run and DVLS scripts to run, but for Linux choose the option "Run the DVLS command on Linux systems"
Selecting "DVLS" as the platform on which to run the command, would mean the DVLS is instructed to run the command. If someone wants to use this, they could either change the base image if using a container, to include their code (or use a bind mount) or if running DVLS on a Windows Server they could make sure their code is available there.
The option to run a command in the DVLS environment would be a fantastic addition because then clients do not have to have any local code at all. Which means if credentials are located somewhere else, clients would not require network access to that other location.
A broader use would be to make RDM/DVLS run a command to get any type of info, for example a hostname
Say the network team uses their own device and IPAM tool (could Netbox, phpipam, could be anything else) and we want to give more (support) people read-only access to switches. Having the ability to call an arbitrary command with variables, which could also return IP, Hostname, Documentation URL, whatever, from any external tool, would mean this networking team would not have to touch or use RDM/DVLS in any way. This would be good for adoption as it will not require everyone to completely switch their toolset. I am aware of the "Netbox synchroniser", but that is specific to Netbox, is only available on Windows clients and is limited in its scope. What I am proposing is much more middleware which would not be application-specific and means: "To get the IP for this device call: programX --get_ip --device_id=$SOME_UUID$" , where "$SOME_UUID$" could be a custom variable RDM session interface.
Such a "Custom credential" entry would technically only have to exist once per repository and everything in that repository could link to it. Whatever program or script someone chooses to put in there could potentially make use of $SESSION_ID$ or any other available Variable.
In case there are any concerns about adding programs to the DVLS server, instead of running a local binary you could also include the option to send an HTTP request which would return credential information. This should be kept simple and general. So just send GET to a provided URL, with basic token, custom request with variable substitution and potentially a template for the response, or option to specify json keys. It would be up to the customer to write their own simple webserver to act as proxy between DVLS and their own system.
I understand that some of what I propose may invoke the question: "Why not use RDM for that, instead of external tools?"
And the answer to that is that it would help transition, it would make more people open to the idea of using RDM in their team and allow them to make use of existing (credential) infrastructure and keep using their own tools.
Also, think about what this could mean for the existing integrations and that it would open up the possibility for others to contribute code in a pluggable manner. You could write a small spec, and let people add a github url to extend the available (credential) integrations.
This feature would be for "advanced" users, meaning you won't have to provide much in term of support, documentation or maintenance. Just run whichever process the user provided, the rest is up to the end-user.