The documentation you are viewing is for Dapr v1.10 which is an older version of Dapr. For up-to-date documentation, see the latest version.
Default Kubernetes secret store component
When Dapr is deployed to a Kubernetes cluster, a secret store with the name
kubernetes is automatically provisioned. This pre-provisioned secret store allows you to use the native Kubernetes secret store with no need to author, deploy or maintain a component configuration file for the secret store and is useful for developers looking to simply access secrets stored natively in a Kubernetes cluster.
A custom component definition file for a Kubernetes secret store can still be configured (See below for details). Using a custom definition decouples referencing the secret store in your code from the hosting platform as the store name is not fixed and can be customized, keeping your code more generic and portable. Additionally, by explicitly defining a Kubernetes secret store component you can connect to a Kubernetes secret store from a local Dapr self-hosted installation. This requires a valid
Scoping secret store accessWhen limiting access to secrets in your application using secret scopes, it’s important to include the default secret store in the scope definition in order to restrict it.
Create a custom Kubernetes secret store component
To setup a Kubernetes secret store create a component of type
secretstores.kubernetes. See this guide on how to create and apply a secretstore configuration. See this guide on referencing secrets to retrieve and use the secret with Dapr components.
Spec metadata fields
For the Kubernetes secret store component, there are no metadata attributes.
- Secrets building block
- How-To: Retrieve a secret
- How-To: Reference secrets in Dapr components
- Secrets API reference
- How To: Use secret scoping
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.