Skip to main content

Known Limitations

Unsupported components​

For security reasons, the agent doesn't have access to the application container. This means the following components cannot be validated will always appear initialized successfully: bindings.localstorage, secretstores.local.env, secretstores.local.file

Pod-identity enabled components​

Dapr components that use pod identity mechanisms such as Azure Active Directory Workload Identity or IAM Roles for pods with a Kubernetes service account will always fail to be initialized due to lack of permissions on the Conductor agent pod to authenticate with the identity provider and validate the component

Cross-namespace component checks​

Some components that reside in a different namespace than the Conductor agent have dependencies that can lead to false communication errors, when in fact the component is healthy in its own namespace. Kubernetes network policies between namespaces can also cause incorrect component initialization statuses. For example:

Let's say a Dapr-enabled app that uses the following Redis component is deployed in the namespace crud-app. The Redis server has a hostname redis-master and is deployed with a Kubernetes Service in the same crud-app namespace.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: redis-pubsub
  namespace: crud-app
spec:
  type: pubsub.redis
  version: v1
  metadata:
    - name: redisHost
      value: "redis-master:6379"

Because the Conductor agent is running in the diagrid-cloud namespace, when the component's Init function runs, it will attempt to connect to hostname redis-master:6379. Since this hostname does not resolve in the diagrid-cloud namespace, Init will result in a communication error.

Mitigation

For the agent to check the component initialization status successfully, it's suggested to specify the service's name along with its corresponding namespace in the connection details like redis-master.crud-app:6379, or use the full hostname like redis-master.crud-app.svc.cluster.local:6379.