How-To: Scope components to one or more applications

Limit component access to particular Dapr instances

Dapr components are namespaced (separate from the Kubernetes namespace concept), meaning a Dapr runtime instance can only access components that have been deployed to the same namespace.

When Dapr runs, it matches it’s own configured namespace with the namespace of the components that it loads and initializes only the ones matching its namespaces. All other components in a different namespace are not loaded.

Namespaces

Namespaces can be used to limit component access to particular Dapr instances.

In self hosted mode, a developer can specify the namespace to a Dapr instance by setting the NAMESPACE environment variable. If the NAMESPACE environment variable is set, Dapr does not load any component that does not specify the same namespace in its metadata.

For example given this component in the production namespace

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: statestore
  5.   namespace: production
  6. spec:
  7.   type: state.redis
  8.   version: v1
  9.   metadata:
  10.   - name: redisHost
  11.     value: redis-master:6379

To tell Dapr which namespace it is deployed to, set the environment variable:

MacOS/Linux:

  1. export NAMESPACE=production
  2. # run Dapr as usual

Windows:

  1. setx NAMESPACE "production"
  2. # run Dapr as usual

Let’s consider the following component in Kubernetes:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: statestore
  5.   namespace: production
  6. spec:
  7.   type: state.redis
  8.   version: v1
  9.   metadata:
  10.   - name: redisHost
  11.     value: redis-master:6379

In this example, the Redis component is only accessible to Dapr instances running inside the production namespace.

Note

The component YAML applied to namespace “A” can reference the implementation in namespace “B”. For example, a component YAML for Redis in namespace “production-A” can point the Redis host address to the Redis instance deployed in namespace “production-B”.

See Configure Pub/Sub components with multiple namespaces for an example.

Application access to components with scopes

Developers and operators might want to limit access to one database from a certain application, or a specific set of applications. To achieve this, Dapr allows you to specify scopes on the component YAML. Application scopes added to a component limit only the applications with specific IDs from using the component.

The following example shows how to give access to two Dapr enabled apps, with the app IDs of app1 and app2 to the Redis component named statestore which itself is in the production namespace

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: statestore
  5.   namespace: production
  6. spec:
  7.   type: state.redis
  8.   version: v1
  9.   metadata:
  10.   - name: redisHost
  11.     value: redis-master:6379
  12. scopes:
  13. - app1
  14. - app2

Community call demo

Using namespaces with service invocation

Read Service invocation across namespaces for more information on using namespaces when calling between services.

Using namespaces with pub/sub

Read Configure Pub/Sub components with multiple namespaces for more information on using namespaces with pub/sub.

Last modified June 23, 2022: Merge pull request #2550 from ItalyPaleAle/cosmosdb-harcoded-dapr-version (cf03237)