search

Azure / azure-service-operator

Azure Service Operator allows you to create Azure resources using kubectl
https://azure.github.io/azure-service-operator/
MIT License
707 stars 190 forks source link

Feature: Allow storing secrets in KeyVault #2242

Open matthchr opened 2 years ago

matthchr commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

epierotto commented 1 year ago

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 commented 1 year ago

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 commented 4 months ago

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 commented 1 week ago

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.