<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2016 at 15:24, Aikeaguinea <span dir="ltr"><<a href="mailto:aikeaguinea@xsmail.com" target="_blank">aikeaguinea@xsmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd be happy with KEYCLOAK-2501 (accepting the password on the command<br>
line). Then the docker exec approach wouldn't expose the password; this<br>
is essentially the approach I started with before I ran into the issue<br>
with the -p switch. (It would be equally desirable to have the same<br>
change for add-user --container for the Wildfly password; should I open<br>
a JIRA with Wildfly about this, or would the implementation of<br>
KEYCLOAK-2501 require the corresponding modification in Wildfly anyway?)<br></blockquote><div><br></div><div>WildFly already supports prompting for the password</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Mounting the file via volume was something we looked into. We're setting<br>
things up in Amazon's Elastic Container Service, which uses autoscaling<br>
groups to bring up new instances automatically (though we don't think<br>
we'll really need that aspect of it all that much). My recollection is<br>
that the setup involved didn't seem worth the trouble because our Docker<br>
image is in a secure repository anyway. If we have to store the file<br>
someplace, might as well just copy it into the container and keep it in<br>
the image; at least that was the thinking. For people who put their<br>
images on a public registry this wouldn't be a good solution.<br>
<br>
<br>
From: <<a href="mailto:keycloak-user-bounces@lists.jboss.org">keycloak-user-bounces@lists.jboss.org</a>> on behalf of Marek Posolda<br>
<<a href="mailto:mposolda@redhat.com">mposolda@redhat.com</a>><br>
Date: Tuesday, February 23, 2016 at 4:37 AM<br>
To: "<a href="mailto:stian@redhat.com">stian@redhat.com</a>" <<a href="mailto:stian@redhat.com">stian@redhat.com</a>>, Aikeaguinea<br>
<<a href="mailto:aikeaguinea@xsmail.com">aikeaguinea@xsmail.com</a>><br>
Cc: keycloak-user <<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div><div class="h5">Subject: Re: [keycloak-user] Securely setting admin passwords<br>
<br>
Another possibility is to share the file keycloak-user.json with docker<br>
via volume. Then it's not hardcoded into the Docker image. The<br>
entrypoint script can check if the file shared through volume exists and<br>
copy it to standalone/configuration in that case.<br>
<br>
Marek<br>
<br>
On 23/02/16 10:10, Stian Thorgersen wrote:<br>
<br>
<br>
On 22 February 2016 at 16:10, Aikeaguinea <<a href="mailto:aikeaguinea@xsmail.com">aikeaguinea@xsmail.com</a>><br>
wrote:<br>
With regard to Docker, things get more complicated. I believe it's not<br>
just the bash history but the Docker history itself that stores the<br>
commands.<br>
<br>
What about "docker exec" approach? We've fixed it in 1.9.0.Final so that<br>
it'll now prompt for a password if one isn't specified.<br>
<br>
<br>
Also, per one of the messages earlier on this chain, it is not advised<br>
to put secrets into Docker environment variables. These are accessible<br>
in many different ways.<br>
<br>
From: <<a href="mailto:keycloak-user-bounces@lists.jboss.org">keycloak-user-bounces@lists.jboss.org</a>> on behalf of Stan Silvert<br>
<<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>><br>
Date: Thursday, February 18, 2016 at 12:26 PM<br>
To: "<a href="mailto:stian@redhat.com">stian@redhat.com</a>" <<a href="mailto:stian@redhat.com">stian@redhat.com</a>><br>
Cc: Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>>, keycloak-user<br>
<<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
Subject: Re: [keycloak-user] Securely setting admin passwords<br>
<br>
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:<br>
It's security vs usability as usual. Allowing passing the password<br>
directly is convenient for developers, for Docker image, for<br>
provisioning tools, etc.. So we're not going to remove that it's<br>
required, but I do appreciate that if not used correctly it's a<br>
potential security risk. The worst case scenario here is really that<br>
someone gets an admins favorite password, as someone that has access to<br>
getting the bash history of that particular user will also be able to<br>
run the add-user script themselves. So if the admin wants to print his<br>
favorite password in clear text in the bash history we should not stop<br>
him.<br>
<br>
It's not our responsibility to clear the bash history, so we should not<br>
do that either.<br>
If there is a way to stop that one command from being saved in the bash<br>
history then we should do it.<br>
<br>
At the very least, we should print a warning message to let the<br>
administrator know he has done something that is potentially insecure.<br>
<br>
<br>
On 18 February 2016 at 16:53, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>><br>
wrote:<br>
It's about balance. I'm not arguing here against it, I just don't see<br>
how it could strengthen security. Nothing will stop people to get their<br>
own gun and automate it with stdin :)<br>
<br>
On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>><br>
wrote:<br>
On 2/18/2016 9:29 AM, Bruno Oliveira wrote:<br>
I can be wrong, but this is not only our responsibility. For example, on<br>
Linux you are prompted for the password with passwd, but at the same<br>
time you could circumvent this using: echo 12345678 | sudo passwd admin<br>
--stdin.<br>
<br>
In this scenario security auditors won't blame the OS for this, but<br>
pretty much sysadmins and bad security practices. Anyways, whatever<br>
people think is the best, I'm fine.<br>
I agree with you there. In that case you are doing something extra to<br>
shoot yourself in the foot. We can't guard against that.<br>
<br>
We just shouldn't put the gun in your hand.<br>
<br>
<br>
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>><br>
wrote:<br>
On 2/18/2016 9:10 AM, Bruno Oliveira wrote:<br>
I think the Jira created by Stian pretty much fixes the problem. Nope?<br>
Stian's JIRA says that if it is not specified on the command line then<br>
do the prompt. But if we still allow setting it from the command line<br>
then the password can still be saved to the log in plain text. Security<br>
auditors will always frown on that.<br>
<br>
So I'm saying we should either disallow setting on the command line or<br>
somehow disable saving to the log. We shouldn't rely on an<br>
administrator to do the right thing.<br>
<br>
<br>
<br>
Something like:<br>
<br>
./add-user-keycloak.sh -u user<br>
Password: ******<br>
<br>
Or<br>
<br>
./add-user-keycloak-sh<br>
Username: joe<br>
Password: ******<br>
<br>
If this can't fix the issue, is also possible to disable bash_history<br>
temporarily. But I wouldn't take this route, because this is pretty much<br>
system administration responsibility.<br>
<br>
<br>
On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <<a href="mailto:ssilvert@redhat.com">ssilvert@redhat.com</a>><br>
wrote:<br>
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:<br>
<br>
<br>
On 17 February 2016 at 17:09, Aikeaguinea <<a href="mailto:aikeaguinea@xsmail.com">aikeaguinea@xsmail.com</a>><br>
wrote:<br>
It seems the add-user.sh script for changing the admin password only<br>
accepts the password as a -p command-line parameter. This would expose<br>
the password in the command history, so I'd prefer not to use the<br>
command in its current form.<br>
<br>
That's a mistake we'll fix that. If not specified it should prompt for<br>
it. Added <a href="https://issues.jboss.org/browse/KEYCLOAK-2501" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2501</a><br>
After attending several security talks the last couple of days, I've<br>
become rather sensitized to this kind of issue. I feel quite strongly<br>
that we should never allow the password to be written to history in<br>
plain text. I'm also afraid it could cause us to flunk government<br>
certifications.<br>
<br>
On Windows, this really isn't a problem because command history is not<br>
saved. After a CMD session ends, the history is lost (unless you<br>
install some third-party tool).<br>
<br>
Perhaps there is a way to temporarily disable logging of command history<br>
in the add-user-keycloak.sh?<br>
<br>
<br>
<br>
<br>
Is there another way to do this?<br>
<br>
The situation is even more complicated with Docker, since running the<br>
script to change the Wildfly admin password requires restarting the<br>
server, which shuts down the container. If you have an autoscaling<br>
group, the container that gets brought up is not the container where you<br>
changed the password, but instead the original container. This seems to<br>
mean that the only way to have Keycloak run in Dockers in an autoscaling<br>
group is to bake the admin passwords into the Docker image beforehand.<br>
This isn't ideal; less so if the only way to add those passwords during<br>
build time is to run the shell script that exposes the password on the<br>
command line.<br>
<br>
You need to set the password once for your database. This can be done<br>
prior to accessing the admin console the first time. Take a look at<br>
<a href="https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md" rel="noreferrer" target="_blank">https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md</a>,<br>
you can use docker exec to do this.<br>
<br>
<br>
--<br>
</div></div><a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Faster than the air-speed velocity of an<br>
unladen european swallow<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div></div>