Scope Pub/sub topic access

    Namespaces or component scopes can be used to limit component access to particular applications. These application scopes added to a component limit only the applications with specific IDs to be able to use the component.

    In addition to this general component scope, the following can be limited for pub/sub components:

    • Which topics which can be used (published or subscribed)
    • Which applications are allowed to publish to specific topics

    This is called pub/sub topic scoping.

    Pub/sub scopes are defined for each pub/sub component. You may have a pub/sub component named pubsub that has one set of scopes, and another pubsub2 with a different set.

    To use this topic scoping three metadata properties can be set for a pub/sub component:

    • spec.metadata.publishingScopes
      • A semicolon-separated list of applications & comma-separated topic lists, allowing that app to publish to that list of topics
      • If nothing is specified in publishingScopes (default behavior), all apps can publish to all topics
      • To deny an app the ability to publish to any topic, leave the topics list blank (app1=;app2=topic2)
      • For example, will allow app1 to publish to topic1 and nothing else, app2 to publish to topic2 and topic3 only, and app3 to publish to nothing.
    • spec.metadata.subscriptionScopes
      • A semicolon-separated list of applications & comma-separated topic lists, allowing that app to subscribe to that list of topics
      • If nothing is specified in subscriptionScopes (default behavior), all apps can subscribe to all topics
    • spec.metadata.allowedTopics
      • A comma-separated list of allowed topics for all applications.
      • If allowedTopics is not set (default behavior), all topics are valid. and publishingScopes still take place if present.
      • publishingScopes or subscriptionScopes can be used in conjunction with allowedTopics to add granular limitations

    These metadata properties can be used for all pub/sub components. The following examples use Redis as pub/sub component.

    Example 1: Scope topic access

    It can also be used for all topics to have always a “ground truth” for which applications are using which topics as publishers/subscribers.

    Here is an example of three applications and three topics:

    The table below shows which applications are allowed to publish into the topics:

    The table below shows which applications are allowed to subscribe to the topics:

    A topic is created if a Dapr application sends a message to it. In some scenarios this topic creation should be governed. For example:

    • A bug in a Dapr application on generating the topic name can lead to an unlimited amount of topics created
    • Streamline the topics names and total count and prevent an unlimited growth of topics

    Here is an example of three allowed topics:

    All applications can use these topics, but only those topics, no others are allowed.

    Example 3: Combine allowedTopics and scopes

    Sometimes you want to combine both scopes, thus only having a fixed set of allowed topics and specify scoping to certain applications.

    Here is an example of three applications and two topics:

    The table below shows which application is allowed to publish into the topics:

    Next steps