Feature: Allow storing secrets in KeyVault

[matthchr]

This was brought up in #1894 and also supported in ASOv1.

This is related to #1415 which was originally for ASOv1 but would apply to ASOv2 as well if it had KV support.

[matthchr]

This is still something that we're tracking. There are various solutions to reading KeyVault secrets into Kubernetes, for example:
https://external-secrets.io/ and https://docs.microsoft.com/en-us/azure/aks/csi-secrets-store-driver, but there aren't any inbuilt solutions for exporting secrets (say, storage account keys) to those stores securely.

[matthchr]

Still something worth doing but hasn't been a lot of clamor for it yet

[epierotto]

I'm also interested on this feature, I wanted to provision an Azure KeyVault along with some secrets.
Initially I thought that I would find an ASO resource similar to "Microsoft.KeyVault/vaults/secrets"

[matthchr]

I'm also interested on this feature, I wanted to provision an Azure KeyVault along with some secrets. Initially I thought that I would find an ASO resource similar to "Microsoft.KeyVault/vaults/secrets"

We purposefully had chosen not to do secret creation via ASO because it felt like these two goals were in conflict:

1. KeyVault wants you to store your secrets only there, so they're the most secure.
2. ASO must store the secret in Kubernetes somehow, in order to know what value to propagate to KeyVault when creating a new secret.

Can you expand more on why you want your secrets in KeyVault and Kubernetes? Can you give some (high level) examples of the scenarios you're looking to solve? Understanding those might help us to revisit the decision mentioned above and consider supporting KV key management through ASO.

[matthchr]

At this point this feels more like a documentation thing as I believe there are projects that achieve this without needing to be as explicit about it as ASOv1 was. We need to close at least the doc gap though if not the actual feature gap.

[cvs79]

This would still benefit customers.

for example, for a current customer we do not expose kubernetes and Azure directly to end users. This could be employees or third-party users. We do expose selfservice repos which they have access to. Contents from this are synced to the cluster using ArgoCD. This can include APIM resources (ex. products) but also secrets (encrypted using sops decrypted by ArgoCD).

But sometimes other azure resources would need a secret from KV. Creating this from ASOv2 would greatly simplify that without installing another operator.