I’m interested to hear how other people manage test credentials (i.e. usernames or emails, and passwords), to get a balance of the following:
credentials can be made available to scripts/builds that automate tests
credentials can be accessed reasonably easily by humans who want to use them to conduct one-off tests
passwords are stored in a sufficiently secure way
when multiple/many credentials need to be stored, managing them all is still feasible
In practice, I’ve made better progress on some of these than others. Generally I’ve prioritised security and making the credentials accessible for test automation, but the downside is that, as a human, managing and using the credentials is quite fiddly and error-prone. Maybe there’s a better way?
Basically what we do is pretty similar from what you described, we have manual test logins and automated test logins. Manual test logins can be shared with someone outside of QA team, even though I have asked to avoid sharing them, but automation logins are not even shared among QA team, only automation team has access to those logins, those logins cannot keep on having password changes or any type of configuration change that can affect automation, therefore not shared with anyone.
We can use AWS Security key provider[AWS Secrets-manager] or if you want to use Azure[AZURE Key Valut] we can have that for the secure storage for the key Managment
@fabio The idea of maintaining separate logins for automation and human usage is interesting, I’ll definitely give that some more thought.
@pavan_n I’ve been using the Azure key vault, to it’s good to confirm that it’s a decent option. One downside to it is that the secrets are stored in a big ol’ list. The lack of folders/structure means that storing lots of information in it can get a bit unmanageable, and using systematic naming only helps so much. This was something I was hoping to improve, but I don’t know if there are many options.
Thank you both for your replies, I’ll share them with my team
We just started using Roboform, so far it has saved a ton of time managing all the various log ins for different vendors and emails and places we log into on a regular basis, if you have multiple log ins for the same site you can record each one with a different name. It will also save bookmarks along with log ins and the plug in shows it right in your browser for quick access.
I am not sure about how it can be incorporated for automated tests, but the human access and managing is great- our version allows creating folder to access to some logins, so you can have just yours, a folder for your direct team and a folder for extended groups that can have access to those log ins.
Hopefully that is more along what you were mostly interested in.
I got some more input from other teams in my company, and have concluded that, in our context, using secrets in Azure’s key vault or secret variables in its variable groups is most appropriate for the automation side of things, although it’s not perfect.
@banna88t We’ve been using a password manager recently for the manual side of things - it’s definitely got potential too. Thanks for sharing your experience
@alila bit late to this but I’ve used a self hosted app like Vault before for this. The advantage is that you can store a hierarchy of secrets and access it via the command line. This makes it easy for users to get data out when needed but also to integrate it in to CI. A lot of CI tools like CircleCI and Concourse natively integrate with it but even if not it’s command line so easy to integrate with a few scripts.
