On 11.08.2016 12:16, Heiko W.Rupp wrote:
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).
If you run the command at container setup time, then you defeated the
purpose of the vault, yes.
There are two things here, from what I'm understanding: one is removing
clear text passwords from standalone.xml and the other is setting up
auth for hservices on Docker images.
Securing passwords can be achieved by using vaults, in or outside of
containers. Vaults are secured differently, and are meant to be
created/managed by the admins in control of the server.
Setting up auth on Docker containers should be a concern of the
Dockerfile, wherever it is, and not a concern of hservices itself.
As a "coincidence", I'm working on creating and admin/password for APM
(HWKAPM-462), using the same idea as Wildfly on OpenShift, where it
creates a random admin/password during the first boot:
https://snag.gy/b6aZWO.jpg
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?).
That's a solution to be applied on this specific build, not on
hservices. The Docker image that is to be consumed by MiQ would be
responsible for creating as many users as needed, the way it's needed.
- Juca.