search

camunda / camunda-modeler

An integrated modeling solution for BPMN, DMN and Forms based on bpmn.io.
https://camunda.com/products/modeler
MIT License
1.47k stars 473 forks source link

Enable process deployment with client authentication / mutual TLS #2404

Open strangelookingnerd opened 2 years ago

strangelookingnerd commented 2 years ago

Even though it is possible to secure a Camunda Platform instance with client authentication / mutual TLS the modeler is unable to connect to this instance to deploy / start processes. In context of enterprise solutions this is often a requirement and thus should be considered as a feature.

In camunda-modeler\client\src\plugins\camunda-plugin\shared\CamundaAPI.js there is a central fetch implementation that should be extended to allow passing a client certificate. See https://github.com/arantes555/electron-fetch/issues/18 for a rough idea. I had a go at a pull-request however hit a wall since JavaScript is not my natural habitat ;) I seemed to have trouble with the React implementation of fetch and importing the required modules. Having a proper selection / configuration of a client certificate similar to any browser (see below) would be desired as well which again is out of my league. K9zG8 Most companies will have their client certificates 'burnt-into' the browsers or will use the certificate store of the OS so you would get around any 'local' configuration - however I would not know how to access this from the context of the modeler.

Since I do require a solution here is what I did: I created a small webapp that allows uploading a file and deploy / start a process using the Process Engines REST API and put it right next to the Camunda Platform. For the modeler I created a small plugin (more a menu extension to be honest) that will open a browser with the URL of my webapp. Since the browser takes care of the selection of an certificate this is a fairly simple however effective solution.

nikku commented 2 years ago

Thanks for opening this issue. We accept contributions that improve the current situation.

barmac commented 2 years ago

Some more insights on this issue can be found in https://github.com/camunda/camunda-modeler/issues/2807

Also cf. https://stackoverflow.com/questions/38986692/how-do-i-trust-a-self-signed-certificate-from-an-electron-app

barmac commented 2 years ago

Added as a spring cleaning topic @MaxTru

christian-konrad commented 2 years ago

@CatalinaMoisuc due to a customer request, I would like us to work on this item in one of the following iterations. I moved it into "ready" therefore. TLS support for a local Zeebe dev cluster was added due to a request of this customer, but unfortunately, the Desktop Modeler is not able to connect to this cluster, so it felt for the customer like a "half-baked" solution, and for their development cycle it is crucial (and I think for others, too). Maybe the problem could be mitigated by the Web Modeler Self-Managed (can you confirm it?), but we shouldn't wait for this long.

christian-konrad commented 2 years ago

A customer reported this, too. Here are the details from the customer request:

Camunda modeler cannot deploy to Zeebe anymore. We have activated a secure HTTPS connection to access the Zeebe Gateways, it might be that camunda modeler doesn't support TLS.

What are the steps to reproduce your problem?

Context:

Which product and version do you currently use? Desktop Modeler 5.0.

In which environments (staging, production, etc.) do you need the feature? Development

Please describe the missing / desired functionality: Add HTTPS / TLS support to Modeler.

What problem would the feature solve? Cannot deploy models to TLS secured Zeebe instance (after we got the TLS security in SUPPORT-12080)

What effort would be required without the feature? Reduced development speed as it is not possible to fix BPMN models in DEV in an iterative fashion.

Do you have a deadline by which you need the feature? Q3. Unless there is a workaround, like using zbctl? Does it support deployment with TLS? If there is a workaround, Q4 is acceptable for us.

Why do you need the feature? Fast iteration / bug fixes in a secure development environment. If we cannot deploy directly to test things out, then we need to do git branch, MR, validation, merge in master and CD to dev.

So a 2 minute test becomes a 2 hour test and that negatively impacts the velocity of the whole team.

Who benefits from the feature (developers, end users, management) and how big are the respective benefiting groups? Developers and consultants

If this feature is not implemented, what impact would it have on you and / or your business? Reduced velocity, longer projects with customers.

ajeans commented 2 years ago

To explain further, the zbctl workaround that is mentioned above consists in doing the following:

# port forward to localhost 26500
kubectl port-forward -n zeebe-caseflow service/zeebe-gateway 26500 
# retrieve the TLS certificate
openssl s_client -connect 127.0.0.1:26500 -showcerts
# And copy the certificate in stdout to dev.crt
./bin/zbctl deploy demo-signature.bpmn --address localhost:26500 --certPath bin/dev.crt --authority zeebe-gateway.zeebe-caseflow
{
  "key": "2251799815028155",
  "processes": [
    {
      "bpmnProcessId": "demo-signature",
      "version": 4,
      "processDefinitionKey": "2251799815028154",
      "resourceName": "demo-signature.bpmn"
    }
  ]
}
barmac commented 2 years ago

Thank you. This will be useful when I work on the issue :)

barmac commented 2 years ago

I see that a custom certificate can also be passed to the Zeebe client we use: https://github.com/camunda-community-hub/zeebe-client-node-js#using-a-self-signed-certificate

barmac commented 2 years ago

I looked deeper into this. So far, I was able to setup Zeebe with a custom certificate. I haven't done it for C7. I can connect to it with zbctl, but cannot do that with either Camunda Modeler (expected) or with zeebe-node, which fails with:

(node:45440) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
    at Object.connect (node:_tls_wrap:1671:15)
    at Object.connect (node:internal/http2/core:3277:22)
    at Subchannel.createSession (/Users/maciej/workspace/zeebe/connection-test/node_modules/@grpc/grpc-js/build/src/subchannel.js:400:31)
    at /Users/maciej/workspace/zeebe/connection-test/node_modules/@grpc/grpc-js/build/src/subchannel.js:495:18
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
15:39:51.289 | zeebe |  ERROR: [topology]: 14 UNAVAILABLE: No connection established
client code ```javascript const ZB = require('zeebe-node') const fs = require('fs') const cert = fs.readFileSync('./cert.pem') void (async () => { const zbc = new ZB.ZBClient('0.0.0.0:26500', { useTLS: true, customSSL: { rootCerts: cert } }) const topology = await zbc.topology() console.log(JSON.stringify(topology, null, 2)) })() ```

I can already see that the implementations for C7 and C8 will differ a lot even though the UI may/should be similar. Also, we could potentially have mutual TLS for C7, but not for C8, because it's not supported yet. Therefore, I think we should split the issue into C7 and C8 issues respectively.

There are three stories in this issue:

barmac commented 2 years ago

@ajeans I moved the C8-related discussion to a new issue: https://github.com/camunda/camunda-modeler/issues/3028

This one will be moved to backlog, as we are focused on C8 support.