How To: Use secret scoping
Use scoping to limit the secrets that can be read by your application from secret stores
Once you configure a secret store for your application, any secret defined within that store is accessible by default from the Dapr application.
You can limit the Dapr application’s access to specific secrets by defining secret scopes. Simply add a secret scope policy to the application configuration with restrictive permissions.
The secret scoping policy applies to any secret store, including:
- A local secret store
- A Kubernetes secret store
- A public cloud secret store
For details on how to set up a secret store, read How To: Retrieve a secret.
Watch this video for a demo on how to use secret scoping with your application.
Scenario 1 : Deny access to all secrets for a secret store
In this example, all secret access is denied to an application running on a Kubernetes cluster, which has a configured Kubernetes secret store named mycustomsecretstore
. Aside from the user-defined custom store, the example also configures the Kubernetes default store (named kubernetes
) to ensure all secrets are denied access. Learn more about the Kubernetes default secret store.
Define the following appconfig.yaml
configuration and apply it to the Kubernetes cluster using the command kubectl apply -f appconfig.yaml
.
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: kubernetes
defaultAccess: deny
- storeName: mycustomsecreststore
defaultAccess: deny
For applications that need to be denied access to the Kubernetes secret store, follow these instructions, and add the following annotation to the application pod:
dapr.io/config: appconfig
With this defined, the application no longer has access to any secrets in the Kubernetes secret store.
Scenario 2 : Allow access to only certain secrets in a secret store
This example uses a secret store named vault
. This could be a Hashicorp secret store component set on your application. To allow a Dapr application to have access to only secret1
and secret2
in the vault
secret store, define the following appconfig.yaml
:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: vault
defaultAccess: deny
allowedSecrets: ["secret1", "secret2"]
The default access to the vault
secret store is deny
, while some secrets are accessible by the application, based on the allowedSecrets
list. [Learn how to apply configuration to the sidecar]](https://v1-8.docs.dapr.io/concepts/configuration-concept/).
Scenario 3: Deny access to certain sensitive secrets in a secret store
Define the following config.yaml
:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: vault
defaultAccess: allow # this is the default value, line can be omitted
deniedSecrets: ["secret1", "secret2"]
This example configuration explicitly denies access to secret1
and secret2
from the secret store named vault
while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]](https://v1-8.docs.dapr.io/concepts/configuration-concept/).
Permission priority
The allowedSecrets
and deniedSecrets
list values take priority over the defaultAccess
policy.
Scenarios | defaultAccess | allowedSecrets | deniedSecrets | permission |
---|---|---|---|---|
1 - Only default access | deny/allow | empty | empty | deny/allow |
2 - Default deny with allowed list | deny | [“s1”] | empty | only “s1” can be accessed |
3 - Default allow with deneied list | allow | empty | [“s1”] | only “s1” cannot be accessed |
4 - Default allow with allowed list | allow | [“s1”] | empty | only “s1” can be accessed |
5 - Default deny with denied list | deny | empty | [“s1”] | deny |
6 - Default deny/allow with both lists | deny/allow | [“s1”] | [“s2”] | only “s1” can be accessed |
Related links
- List of secret stores
- Overview of secret stores
Last modified September 28, 2022: [Secrets Mgmt] overview & how-to refresh (#2678) (e4112bba)