7.3 KiB
type | title | linkTitle | weight | description | description |
---|---|---|---|---|---|
docs | How-To: Limit the secrets that can be read from secret stores | Limit secret store access | 3000 | Define secret scopes by augmenting the existing configuration resource with restrictive permissions. | Define secret scopes by augmenting the existing configuration resource with restrictive permissions. |
In addition to [scoping which applications can access a given component]({{< ref "component-scopes.md">}}), you can also scope a named secret store component to one or more secrets for an application. By defining allowedSecrets
and/or deniedSecrets
lists, you restrict applications to access only specific secrets.
In addition to [scoping which applications can access a given component]({{< ref "component-scopes.md">}}), you can also scope a named secret store component to one or more secrets for an application. By defining allowedSecrets
and/or deniedSecrets
lists, you restrict applications to access only specific secrets.
For more information about configuring a Configuration resource:
- [Configuration overview]({{< ref configuration-overview.md >}})
- [Configuration schema]({{< ref configuration-schema.md >}}) For more information about configuring a Configuration resource:
- [Configuration overview]({{< ref configuration-overview.md >}})
- [Configuration schema]({{< ref configuration-schema.md >}})
Configure secrets access
The secrets
section under the Configuration
spec contains the following properties:
secrets:
scopes:
- storeName: kubernetes
defaultAccess: allow
allowedSecrets: ["redis-password"]
- storeName: localstore
defaultAccess: allow
deniedSecrets: ["redis-password"]
The following table lists the properties for secret scopes:
Property | Type | Description |
---|---|---|
storeName | string | Name of the secret store component. storeName must be unique within the list |
defaultAccess | string | Access modifier. Accepted values "allow" (default) or "deny" |
allowedSecrets | list | List of secret keys that can be accessed |
deniedSecrets | list | List of secret keys that cannot be accessed |
When an allowedSecrets
list is present with at least one element, only those secrets defined in the list can be accessed by the application.
Permission priority
The allowedSecrets
and deniedSecrets
list values take priority over the defaultAccess
. See how this works in the following example scenarios:
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 denied 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 |
Examples
Scenario 1: Deny access to all secrets for a secret store
In a Kubernetes cluster, the native Kubernetes secret store is added to your 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: In a Kubernetes cluster, the native Kubernetes secret store is added to your 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:
-
Define the following
appconfig.yaml
. -
Define the following
appconfig.yaml
.apiVersion: dapr.io/v1alpha1 kind: Configuration metadata: name: appconfig spec: secrets: scopes: - storeName: kubernetes defaultAccess: deny
apiVersion: dapr.io/v1alpha1 kind: Configuration metadata: name: appconfig spec: secrets: scopes: - storeName: kubernetes defaultAccess: deny
-
Apply it to the Kubernetes cluster using the following command:
kubectl apply -f appconfig.yaml`.
For applications that you need to deny access to the Kubernetes secret store, follow [the Kubernetes instructions]({{< ref kubernetes-overview >}}), adding the following annotation to the application pod.
-
Apply it to the Kubernetes cluster using the following command:
kubectl apply -f appconfig.yaml`.
For applications that you need to deny access to the Kubernetes secret store, follow [the Kubernetes instructions]({{< ref kubernetes-overview >}}), adding the following annotation to the application pod.
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
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
:
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
. Meanwhile, some secrets are accessible by the application based on the allowedSecrets
list. Follow [the Sidecar configuration instructions]({{< ref "configuration-overview.md#sidecar-configuration" >}}) to apply configuration to the sidecar.
This example defines configuration for secret store named vault
. The default access to the secret store is deny
. Meanwhile, some secrets are accessible by the application based on the allowedSecrets
list. Follow [the Sidecar configuration instructions]({{< ref "configuration-overview.md#sidecar-configuration" >}}) 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 configuration explicitly denies access to secret1
and secret2
from the secret store named vault,
while allowing access to all other secrets. Follow [the Sidecar configuration instructions]({{< ref "configuration-overview.md#sidecar-configuration" >}}) to apply configuration to the sidecar.
Next steps
{{< button text="Service invocation access control" page="invoke-allowlist" >}}
This configuration explicitly denies access to secret1
and secret2
from the secret store named vault,
while allowing access to all other secrets. Follow [the Sidecar configuration instructions]({{< ref "configuration-overview.md#sidecar-configuration" >}}) to apply configuration to the sidecar.
Next steps
{{< button text="Service invocation access control" page="invoke-allowlist" >}}