Password management
Last updated
Was this helpful?
Last updated
Was this helpful?
We prefer not using shared accounts where possible. We use shared accounts when the plan we can afford to use of a given service does not allow individual accounts for enough users to be practical for our needs.
You should definitely get a dedicated account for any django/flask app we develop.
We use BitWarden for shared password management.
We try to follow the principle of least privilege, meaning you should only have access to passwords you actually need. To avoid creating multiple shared accounts on the same service, please add any accounts that relate to your unit's work to the table, and please document when it is the preferred tool for the job in the table above it. Before creating a new account, check if there is an existing account you can get access to and reuse. Duplicate accounts can waste money and effort.
We organise shared passwords according to:
unit - for passwords shared with everyone in that unit, e.g. comms, dev, finance
project - for passwords shared with everyone in the project
Bitwarden can "nest" collections using forward-slashes (/) in the name, and creating a collection for each level in the hierarchy.
When adding items, remember to add them to the relevant collection. The collections can be edited later. An item can be in multiple collections, e.g. the project, as well as the finance collection to give the finance team access to invoices.
Invite new users to the organisation. Once they've accepted, they will have an account and can store passwords for themselves, but they aren't part of the organisation yet.
These users will be listed as accepted in the organisation user list. You will need their bitwarden fingerprint.
They can find their fingerprint on their user profile in BitWarden. It is not secret.
Once they are confirmed, add them to any collections they need access to by clicking on their name and checking the relevant collection boxes.
Everyone should have access to
project
unit
and then any specific units and projects they need to access.
Developers will need to deploy credentials via Ansible.
Secure Note type items seem to work best for these kinds of credentials. Use a custom text field for the non-sensitive values, and a hidden field for API keys, passwords and other sensitive values.
We usually organise these credentials in an environment collection under the relevant project collection, and named after the service, e.g. under project/municipal-money we have prod, staging and sandbox matching the environment names used in the ansible inventory. Ansible can then use this name to select the right credential for each environment.
Make sure the item is named consistently across environments so that the same service can be accessed using only an environment name variable in the collection name.
You can accept them into the organisation by confirming their Bitwarden after selecting Confirm in the menu next to their name.
