search

dapr / proposals

Proposals for new features in Dapr
Apache License 2.0
15 stars 33 forks source link

Create PR 0011-R-secret-auto-injection.md #15

Closed ezYakaEagle442 closed 1 year ago

ezYakaEagle442 commented 1 year ago

Signed-off-by: Steve aka ezYakaEagle442 43554247+ezYakaEagle442@users.noreply.github.com

ItalyPaleAle commented 1 year ago

Thanks for this proposal and for taking the time to write it out!

I am not sure I support this proposal however. The main issue I have is that for this to work, we'd need the Dapr Sidecar Injector to communicate with secret stores, which is currently something we do not do and we'd have a hard time supporting: issues include authorization, scoping, and performance. I also think that there will be some UX issues, for example with the fact that secrets that are injected by the injector are not updated during the app's lifecycle, and the next natural question we'd get is how to allow hot-reload.

yaron2 commented 1 year ago

-1 binding.

This proposal introduces both security unwarranted security implications (sidecar reading application, non-Dapr secrets), broadening the scope of the injector to handle non-Dapr issues and requiring the injector to know intimate details regarding the application architecture.

artursouza commented 1 year ago

-1 binding

Language specific details should fall into the SDKs. Although it is nice to have an user experience where Dapr can be used without requiring any code changes, I don't think it is possible in this case (see Yaron's comments). The next best thing is for the app to bring in a Dapr SDK dependency that works really well with their framework of choice and require zero or a few code/config changes.