Arch Forum 2024-08-29¶

Participants: Backend devs, Victor, ??

Agenda¶

KeyVault Guidelines:
General guidelines are listed in wiki, here: https://dev.azure.com/MAJORITY/Documentation/_wiki/wikis/Main/446/Secretes-and-KeyVault

Given these, we should do these things:

Remove global service keyvault, move keys to global key vault
Clean up dev/stage/prod to all match keys in prod keyvaults
Move global cryptography secrets to user keyvault
The end result is that global keyvault contains:
- Elastic logging credentials
- Servicebus credentials
- RabbitMQ credentials
- Minority auth keys
- Firebase credentials
- Risk credentials
Do not use two ConfigurationSourceAttributes for secrets, this should not be needed anymore. Existing double entries should be cleaned up.

Restructure how logging is done, to not call elastic directly (and therefor not need any keys in keyvault)
Deprecate servicebus (and therefor not need any keys in keyvault)
Use per area unique firebase credentials, and move these to each area's keyvault
Investigate if its possible to use managed identity or similar to connect to RabbitMQ
Think about risk authentication, does it really need to go authenticated?
Ideally, global KeyVault only contains the Minority auth keys

How to handle provider credentials that are needed for debugging? For example, sometimes a developer need to call (prod) remittance providers API directly to debug some issue. But if developers shouldn't access the KeyVault, then how to handle this situation?
The servicebus secret is duplicated in Regresssion test KeyVault and normal KeyVault. Is this really needed. It caused issues when not both were updated during a secret rotation.
(Also some additional points were raised, that are already merged into the general guidelines and not listed here)