<div dir="ltr">Hi,<div><br></div><div>Changes in JS will be required anyway. Because currently it sends the data</div><div>in cluster attributes dictionary. So it should send the data to some specific url.</div><div><br></div><div>Regarding to authentication we had similar problem with diagnostic snapshot [1],</div><div>you still can perform authentication in Nailgun and then Nginx will continue to</div><div>perform the action.</div><div><br></div><div>You can get cluster's ID from nginx, it will be something like:</div><div><br></div><div> location ~ ^/api/clusters/(?<cluster_id>[0-9]+)/upload_key {<br></div><div> upload_store /var/lib/fuel/ssl_keys/$cluster_id</div><div> ....</div><div> }</div><div><br></div><div>Thanks,</div><div><br></div><div>[1] <a href="https://github.com/stackforge/fuel-specs/blob/5409aaca363dccf8e7598fc7995ce8ade1e68ebc/specs/7.0/snapshot-download-with-auth.rst#proposed-change">https://github.com/stackforge/fuel-specs/blob/5409aaca363dccf8e7598fc7995ce8ade1e68ebc/specs/7.0/snapshot-download-with-auth.rst#proposed-change</a></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 3:31 PM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I preparing patches for library, but there was raised another question: how should we saving keypairs from UI? I see there two options:<div><br></div><div>1. It will be done via UI (JS?) that will post file to special URL and then it will be saved via nginx HttpUploadModule. Caveats here:</div><div>- I don't know how we will deal with authentication. How nginx should understand that this file got from trusted source?</div><div>- As we should place keys in different places for different clusters, some handler should so it, we cannot save files with pure nginx. Who will write this handler and maintain it?</div><div><br></div><div>2. It will be done via Nailgun that will store files directly in FS. Caveats here:</div><div>- How about speed/locks? Now we store just small files with certificates (<4 kb in most of cases), but in future we, maybe, will need to save big files. Will a solution with Nailgun work okay?</div><div>- Logs. As I understand, if file will be saved by nailgun API, it will be saved in logs and we need some tool to cut it out from there.</div><div><br></div><div>So, which way seems better for you, folks?</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 21, 2015 at 1:59 PM, Adam Heczko <span dir="ltr"><<a href="mailto:aheczko@mirantis.com" target="_blank">aheczko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind of overhead if designed from the beginning.<div>If there are some HTTP authentication/CSR request/key management mechanisms already in place, of course there is no overhead.</div><div><br></div><div>Regards,</div><div><br></div><div>A.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Adam,<div><br></div><div>I'm not sure if understand you correctly, what do you mean by "<span style="font-size:12.8000001907349px">overhead for</span></div><div><span style="font-size:12.8000001907349px">certificate provisioning"? We already </span><span style="font-size:12.8000001907349px">have all the mechanisms in place in order</span></div><div><span style="font-size:12.8000001907349px">to provision certificates, the point </span><span style="font-size:12.8000001907349px">is currently with </span><span style="font-size:12.8000001907349px">user's certificates we work in</span></div><div><span style="font-size:12.8000001907349px">absolutely different way and </span><span style="font-size:12.8000001907349px">store them in </span><span style="font-size:12.8000001907349px">absolutely different place. And this</span></div><div><span style="font-size:12.8000001907349px">way leads to huge problems.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Thanks,</span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko <span dir="ltr"><<a href="mailto:aheczko@mirantis.com" target="_blank">aheczko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Evgeniy,<div>what you've proposed is all right, although it adds some overhead for certificate provisioning.</div><div>In fact, to do it right we should probably define REST API for provisioning certificates.</div><div>I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management.</div><div><br></div><div>Regards,</div><div><br></div><div>A.</div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Stanislaw,<div><br></div><div>I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes,</div><div>in this case it can be seen in all the logs, which is terrible security problem,</div><div>and we already have a place where we keep auto-generated certificates and</div><div>ssh-keys, and those are copied to specific nodes by Astute.</div><div><br></div><div>So UI should send the file to specific URL, Nginx should be configured to send auth</div><div>request to backend, after request is authorised, Nginx should save the file into predefined</div><div>directory, the same which we use for autogenerated certificates, in this case such</div><div>tool as OSTF can take certificates from a single place.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><span style="font-size:12.8000001907349px">Hi folks.</span><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Today I want to discuss the way we save SSL keys for Fuel environments. As you maybe know we have 2 ways to get a key:</div><div style="font-size:12.8000001907349px">a. Generate it by Fuel (self-signed certificate will be created in this case). In this case we will generate private key, csr and crt in a pre-deployment hook on master node and then copy keypair to the nodes which needed it.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">b. Get a pre-generated keypair from user. In this case user should create keypair by himself and then upload it through Fuel UI settings tab. In this case keypair will be saved in nailgun database and then will serialized into astute.yaml on cluster nodes, pulled from it by puppet and saved into a file.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Second way has some flaws:</div><div style="font-size:12.8000001907349px">1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause:</div><div style="font-size:12.8000001907349px">1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB.</div><div style="font-size:12.8000001907349px">1.2. It brings problems for implementation in other different places - for example, we need to get certificate for properly run OSTF tests and now we should implement two different ways to deliver that certificate to OSTF container. The same for fuel-cli - we should somehow get certificate from DB and place it in FS to use it.</div><div style="font-size:12.8000001907349px">2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this.</div><div style="font-size:12.8000001907349px">3. If keypair data serializes into astute.yaml it means than that data automatically will be fetched when diagnostic snapshot will created. So in some cases in can lead to security vulnerability, or we will must to write another crutch to cut it out of diagnostic snapshot.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">So I propose to get rid of saving keypair in nailgun database and implement a way to always saving it to local FS on master node. We need to implement next items:</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">- Change UI logic that saving keypair into DB to logic that will save it to local FS</div><div style="font-size:12.8000001907349px">- Implement according fixes in fuel-library</div></div>
<br></div></div><span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span>-- <br><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>