On 11 Aug 2016, at 11:18, Juraci Paixão Kröhling wrote:
As other secrets on the standalone.xml (like data source passwords)
,
the password should be stored in the vault.
https://developer.jboss.org/wiki/MaskingPasswordsForWildFlyUsingNon-inter...
Doesn't $vault.sh --keystore key.store --keystore-password secretsecret
just move the issue one step away? At least when running this command at
container setup time (we can't burn the keystore+password into the image
we ship).
> for the Docker builds I can run (pseudocode):
>
> docker run -e HAWKULAR_USER=jdoe -e HAWKULAR_PASSWORD=password
> pilhuhn/hawkular-services
>
> the startup in the image takes care that jdoe is added to the
> users.properties file for JAAS
> and the agent gets those env-variables as user/password and the agent
> can talk to the
> server (see also below).
This is not for a production setup, right? On a production setup, the
user storage should not be user.properties and alike. Those will (or
even, should) come from actual external sources, like LDAP, databases,
...
I am mostly concerned about the Hawkular in Docker in ManageIQ
case, where we have a single technical user for Hawkular and
the agent (well, perhaps a second one for the agents?).
> == Agent side
>
> I recall that in the agent installer you have added some way of
> 'obfuscating' the password.
Vaults should be used for this. The good thing is that, AFAIK, no
change
on the agent is required. The subsystem sees the actual clear text
value
from the vault.
> == Server side
>
> Passing in the password like above to set up the server is equally
> bad
> (perhaps a tiny bit less, as the
> server is usually inside a more secured area than the agents).
I believe our docker images should be meant to be extended, so that
users can configure their user storage. The user.properties should be
seen as only a "placeholder"
This applies to the WildFly+agent side ("hawkfly"), but I do not
think users of MiQ should be forced to dork around with Docker
containers, replacing internals of Hawkular with something they
don't understand and then open Jiras with us.