DIY Password Manager using Azure Key Vault because .. why not?
Password managers are great. No doubt. But when it’s not an option for your team (costing, user management, etc.), there may be another option….
The WHY
Recently, I was presented with an interesting challenge. My new team had been using open source KeyPass (MacPass for MacOS) for password management. It of course presents a few issues:
- KeyPass password file needs to be shared amongst users. In the wrong hands, the file can be deadly.
- With the KeyPass files sitting individually with each team member, they can get quickly out-of-sync especially in teams where a lot of systems (and passwords) are at play. Imagine someone updates a password and now s/he would have to update his password, update the password database to a central repository and wait for all other users to ‘pull’ the new file… all in order to be in-sync. This also leads to scenarios where teams are resorting to sending passwords over chat or worse (email?).
Since I was new to the team and the budget was he-who-must-not-be-named, I wondered what we could use to rectify the issue on hand or at least mitigate some of the risks and improve the workflow. And since we were an all Azure shop, I immediately wondered if we could use the Azure Key Vault in some way as a password repository. Unfortunately and surprisingly Google didn’t come to my rescue. So I thought I’d give it a go and blog about it. There are some key benefits to this approach:
- Use your existing AD accounts to maintain access to the passwords/keys. When an employee is terminated, their AD is one of the first things to get disabled. AD management takes care of password management.
- Cheap. Very cheap.
- Developer/Tech team-friendly. If you’re working with technical teams (I’d assume you are), they can access the passwords and keys right from the terminal. Helping their efficiency while maintaining good security hygiene.
- This was a bonus. Once you have credentials stored in Azure Key Vault, now they can be accessed by another application in Azure resource if you’d like and if you’d set up the right access for it (using Service Principal). For example, if you’d need to use a password in one of the scripts, you can create specific access for the script to the specific key/vault. This is also a good practice for scripts as it removes the need for hardcoding credentials.
- The granularity of access. You can configure different levels of access to different AD/groups e.g. Contractors in a company can be set to only have ‘list’ and ‘view’ access to only certain Key Vaults that are required for their specific projects and nothing else. And depending on how you configure the vaults, you can have good control over the scope of any access that way as well.
The HOW
Ingredients:
- Azure Account
- Azure CLI
- Optional: JQ package
(Although you can do without JQ, it will help tremendously cleaning up the otherwise very verbose outputs. Installing it is as easy as sudo apt-get install jq in any terminal including WSL)
…. and that’s it!
Setup steps:
- If you haven’t created an Azure Key/Secret before, have a go at creating a secret (we’ll be using secrets not keys as the keys serve a specific purpose). Follow ‘Create a Secret’ portion here to create a secret (duh!) under a scope.
- Open up a terminal and enter
az login. This will open a browser and let you log into your Azure account which I find freaky cool still… - Once logged in, now you can enter the following command to get a list of all vaults that your Azure account has access to. As you start setting up, you’ll think of the best way to structure the key vaults so it’s easy for you to navigate!
bash-3.2$ az keyvault list | jq ‘.[]| .name’“vault1”
“emails”
“bank-details”
“vendor-xyz”
"all-random-examples
- Next step you can view the secrets in the vault of your choice.
bash-3.2$ az keyvault secret list --vault-name vendorx | jq '.[].name'"vendorx-sftp-password"
"vendorx-username"
- And finally, you can get the secret value using below command. Obviously you can avoid the above two steps if you understand the information heirarchy and the setup.
az keyvault secret show --name vendorx-username --vault-name vendorx | jq '.value'"FHI5wHy---SECRET---VALUE-----w=="
Summary
No doubt that Azure Key Vault commands are verbose and the solution is not for everyone. With the given concept though, the sky is the limit. Imagine a python script to query a password (that securely queries the vault and returns what you need) or some clever bash script! I’ll continue to explore this idea and will endeavor to keep this post updated on my findings/rants/aha-s!