Open acn-sbuad opened 2 years ago
Another consideration for this issue is to not depend on the KeyVault as such, but rather have one or more interfaces providing secrets and certificates eg. ISecretProvidcer, ICertificateProvider. This would give us one less dependency on Microsoft Azure as such and make running locally and on-prem easier.
@RonnyB71 I agree fully. We discussed this a month or two back while you were trying to use the MaskinportenClient package in an app. We ended up with having key vault secrets automatically being read into Configuration because that was where the MakinsportenClient expected to find it. Doing this through interfaces would require changes in many packages, but it might be worth it.
"Secrets aren't settings."
@RonnyB71 transferring this issue to app-lib repo, close it if it's no longer relevant 😊
Description
Microsoft has released a completely new set of NuGet packages with client implementation for Azure KeyVault. Altinn 3 is currently using latest version of the original client library and should consider switching to the new client libraries.
Several of our projects reference Microsoft.Azure.KeyVault which is now deprecated. Package should be replaced by alternate package Azure.Security.KeyVault.Secrets.
More information: https://www.nuget.org/packages/Microsoft.Azure.KeyVault/
Considerations
Altinn 3 currently has multiple implementations using the client library. We should look into creating a common implementation. Storage might be the only component that access a Key Vault to find a secret outside of the Program class. The question will be if we can register a
KeyVaultClientWrapper
as a service and then use that in the Program class during "startup" to obtain the Instrumentation Key.Update Microsoft.Extensions.Configuration.AzureKeyVault at the same time.
Acceptance criteria
Tasks