Secrets manager¶
Secrets is used to either provision infrastructure, setup software or run services in production.
Everything is managed within Bitwarden in order to reduce the only needed secret to a single token that grants access to the manager.
The secrets are organized in projects (can be thought of as folders)
| Project | Description |
|---|---|
| App Backend | Runtime secrets that are used by our CustomOffice backends e.g: - api-server - dotnet-server - task-runner - nest-api-server They all share a projects due to the fact that they share some secrets, and we cannot assign multiple projects to the same secret. So if we were to have a project per backend application, then we would be forced to keep copies of the exact same secret. |
| App Fields | Runtime secrets used by our fields-server. |
| App Frontend | Runtime secrets used by the frontend. |
| CD Build Servers | Secrets used to setup self hosted build servers. |
| CD CustomOffice | Continuous Delivery of CustomOffice, e.g. access upload new images to Docker Hub for example. |
| CD Developer Tools | Secrets used to setup internal developer tools on developer.co.customoffice.dk, currently hosting SonarQube and this documentation. |
| CD Docs | Continous Delivery secrets for our documentation page. |
| CI CustomOffice | Continuous Integration pipeline. |
| Customer GPG keys | GPG keys used to encrypt database backups. |
| Customer Secrets | Customer specific secrets, e.g. access to AWS file and backup buckets. |
| Provision Server | Secrets that allows creating a new server. |
| Slack | Webhooks to send notifications in Slack, used by our GitHub workflows |
| SonarQube | Send scans to our SonarQube instance. |
Machine Accounts¶
Access to secrets is granted via machine accounts
Local Development¶
Has limited readonly access to our secrets. Only selected secrets can be read by this machine account.
GitHub Actions¶
Full access and can write new customer secrets.
Working with secrets¶
Local development¶
For local development, relevant secrets are written to .env files as a postinstall script.
More specifically npm run fetch-secrets is executed after installing NPM packages. This will populate .env files for the following apps.
| App | Secrets |
|---|---|
| api-server | App Backend |
| dotnet-server | App Backend |
| fields-server | App Fields |
| frontend | App Frontend |
| nest-api-server | App Backend |
| task-runner | App Backend |
Only requirement is that BWS_ACCESS_TOKEN is available, usually done in an .env file in repository root.
Note that only secrets available for the Local development machine account are written to the .env files.
GitHub actions¶
In GitHub our workflows have a BWS_ACCESS_TOKEN available globally via the organization secrets.
Example obtaining two secrets in a workflow.
- name: Get secrets
uses: bitwarden/sm-action@v2
with:
access_token: ${{ secrets.BWS_ACCESS_TOKEN }}
secrets: |
1724d98c-835c-4fbf-9ecc-b491005b9511 > MY_SECRET_ONE
d2c1b929-c4bb-42b7-b70b-b475008a1161 > MY_SECRET_TWO
When this step has successfully executed, then MY_SECRET_ONE and MY_SECRET_TWO are available as environment variables in the following steps.
Ansible¶
In Ansible we can look up any secret like this:
{{ lookup('bitwarden.secrets.lookup', '7d8081b6-9aac-4cee-b2f0-b2880145f44a') }}
Executing playbooks via GitHub actions, any secret can be read as the BWS_ACCESS_TOKEN used is created from the GitHub Actions machine account.
Locally, it depends on the BWS_ACCESS_TOKEN written to ansible/.env. If it is a Local development machine account, the playbook will fail to execute if it attempts to access secrets that are outside the scope of normal local development.