<div dir="ltr">That doesn&#39;t seem ideal to me as you&#39;re then &quot;hard-coding&quot; the password into the Docker image.</div><div class="gmail_extra"><br><div class="gmail_quote">On 23 February 2016 at 10:03, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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&#39;s password.</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 23, 2016 at 3:19 AM Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you have suggestions to changes/additions we can do to make it more secure feel free to let us now</div><div class="gmail_extra"><br><div class="gmail_quote">On 22 February 2016 at 16:32, Aikeaguinea <span dir="ltr">&lt;<a href="mailto:aikeaguinea@xsmail.com" target="_blank">aikeaguinea@xsmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We&#39;re essentially doing this. Since we need to secure the Wildfly admin<br>
password as well, we are basically running the add-user.sh scripts to<br>
generate the keycloak-user.json and mgmt-users.properties before running<br>
the Docker script, and then adding them to the image. This has the<br>
disadvantage of baking the passwords into the image, but at least<br>
they&#39;re encrypted and the image is stored in a secure repository, which<br>
is probably as good as we&#39;re going to get.<br>
<br>
<br>
<br>
From: &lt;<a href="mailto:keycloak-user-bounces@lists.jboss.org" target="_blank">keycloak-user-bounces@lists.jboss.org</a>&gt; on behalf of Bill Burke<br>
&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;<br>
Date: Monday, February 22, 2016 at 10:21 AM<br>
To: &quot;<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>&quot; &lt;<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>&gt;<br>
<div><div>Subject: Re: [keycloak-user] Securely setting admin passwords<br>
<br>
I&#39;m too lazy to read this entire thread, sorry if somebody already<br>
suggested this, but can&#39;t you<br>
<br>
1) Create a minimal realm in your local environment and export the realm<br>
to json.<br>
2) Import this json in your Docker script?<br>
<br>
<br>
<br>
On 2/22/2016 10:10 AM, Aikeaguinea wrote:<br>
With regard to Docker, things get more complicated. I believe it&#39;s not<br>
just the bash history but the Docker history itself that stores the<br>
commands.<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: &lt;<a href="mailto:keycloak-user-bounces@lists.jboss.org" target="_blank">keycloak-user-bounces@lists.jboss.org</a>&gt; on behalf of Stan Silvert<br>
&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;<br>
Date: Thursday, February 18, 2016 at 12:26 PM<br>
To: &quot;<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>&quot; &lt;<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>&gt;<br>
Cc: Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;, keycloak-user<br>
&lt;<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>&gt;<br>
Subject: Re: [keycloak-user] Securely setting admin passwords<br>
<br>
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:<br>
It&#39;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&#39;re not going to remove that it&#39;s<br>
required, but I do appreciate that if not used correctly it&#39;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&#39;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 &lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;<br>
wrote:<br>
It&#39;s about balance. I&#39;m not arguing here against it, I just don&#39;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 &lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;<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&#39;t blame the OS for this, but<br>
pretty much sysadmins and bad security practices. Anyways, whatever<br>
people think is the best, I&#39;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&#39;t guard against that.<br>
<br>
We just shouldn&#39;t put the gun in your hand.<br>
<br>
<br>
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert &lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;<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&#39;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&#39;m saying we should either disallow setting on the command line or<br>
somehow disable saving to the log.  We shouldn&#39;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&#39;t fix the issue, is also possible to disable bash_history<br>
temporarily. But I wouldn&#39;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 &lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;<br>
wrote:<br>
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:<br>
<br>
<br>
On 17 February 2016 at 17:09, Aikeaguinea &lt;<a href="mailto:aikeaguinea@xsmail.com" target="_blank">aikeaguinea@xsmail.com</a>&gt;<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&#39;d prefer not to use the<br>
command in its current form.<br>
<br>
That&#39;s a mistake we&#39;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&#39;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&#39;m also afraid it could cause us to flunk government<br>
certifications.<br>
<br>
On Windows, this really isn&#39;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&#39;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>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Access your email from home and the web<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">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>
<br>
<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
keycloak-user@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">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>
<br>
<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">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>
<br>
<br>
--<br>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Choose from over 50 domains or use your own<br>
<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
</div></div>keycloak-user@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<span><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
</span><span><font color="#888888">--<br>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Or how I learned to stop worrying and<br>
                          love email again<br>
</font></span><div><div><br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">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>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">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></blockquote></div>
</div></div></blockquote></div><br></div>