Arch Forum 2024-08-01¶
Participants: Backend developers, JD (only Servicebus/rabbit), Andy and Victor
Agenda¶
Notes¶
Servicebus SAS tokens: Currently there's a single SAS token used to auth against prod servicebus, both code and developers use this. This is a quite big security issue!
Short term fix:
- Rotate the SAS token to at least minimize the spread of the token to current employees.
- Add VPN requirement for prod Servicebus
A short discussion on other improvements:
- It should be possible to update platform code to use workload identity for auth. Maybe a day of work to fix. We think we will continue with Servicebus for quite a long time, maybe even a year. Therefor, it's worth to implement this even though we plan to discontinue Servicebus.
- Servicebus explorer only works with SAS tokens.
- Can we just use the portal instead? Some features are not available there (but we could not remember exactly which)
- Given we need a SAS token, we can make it short-lived and unique by developer:
- A cli or pipeline that creates a token with a 1-day lifetime that developers can use when they need it. On a high level, something similar to the elevated database permissions pipeline.
- We also need a solution for local tools that publish to production Servicebus. Either these can use the same short-lived SAS token as discussed above, or they could use the user's permission in portal somehow. Needs investigation.
Finally, a big thank you to Alex, who brought up the SAS token security issue first! Everyone should be encouraged to bring up security issues / possible improvements whenever we see them!
RabbitMQ Update (MIB-9046): A short updated on the RabbitMQ project. Shakib made a review of the full implementation and raised some concerns. But once those are resolved, we should be good to go. As before, we plan to first switch some less important area over first.
Shakib also brought up the good suggestion to switch over integration tests to use RabbitMQ instead of Servicebus everywhere. Given that this will make our RabbitMQ implementation get some load, and at the same time we get rid of (or make more visible) any testing concurrency issues, we will do this.
Some notes:
- This means all developers should have a local instance of RabbitMQ running, just like they have today.
- Pipelines are already prepared to run tests with local RabbitMQ
- We should investigate how it works when we run regression tests locally.
Mapperly Migration Update (MIB-10403):
- Mapperly migration is now nearing completion. Great progress during summer.
- Some bugs have happened, we should be careful when migrating the remaining areas.
- .NET8 upgrade is not as far, but should be easy to do. Only minor adjustments have been needed.