How-to: Mount Pod volumes to the Dapr sidecar

Configure the Dapr sidecar to mount Pod Volumes

The Dapr sidecar can be configured to mount any Kubernetes Volume attached to the application Pod. These Volumes can be accessed by the daprd (sidecar) container in read-only or read-write modes. If a Volume is configured to be mounted but it does not exist in the Pod, Dapr logs a warning and ignores it.

For more information on different types of Volumes, check the Kubernetes documentation.

Configuration

You can set the following annotations in your deployment YAML:

AnnotationDescription
dapr.io/volume-mountsFor read-only volume mounts
dapr.io/volume-mounts-rwFor read-write volume mounts

These annotations are comma separated pairs of volume-name:path/in/container. Verify the corresponding Volumes exist in the Pod spec.

Within the official container images, Dapr runs as a process with user ID (UID) 65532. Make sure that folders and files inside the mounted Volume are writable or readable by user 65532 as appropriate.

Although you can mount a Volume in any folder within the Dapr sidecar container, prevent conflicts and ensure smooth operations going forward by placing all mountpoints within one of the following locations, or in a subfolder within them:

LocationDescription
/mntRecommended for Volumes containing persistent data that the Dapr sidecar process can read and/or write.
/tmpRecommended for Volumes containing temporary data, such as scratch disks.

Examples

Basic deployment resource example

In the example Deployment resource below:

  • my-volume1 is available inside the sidecar container at /mnt/sample1 in read-only mode
  • my-volume2 is available inside the sidecar container at /mnt/sample2 in read-only mode
  • my-volume3 is available inside the sidecar container at /tmp/sample3 in read-write mode
  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: myapp
  5. namespace: default
  6. labels:
  7. app: myapp
  8. spec:
  9. replicas: 1
  10. selector:
  11. matchLabels:
  12. app: myapp
  13. template:
  14. metadata:
  15. labels:
  16. app: myapp
  17. annotations:
  18. dapr.io/enabled: "true"
  19. dapr.io/app-id: "myapp"
  20. dapr.io/app-port: "8000"
  21. dapr.io/volume-mounts: "my-volume1:/mnt/sample1,my-volume2:/mnt/sample2"
  22. dapr.io/volume-mounts-rw: "my-volume3:/tmp/sample3"
  23. spec:
  24. volumes:
  25. - name: my-volume1
  26. hostPath:
  27. path: /sample
  28. - name: my-volume2
  29. persistentVolumeClaim:
  30. claimName: pv-sample
  31. - name: my-volume3
  32. emptyDir: {}
  33. ...

Custom secrets storage using local file secret store

Since any type of Kubernetes Volume can be attached to the sidecar, you can use the local file secret store to read secrets from a variety of places. For example, if you have a Network File Share (NFS) server running at 10.201.202.203, with secrets stored at /secrets/stage/secrets.json, you can use that as a secrets storage.

  1. Configure the application pod to mount the NFS and attach it to the Dapr sidecar.

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4. name: myapp
    5. ...
    6. spec:
    7. ...
    8. template:
    9. ...
    10. annotations:
    11. dapr.io/enabled: "true"
    12. dapr.io/app-id: "myapp"
    13. dapr.io/app-port: "8000"
    14. dapr.io/volume-mounts: "nfs-secrets-vol:/mnt/secrets"
    15. spec:
    16. volumes:
    17. - name: nfs-secrets-vol
    18. nfs:
    19. server: 10.201.202.203
    20. path: /secrets/stage
    21. ...
  2. Point the local file secret store component to the attached file.

    1. apiVersion: dapr.io/v1alpha1
    2. kind: Component
    3. metadata:
    4. name: local-secret-store
    5. spec:
    6. type: secretstores.local.file
    7. version: v1
    8. metadata:
    9. - name: secretsFile
    10. value: /mnt/secrets/secrets.json
  3. Use the secrets.

    1. GET http://localhost:<daprPort>/v1.0/secrets/local-secret-store/my-secret

Dapr Kubernetes pod annotations spec

Last modified October 12, 2023: Update config.toml (#3826) (0ffc2e7)