[keycloak-user] Securely setting admin passwords
Bill Burke
bburke at redhat.com
Mon Feb 22 10:21:08 EST 2016
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
> <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Stan
> Silvert <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
> *Date: *Thursday, February 18, 2016 at 12:26 PM
> *To: *"stian at redhat.com <mailto:stian at redhat.com>" <stian at redhat.com
> <mailto:stian at redhat.com>>
> *Cc: *Stian Thorgersen <sthorger at redhat.com
> <mailto:sthorger at redhat.com>>, keycloak-user
> <keycloak-user at lists.jboss.org <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>>>> <mailto: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
>>>>> <http://www.fastmail.com/> - Access your email
>>>>> from home and the web
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> <mailto: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
>>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto: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.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/d2a2c976/attachment-0001.html
More information about the keycloak-user
mailing list