dapr init should initialize a local secret store

[AaronCrawfis]

Describe the proposal

In addition to state and pub/sub components, dapr init should initialize a secret store component backed by a local JSON file, located in the default component directory.

Then in the docs we should always reference the secret store via secretRef instead of having credentials in plaintext.

#742 captures the ability to add secrets to this local secret store

Release Note

RELEASE NOTE: ADD local secret store component with dapr init

[AaronCrawfis]

Mockup

[AaronCrawfis]

Based on discussions with @wcs1only and @pkedy this could also be macOS KeyChain or Windows Credential Manager if we don't want to use a file

[withinboredom]

There's also the Gnome Keyring for Linux desktops. Ideally, these would be separate components (a Windows Credential Manager component, a macOS KeyChain component, and -- hopefully -- a Gnome Keyring component), and then dapr --init would just pick the most appropriate one. I think a file-based one should be included in cases where there isn't a local credential store or it's been disabled. My 2¢.

I think it's also possible for a keychain to become locked after being unlocked, which may deny dapr from reading secrets after it starts, which may be an interesting failure case that devs need to deal with. It's been a few years since I've written code to deal with those APIs so I don't completely remember if that's true or not.

[wcs1only]

There's also the Gnome Keyring for Linux desktops. Ideally, these would be separate components (a Windows Credential Manager component, a macOS KeyChain component, and -- hopefully -- a Gnome Keyring component), and then dapr --init would just pick the most appropriate one. I think a file-based one should be included in cases where there isn't a local credential store or it's been disabled. My 2¢.

I think it's also possible for a keychain to become locked after being unlocked, which may deny dapr from reading secrets after it starts, which may be an interesting failure case that devs need to deal with. It's been a few years since I've written code to deal with those APIs so I don't completely remember if that's true or not.

There's a couple of golang libs out there that wrap these in a consistent API:
https://github.com/keybase/go-keychain
https://github.com/zalando/go-keyring

I propose we do one of these first they should cover a substantial percentage of our users, and only do the file option if we find a real need or it is worth the security tradeoff.

[artursouza]

This issue is blocked on secret store being available first in contrib: dapr/components-contrib#1037

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

[mukundansundar]

pinned by dependent work in components-contrib