should we use a Secret for the application.properties?
Opened this issue · 6 comments
The connector configuration frequently contains username, passwords, tokens and secrets. e.g. for the twitter component all the component properties should be secret
One day we may want to split the configuration between 2 resources; a ConfigMap and a Secret; with secret stuff only going into the Secret.
However for now - maybe just using a Secret instead of a ConfigMap for the connector configuration is simplest? It then makes sure the configuration is all secret?
If we don't have a way to mark which configuration keys are passwords, keys or aneything else that needs to be secret, then using Secrets instead of ConfigMap is oneway right?
I recall that a long time ago, there have been an request raised in Camel, to mask passwords, etc when presenting endpoint urls in logs, jmx etc. I don't know if it was ever implemented, but it might worth checking if it has and if we can extract that info from there.
I think the next Camel version maintains the metadata of which properties are secret
@KurtStam there may be properties that the citizen developer may need to populate that are secret (e.g. login / passwords to sales force or something)
We have an open question whether openshift/kubernetes are secret enough... Do we need encryption at rest, etc.
I was just browsing through documents and found this.
We have lots of static and dynamic secrets. ( For example, OAuth token which is getting refreshed every few days by other application ).
Example would be,
Funktion Camel flow starts -> acquires and uses token from Vault -> Make API call -> Stop
Is there possiblity to store all secrets in some sort of small HA KV database.
Something like Hashicorp Vault.
https://github.com/hashicorp/vault