Replies: 1 comment 3 replies
-
Sounds like a plan 👍 Kubernetes uses mostly environment variables to pass along information? We could mark secrets with something like But yes, I like the idea of also abstracting this Dapr secret management as there is no need for the application code to know where the secret value is coming from (and we can provide our other secret store functionality like caching on it). I'm wondering how we can test this? We have for example a HashiCorp Vault secret provider in our repo and it is tested by running locally an instance of the Vault. Maybe we can do something like that for Dapr, too? |
Beta Was this translation helpful? Give feedback.
-
Arcus.Security has a great support for Azure KeyVault and some other secret providers
However, afaik, we do not currently support Kubernetes secrets. Actually, a Kubernetes secret can be just retrieved from the configuration, and that is also how I'm doing it right now. (I am adding the configuration as a secret provider). Maybe be can improve this ? Making it a bit more explicit ?
Next to that, when creating services that run in Kubernetes, people are also making use of Dapr. One of the Dapr components is for secret management.
It allows you to abstract access to your secret store: you configure the dapr secret component to connect to KeyVault for instance , and from your application code you use the dapr api to retrieve the secret. More info can be found here.
I think we should consider creating an Arcus secretprovider so that you're able to interact with your Dapr secret component. This allows developers to abstract away the communication with the Dapr API to get their secrets.
Beta Was this translation helpful? Give feedback.
All reactions