<div dir="ltr">Hi Stanislav,<div>agree that unification is very useful and it is right direction.</div><div>While designing implementation changes please remember that we should serve cases:</div><div>1). There could be multiple environments served by one Fuel node. IMO we should prepare a way to have different private key per environment.</div><div>In some cases private key will be common / shared for all environments, in some cases no.</div><div>2). We should remember that there are various X.509 use cases for various OpenStack services. Usually, X.509 is used only for TLS traffic encryption. But in some cases we want to make authentication decision based on X.509 certificate.</div><div>This is useful for example with libvirt authentication, soon we'll have mechanism for X.509 Keystone authentication.</div><div>In other words: </div><div>- we should remember to have consistent naming policy for X.509 certificates storage, and there should be implemented kind of 'per service' certificate directory</div><div>- X.509 role will vary, depending on service. Sometimes only encryption, sometimes also authentication.</div><div>3). Elliptic Curve Cryptography (ECC) support even adds more complexity, as I could imagine a situation where we rely on RSA private keys for some services, and we rely on ECC private keys for others.</div><div>In fact, IMO we should always create RSA and ECC private key pair per Fuel environment, and then, in Fuel UI provide user an option which type of cryptography (RSA or ECC) use for which service.</div><div>Or take simplified approach, and during cluster provisioning 'hard code' which type of cryptography (which private key) use globally for all services.</div><div><br></div><div>Of course scope of implementation to be discussed, the whole X.509 topic is not easy one, and doing thing 'right' could be really time consuming.</div><div><br></div><div>Just my 2 cents :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 21, 2015 at 11:10 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>__________________________________________________________________________<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 class="gmail_signature"><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>