[keycloak-user] Securely setting admin passwords
Marek Posolda
mposolda at redhat.com
Tue Feb 23 04:37:07 EST 2016
Another possibility is to share the file keycloak-user.json with docker
via volume. Then it's not hardcoded into the Docker image. The
entrypoint script can check if the file shared through volume exists and
copy it to standalone/configuration in that case.
Marek
On 23/02/16 10:10, Stian Thorgersen wrote:
>
>
> On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea at xsmail.com
> <mailto:aikeaguinea at xsmail.com>> 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.
>
>
> What about "docker exec" approach? We've fixed it in 1.9.0.Final so
> that it'll now prompt for a password if one isn't specified.
>
> 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 <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
> 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/19205d2e/attachment-0001.html
More information about the keycloak-user
mailing list