Interact with Kubernetes Dapr apps using Dapr CLI

[hanzvanaardt]

I recently completed my first deployment of Dapr onto our Kubernetes Cluster and wanted to do some tests against the Dapr apps. I was hoping to use invokeGet, invokePost and Publish for these tested only to realize that the kubernetes implementation of these features does not exist.

It will be very helpful if one is able to use invokeGet, invokePost and Publish with the -k option to invoke and publish against Dapr app sidecars running in a kubernetes cluster.

[pkedy]

This would totally be a nice feature for development but I wanted to raise a question around security. My assumption is that the sidecars should only trust communication from the app containers in the same pod and the other running Dapr sidecars (via mTLS, etc). Would exposing a mechanism to use invokeGet, invokePost, and publish essentially bypass that level of trust? Am I missing something?

I'm wondering if maybe a solution (granted pie in the sky) would be to deploy some sort of REPL container behind a Dapr that is adheres to the security pattern above. One could use OPA/admission controllers to make this this never accidentally gets deployed into production K8s environments. Thoughts?

[pkedy]

Also might consider using kubectl port-forward to accomplish this. https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod One downside is that you would not receive callbacks to Publish operations.

[yaron2]

One downside is that you would not receive a callbacks to a Publish operations.

The app running on k8s will receive the callbacks. Your local machine won't. :)

[imneov]

I am currently working on an iot platform based on Dapr. We chose dapr because dapr can be used in both kubernetes mode and self-hosted mode.

We extend Dapr CLI so that the invoke command supports Kubernetes mode. The goal is to simplify documentation and testing.

Compared with kubectl port-forward, using invokeGet and invokePost with the -k option will make the whole process more concise. This allows Dapr CLI to have a consistent experience in kubernetes mode and self-hosted mode.

The process is similar:

1. Get the Pod corresponding to the App
2. Complete the specific communication through the SubResource("proxy") of RESTClient
3. Direct access to App's AppPort port or access to daprd's HttpPort port

                                      +-----------------+
                                      |                 |
                     AppPort          | +-------------+ |
         +----------------------------> |    APP      | |
  +----------+                        | +-------------+ |
  | dapr cli |                        |                 |
  +----------+                        | +-------------+ |
         +----------------------------> |    Daprd    | |
                    HttpPort          | +-------------+ |
                                      |                 |
                                      |            pod  |
                                      +-----------------+

[mukundansundar]

This sounds interesting. /cc @yaron2 thoughts?

[yaron2]

I support adding this functionality. @imneov would you be willing to submit a PR for this?

[imneov]

@yaron2 yes, that was the plan 🙂

[mukundansundar]

@imneov please comment as /assign in this issue to work on this. Please close the other issue in this case also.

[imneov]

/assign

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.