How-To: Limit the secrets that can be read from secret stores

    In addition to scoping which applications can access a given component, for example a secret store component (see Scoping components), a named secret store component itself can be scoped to one or more secrets for an application. By defining and/or deniedSecrets list, applications can be restricted to access only specific secrets.

    Follow to define a configuration CRD.

    The secrets section under the Configuration spec contains the following properties:

    The following table lists the properties for secret scopes:

    The 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

    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.

    For applications that need to be deined access to the Kubernetes secret store, follow these instructions, and add the following annotation to the application pod.

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

    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 to apply configuration to the sidecar.

    Define the following config.yaml:

    The above configuration explicitly denies access to secret1 and from the secret store named vault while allowing access to all other secrets. Follow these instructions to apply configuration to the sidecar.