Skip to content

docs: fix secret scope documentation for clarity #4965

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
msfussell merged 3 commits into from
Dec 12, 2025
+2 −32
Merged

docs: fix secret scope documentation for clarity #4965

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6d78718
Refactor secret scope documentation for clarity
caretak3r Dec 4, 2025
b9b06b6
Merge branch 'v1.16' into refactor-documentation-secret-scope
caretak3r Dec 9, 2025
ca43e46
Merge branch 'v1.16' into refactor-documentation-secret-scope
caretak3r Dec 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 2 additions & 32 deletions daprdocs/content/en/operations/configuration/secret-scope.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,9 +11,7 @@ In addition to [scoping which applications can access a given component]({{% ref
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

Expand Down Expand Up @@ -58,10 +56,8 @@ The `allowedSecrets` and `deniedSecrets` list values take priority over the `def

### 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:

1. Define the following `appconfig.yaml`.
1. Define the following `appconfig.yaml`.

```yaml
Expand All @@ -75,26 +71,8 @@ In a Kubernetes cluster, the native Kubernetes secret store is added to your Dap
- storeName: kubernetes
defaultAccess: deny
```
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
secrets:
scopes:
- storeName: kubernetes
defaultAccess: deny
```

1. Apply it to the Kubernetes cluster using the following command:

```bash
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.
1. Apply it to the Kubernetes cluster using the following command:
2. Apply it to the Kubernetes cluster using the following command:

```bash
kubectl apply -f appconfig.yaml`.
Expand All @@ -108,7 +86,6 @@ 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`:
Expand All @@ -126,7 +103,6 @@ spec:
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
Expand All @@ -151,9 +127,3 @@ This configuration explicitly denies access to `secret1` and `secret2` from the
## Next steps

{{< button text="Service invocation access control" page="invoke-allowlist.md" >}}

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.md" >}}
Loading