Http-connector authentication? + Secret storage?

[StephenOTT]

Is there any code examples of having http connector use any form of authentication to a web service?
Looking for some patterns. My initial thought is your store any sort of credentials as a process variable?

But additional question is: any sort of patterns for Secret/credential storage? Something like use case with Hashicorp Vault, etc?

I know you can abstract into delegate code, but looking at http connector first and then expand from there

[Webcyberrob]

Hi Stephen,
Ive wrestled with this myself. One option Ive considered is store the secrets in the catalina.properties file and thus they are available as system properties. Hence in connector code, use an expression to substitute the property value. In addition, I can have different property file in each environment (dev, test etc). Hence the process model works in each environment unchanged.

In terms of restricted access, for a production linux machine, Id create a system account for tomcat, but disable login/console access. Hence the system can run as tomcat, but nobody can get onto the consol as tomcat. The admins must login with a privileged account and sudo. Hence the ‘secrets’ are protected via access controls on a need to know basis…

regards

Rob

[StephenOTT]

Interesting.

In your example, the properties file would be accessible to all processes within a deployment or across all deployments? (In my scenario we use shared engine with only Camunda Deployments/REST API deployments. No WAR deployments).

I don’t see a problem with storing something like Hashicorp Vault keys in the process as long as it is auditable and could roll the access as required through the Vault. Additionally you could add restrictions that would make is so only the specific process would be able to access information in the vault. But again not a “perfect” solution as of yet.

@camunda any thoughts or best practices?

[hawky4s]

Hi Stephen,

Imo using Vault or a similar token-based mechanism is probably the best tradeoff of security / auditing / usability.
You could inject a (one-/multiple-time-usage) token from vault at the start of the process which allows the process to use the token to pull in the credentials from vault one or more times at the right time. It shouldn’t be a problem to save the token as a process variable because of its short lifetime. When using Vault, probably the cubbyhole backend is the way to go. I experimented with it for injecting secrets in docker image/containers for our CI environment.
Imo Vault is especially nice to work with because of its rich right/namespace model and the REST API.

Cheers,
Christian

[StephenOTT]

@hawky4s Thanks! You see the token from vault is being invoked/injected from outside of the process or called from inside of the process?

[StephenOTT]

@hawky4s did you ever do any more in this space? I have circled back to it and looking at doing a implementation with “something” in the next few weeks.

[StephenOTT]

Cross-Reference for future info:

Using secrets/passwords securely in processes (Using Docker Secrets, not storing passwords in process variables)

Hey all So we have had some discussions about how to store secrets/passwords when working with Processes: Recently we came up with the following solution: Using Docker Secrets (Blog | Docker) you can manage sensitive data: with the Secrets feature, which basically creates a in-memory volume that stores your secret(s): Manage sensitive data with Docker secrets | Docker Documentation How Docker manages secrets When you add a secret to the swarm, Docker sends the secret to the swarm manager…