[keycloak-user] Securely setting admin passwords

Tue Feb 23 04:08:39 EST 2016

That doesn't seem ideal to me as you're then "hard-coding" the password
into the Docker image.

On 23 February 2016 at 10:03, Bruno Oliveira <bruno at abstractj.org> wrote:

> I think the best approach is to add keycloak-user.json. Even if we provide
> some sorta of public key encryption for protecting passwords, at some point
> would be mandatory for automation scripts to be prompted for the admin's
> password.
>
> On Tue, Feb 23, 2016 at 3:19 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> If you have suggestions to changes/additions we can do to make it more
>> secure feel free to let us now
>>
>> On 22 February 2016 at 16:32, Aikeaguinea <aikeaguinea at xsmail.com> wrote:
>>
>>> We're essentially doing this. Since we need to secure the Wildfly admin
>>> password as well, we are basically running the add-user.sh scripts to
>>> generate the keycloak-user.json and mgmt-users.properties before running
>>> the Docker script, and then adding them to the image. This has the
>>> disadvantage of baking the passwords into the image, but at least
>>> they're encrypted and the image is stored in a secure repository, which
>>> is probably as good as we're going to get.
>>>
>>>
>>>
>>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke
>>> <bburke at redhat.com>
>>> Date: Monday, February 22, 2016 at 10:21 AM
>>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] Securely setting admin passwords
>>>
>>> I'm too lazy to read this entire thread, sorry if somebody already
>>> suggested this, but can't you
>>>
>>> 1) Create a minimal realm in your local environment and export the realm
>>> to json.
>>> 2) Import this json in your Docker script?
>>>
>>>
>>>
>>> On 2/22/2016 10:10 AM, Aikeaguinea wrote:
>>> With regard to Docker, things get more complicated. I believe it's not
>>> just the bash history but the Docker history itself that stores the
>>> commands.
>>>
>>> Also, per one of the messages earlier on this chain, it is not advised
>>> to put secrets into Docker environment variables. These are accessible
>>> in many different ways.
>>>
>>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
>>> <ssilvert at redhat.com>
>>> Date: Thursday, February 18, 2016 at 12:26 PM
>>> To: "stian at redhat.com" <stian at redhat.com>
>>> Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
>>> <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] Securely setting admin passwords
>>>
>>> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>>> It's security vs usability as usual. Allowing passing the password
>>> directly is convenient for developers, for Docker image, for
>>> provisioning tools, etc.. So we're not going to remove that it's
>>> required, but I do appreciate that if not used correctly it's a
>>> potential security risk. The worst case scenario here is really that
>>> someone gets an admins favorite password, as someone that has access to
>>> getting the bash history of that particular user will also be able to
>>> run the add-user script themselves. So if the admin wants to print his
>>> favorite password in clear text in the bash history we should not stop
>>> him.
>>>
>>> It's not our responsibility to clear the bash history, so we should not
>>> do that either.
>>> If there is a way to stop that one command from being saved in the bash
>>> history then we should do it.
>>>
>>> At the very least, we should print a warning message to let the
>>> administrator know he has done something that is potentially insecure.
>>>
>>>
>>> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>> It's about balance. I'm not arguing here against it, I just don't see
>>> how it could strengthen security. Nothing will stop people to get their
>>> own gun and automate it with stdin :)
>>>
>>> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>> I can be wrong, but this is not only our responsibility. For example, on
>>> Linux you are prompted for the password with passwd, but at the same
>>> time you could circumvent this using: echo 12345678 | sudo passwd admin
>>> --stdin.
>>>
>>> In this scenario security auditors won't blame the OS for this, but
>>> pretty much sysadmins and bad security practices. Anyways, whatever
>>> people think is the best, I'm fine.
>>> I agree with you there.  In that case you are doing something extra to
>>> shoot yourself in the foot.  We can't guard against that.
>>>
>>> We just shouldn't put the gun in your hand.
>>>
>>>
>>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>> I think the Jira created by Stian pretty much fixes the problem. Nope?
>>> Stian's JIRA says that if it is not specified on the command line then
>>> do the prompt.  But if we still allow setting it from the command line
>>> then the password can still be saved to the log in plain text.  Security
>>> auditors will always frown on that.
>>>
>>> So I'm saying we should either disallow setting on the command line or
>>> somehow disable saving to the log.  We shouldn't rely on an
>>> administrator to do the right thing.
>>>
>>>
>>>
>>> Something like:
>>>
>>> ./add-user-keycloak.sh -u user
>>> Password: ******
>>>
>>> Or
>>>
>>> ./add-user-keycloak-sh
>>> Username: joe
>>> Password: ******
>>>
>>> If this can't fix the issue, is also possible to disable bash_history
>>> temporarily. But I wouldn't take this route, because this is pretty much
>>> system administration responsibility.
>>>
>>>
>>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>
>>>
>>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
>>> 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.
>>>
>>> That's a mistake we'll fix that. If not specified it should prompt for
>>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>>> After attending several security talks the last couple of days, I've
>>> become rather sensitized to this kind of issue.  I feel quite strongly
>>> that we should never allow the password to be written to history in
>>> plain text.   I'm also afraid it could cause us to flunk government
>>> certifications.
>>>
>>> On Windows, this really isn't a problem because command history is not
>>> saved.  After a CMD session ends, the history is lost (unless you
>>> install some third-party tool).
>>>
>>> Perhaps there is a way to temporarily disable logging of command history
>>> in the add-user-keycloak.sh?
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> You need to set the password once for your database. This can be done
>>> prior to accessing the admin console the first time. Take a look at
>>>
>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md
>>> ,
>>> you can use docker exec to do this.
>>>
>>>
>>> --
>>> http://www.fastmail.com - Access your email from home and the web
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.orghttps://
>>> lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>> --
>>> http://www.fastmail.com - Choose from over 50 domains or use your own
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.orghttps://
>>> lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> --
>>> http://www.fastmail.com - Or how I learned to stop worrying and
>>>                           love email again
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/93bcf0d7/attachment.html 