The documentation you are viewing is for Dapr v1.7 which is an older version of Dapr. For up-to-date documentation, see the latest version.

How To: Use secret scoping

Use scoping to limit the secrets that can be read by your application from secret stores

You can read guidance on setting up secret store components to configure a secret store for an application. Once configured, by default any secret defined within that store is accessible from the Dapr application.

To limit the secrets to which the Dapr application has access to, you can define secret scopes by adding a secret scope policy to the application configuration with restrictive permissions. Follow these instructions to define an application configuration.

The secret scoping policy applies to any secret store, whether that is a local secret store, a Kubernetes secret store or a public cloud secret store. For details on how to set up a secret stores 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. In the case of Kubernetes, aside from the user defined custom store, the default store named kubernetes is also addressed to ensure all secrets are denied access (See here to learn more about the Kubernetes default secret store).

To add this configuration follow the steps below:

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 that is named vault. For example this could be a Hashicorp secret store component that has been set on your application. To allow a Dapr application to have access to only certain secrets 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"]

This example defines configuration for secret store named vault. The default access to the secret store is deny, whereas some secrets are accessible by the application based on the allowedSecrets list. Follow these instructions to apply configuration to the sidecar.

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 uses a secret store that is named vault. The above configuration explicitly denies access to secret1 and secret2 from the secret store named vault while allowing access to all other secrets. Follow these instructions to apply configuration to the sidecar.

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

howto-secrets/


Last modified August 19, 2021: clean up all whitenoise (cbdab00b)