How To: Use secret scoping

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

Follow these instructions to configure secret store for an application. Once configured, any secret defined within that store will be accessible from the Dapr application.

To limit the secrets to which the Dapr application has access, users can define secret scopes by augmenting existing configuration CRD with restrictive permissions.

Follow these instructions to define a configuration CRD.

Scenario 1 : Deny access to all secrets for a secret store

In Kubernetes cluster, the native Kubernetes secret store is added to Dapr application by default. In some scenarios it may be necessary to deny access to Dapr secrets for a given application. To add this configuration follow the steps below:

Define the following appconfig.yaml and apply it to the Kubernetes cluster using the command kubectl apply -f appconfig.yaml.

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: appconfig
  5. spec:
  6. secrets:
  7. scopes:
  8. - storeName: kubernetes
  9. 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.

  1. dapr.io/config: appconfig

With this defined, the application no longer has access to Kubernetes secret store.

Scenario 2 : Allow access to only certain secrets in a secret store

To allow a Dapr application to have access to only certain secrets, define the following config.yaml:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: appconfig
  5. spec:
  6. secrets:
  7. scopes:
  8. - storeName: vault
  9. defaultAccess: deny
  10. 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 senstive secrets in a secret store

Define the following config.yaml:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Configuration
  3. metadata:
  4. name: appconfig
  5. spec:
  6. secrets:
  7. scopes:
  8. - storeName: vault
  9. defaultAccess: allow # this is the default value, line can be omitted
  10. deniedSecrets: ["secret1", "secret2"]

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 priorty over the defaultAccess.

ScenariosdefaultAccessallowedSecretsdeniedSecretspermission
1 - Only default accessdeny/allowemptyemptydeny/allow
2 - Default deny with allowed listdeny[“s1”]emptyonly “s1” can be accessed
3 - Default allow with deneied listallowempty[“s1”]only “s1” cannot be accessed
4 - Default allow with allowed listallow[“s1”]emptyonly “s1” can be accessed
5 - Default deny with denied listdenyempty[“s1”]deny
6 - Default deny/allow with both listsdeny/allow[“s1”][“s2”]only “s1” can be accessed

Last modified February 16, 2021: Merge pull request #1235 from dapr/update-v0.11 (b4e9fbb)