should we use a Secret for the application.properties?

[jstrachan]

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?

[KurtStam]

I would argue that the citizen developer would need access to the config, but may not need/have access to secret stuff, so it may make sense to split this up now rather then later. So my vote would be to make the split between Secret and ConfigMap now. my 2 cents

…

--K

On Tue, Dec 20, 2016 at 5:37 AM, James Strachan ***@***.***> wrote: 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? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACK-En3hCRLrcDaBPgcT5JHBJSfVZJgks5rJ6_4gaJpZM4LRsRS> .

-- Kurt T. Stam twitter: @KurtStam google+: kurt.stam@gmail.com

[iocanel]

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.

[jstrachan]

I think the next Camel version maintains the metadata of which properties are secret

[jstrachan]

@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)

[jimmidyson]

We have an open question whether openshift/kubernetes are secret enough... Do we need encryption at rest, etc.

[markrey]

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