A few years back I added encryption of our SUT passwords to a few scripts as a proof of concept exercise via Text Encryption. It worked well but the average execution time for the scripts did increase a tick. Ultimately we determined our test environment had enough inherent security (and the SUT passwords weren’t overly important to protect) and I removed the code.
I am curious, though, if anyone has been using this with recent Eggplant Functional releases and whether any significant hit to the execution time has been measured. I still have this nagging need to put the code back in but haven’t tried it with the last few EF releases. For scripts being executed in Eggplant Manager, I suspect a small increase in execution time is irrelevant as long as the scripts do their job, and they aren’t impacted in any significant way.
I haven’t looked at how system performance is affected by scripts using these functions. If anyone has data on whether the system takes a hit in performance of any significance that would also be good to know
Hi @chrisbryant, we do use encode and decode, and primarily because the initial hop in a test suite via RDP is onto a management server that acts as a “bastion” for connecting to the SUT, and that the second connection needs credentials. We haven’t noticed any increase in execution time, most of the delays are caused by waitfor statements that we use frequently. So to answer your question, we do use these functions frequently and they don’t cause a performance problem, but you should know that we run the scripts on virtual machines with 32 virtual processors running at 2.5 GHz and a large amount of memory (128Gb). There are usually three or four developers of Eggplant scripts coding and testing scripts concurrently.
Did you check the setvaultvalue and getvaultvalue in combination with typehiddentext.
Typehiddentext will only be shown as **** in the logs
Set/Getvaultvalue are utilising the operating systems credentials managers
The passwords need to be set once on the EPF machines and can be retrieved via the get.
combine type and get to this. Do not store it in a variable
I’ll be honest, I’m a huge fan of encryption and I think in the beginning I was just happy to see the option available and wanted to try it out Your example here may actually be a better fit for our environment! I’ll give this a go shortly. Appreciate it!
Here is a better test case in BDD format explaining the requirement for using Vault and asking for people’s experiences with similar CI/CD deployments:
AS A Jenkins Pipeline task
GIVEN THAT I run as a process owned by a Service Account AND
GIVEN THAT I have access to the Windows Credential Manager with a valid security context as a Principal
WHEN I execute a “Runscript” batch job remotely on the Eggplant server using Windows Remoting
THEN the test-specific key(s) that I pass as a command line argument to the batch job using one or more -param arguments can be used by the Eggplant script’s getVaultValue function to query Windows Credentials Manager and return a password; and I can use the keys(s) and the username(s) passed as separate command-line parameters to provide the credentials needed in the script to open an RDP connection (or do anything requiring a login), without my having to call the Runscript batch job with passwords in plaintext. AND
The Windows Credentials Manager can use the Active Directory LDAP database to store the encrypted password associated with the key OR
The Windows Credentials Manager can use the Azure KeyVault database to store the encrypted password password associated with the key.
@Karsten and @chrisbryant is this a viable approach to avoid using plaintext passwords in batch files/command lines/Jenkins jobs, and have you got the scars to prove it?
