[keycloak-user] Securely setting admin passwords

[Tim Dudgeon]

I was also struggling with this, but another post pointed to this info 
that allows the user/pass to be defined using environment variables. 
Should solve the problem?
https://github.com/jboss-dockerfiles/keycloak/tree/master/server

Tim


On 17/02/2016 21:52, Aikeaguinea wrote:
> Running in Amazon's Elastic Container Service with an autoscaling group,
> which can bring up new EC2 instances to host the Dockers at any time
> without manual intervention, makes it challenging to share the file via
> volume or use the http URL.
>
> So far I've had the Wildfly startup wrapped in a script that calls
> add-user.sh before the server starts; we were thinking of using
> something like CredStash (https://github.com/fugue/credstash) as the
> source for the credentials. Then start-keycloak.sh would look something
> like this:
>
>       # Container needs to know its host, for JGroups
>       export EXTERNAL_HOST_IP=$(curl -s
>       169.254.169.254/latest/meta-data/local-ipv4)
>
>       $WILDFLY_HOME/bin/add-user.sh --container -u admin -p $(credstash
>       get $KEYCLOAK_WILDFLY_ADMIN_PWD_KEY)
>       $WILDFLY_HOME/bin/add-user.sh -u admin -p $(credstash get
>       $KEYCLOAK_ADMIN_PWD_KEY)
>
>       # Allow graceful shutdown from `docker stop`, which issues SIGTERM.
>       trap "$WILDFLY_HOME/bin/stop-keycloak.sh" SIGTERM
>       exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>       -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME
>
> Still, the password is being passed in the clear on the command line,
> and is visible via a process listing. Since the command is being run
> inside Docker, this would ultimately expose the password in cleartext to
> a docker history command.
>
> It looks like I'm going to have to figure out how to mount the files
> from a volume. Are the relevant files
> standalone/configuration/keycloak-add-user.json and
> standalone/configuration/mgmt-users.properties ?
>
>   Date: Wed, 17 Feb 2016 21:52:57 +0100
>> From: Marek Posolda <mposolda at redhat.com>
>> Subject: Re: [keycloak-user] Securely setting admin passwords
>> To: Aikeaguinea <aikeaguinea at xsmail.com>,
>> 	keycloak-user at lists.jboss.org
>> Message-ID: <56C4DDA9.2090401 at redhat.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> You can create the file in some "safe" environment (your laptop) and
>> then share the file with docker via volume and copy to the
>> standalone/configuration of the server? The created JSON file doesn't
>> contain password in plain text, but it's encoded.
>>
>> Also the "add-user.sh" script doesn't need server to be running.
>>
>> Finally, uf you don't need automated way, you can set it manually after
>> first startup when going to http://localhost:8080/auth
>>
>> Marek
>>
>>
>> On 17/02/16 17:09, Aikeaguinea wrote:
>>> It seems the add-user.sh  script for changing the admin password only
>>> accepts the password as a -p command-line parameter. This would expose
>>> the password in the command history, so I'd prefer not to use the
>>> command in its current form.
>>>
>>> Is there another way to do this?
>>>
>>> The situation is even more complicated with Docker, since running the
>>> script to change the Wildfly admin password requires restarting the
>>> server, which shuts down the container. If you have an autoscaling
>>> group, the container that gets brought up is not the container where you
>>> changed the password, but instead the original container. This seems to
>>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>>> group is to bake the admin passwords into the Docker image beforehand.
>>> This isn't ideal; less so if the only way to add those passwords during
>>> build time is to run the shell script that exposes the password on the
>>> command line.