Switch to RBAC for KeyVault access

[Pauwelz]

We're currently using "Vault access policy" for the internal Invictus Keyvault, when switching to MI (#168) we can also change to using RBAC for this keyvault.

[GoutsmitSam]

@Pauwelz This change has been finished, but @LaurentAerens has a concern that the Invictus KeyVault might be used by other (non-Invictus) applications/integrations as well, meaning that those applications will have to switch to using RBAC as well.

Do you have any knowledge of this being a widespread practice? Should we hold off rolling this out until we get some clarity on this?

[pim-simons]

@Pauwelz This change has been finished, but @LaurentAerens has a concern that the Invictus KeyVault might be used by other (non-Invictus) applications/integrations as well, meaning that those applications will have to switch to using RBAC as well.

Do you have any knowledge of this being a widespread practice? Should we hold off rolling this out until we get some clarity on this?

I have one or two customers where this is done as well.
For my customers this shouldn't be an issue since the functions that access the Invictus KeyVault are already running under a managed identity that has KeyVault access assigned to them on the subscription.

However, even if this was not the case and the customer would be impacted this is something they would immediately see during deployment of the new Invictus version over their DTAP environment and would be able to make the appropriate changes before moving this to production. So from my point of view this changing the Invictus KeyVault to RBAC should not result in production issues at customers.

Just my thoughts, interested in others 👍🏻

[GoutsmitSam]

Update: the general consensus is that this should not be seen as a blocking issue. Any 'outside' connections to the Invictus KeyVault will get detected when installing the version, so can be handled at that point. I'll close this issue, and have asked the team to release this change.