Re: [openstack-dev] [Fuel] SSL keys saving
Hi,
Changes in JS will be required anyway. Because currently it sends the data
in cluster attributes dictionary. So it should send the data to some
specific url.
Regarding to authentication we had similar problem with diagnostic snapshot
[1],
you still can perform authentication in Nailgun and then Nginx will
continue to
perform the action.
You can get cluster's ID from nginx, it will be something like:
location ~ ^/api/clusters/(?cluster_id[0-9]+)/upload_key {
upload_store /var/lib/fuel/ssl_keys/$cluster_id
}
Thanks,
[1]
https://github.com/stackforge/fuel-specs/blob/5409aaca363dccf8e7598fc7995ce8ade1e68ebc/specs/7.0/snapshot-download-with-auth.rst#proposed-change
On Mon, Aug 24, 2015 at 3:31 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:
I preparing patches for library, but there was raised another question:
how should we saving keypairs from UI? I see there two options:
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:
- I don't know how we will deal with authentication. How nginx should
understand that this file got from trusted source?
- 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?
2. It will be done via Nailgun that will store files directly in FS.
Caveats here:
- 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?
- 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.
So, which way seems better for you, folks?
On Fri, Aug 21, 2015 at 1:59 PM, Adam Heczko ahec...@mirantis.com wrote:
Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind
of overhead if designed from the beginning.
If there are some HTTP authentication/CSR request/key management
mechanisms already in place, of course there is no overhead.
Regards,
A.
On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L e...@mirantis.com wrote:
Hi Adam,
I'm not sure if understand you correctly, what do you mean by overhead
for
certificate provisioning? We already have all the mechanisms in place
in order
to provision certificates, the point is currently with user's
certificates we work in
absolutely different way and store them in absolutely different place.
And this
way leads to huge problems.
Thanks,
On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko ahec...@mirantis.com
wrote:
Hi Evgeniy,
what you've proposed is all right, although it adds some overhead for
certificate provisioning.
In fact, to do it right we should probably define REST API for
provisioning certificates.
I'm rather for simplified approach, consisting of Shell / Puppet
scripts for certificate upload/management.
Regards,
A.
On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote:
Hi Stanislaw,
I agree that user's certificates mustn't be saved in Nailgun database,
in cluster attributes,
in this case it can be seen in all the logs, which is terrible
security problem,
and we already have a place where we keep auto-generated certificates
and
ssh-keys, and those are copied to specific nodes by Astute.
So UI should send the file to specific URL, Nginx should be configured
to send auth
request to backend, after request is authorised, Nginx should save the
file into predefined
directory, the same which we use for autogenerated certificates, in
this case such
tool as OSTF can take certificates from a single place.
Thanks,
On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin
sbogat...@mirantis.com wrote:
Hi folks.
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:
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.
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.
Second way has some flaws:
1. We already have some keys for nodes and we store them on master
node. Store keys in different places is bad, cause:
1.1. User experience - user should remember that in some cases keys
will be store in FS and in some other cases - in DB.
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
Re: [openstack-dev] [Fuel] SSL keys saving
On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library I have not been following this thread nor I do I know or understand all your requirements but I wanted to bring to your attention the fact OpenStack has a project called Barbican whose primary purpose is to safely store keys, plus it has many other features for handling keys. Key handling is tricky so rather than try to design something yourself perhaps it might make sense to leverage the Barbican work. https://wiki.openstack.org/wiki/Barbican/Incubation http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/ http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack -- John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
I preparing patches for library, but there was raised another question: how should we saving keypairs from UI? I see there two options: 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: - I don't know how we will deal with authentication. How nginx should understand that this file got from trusted source? - 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? 2. It will be done via Nailgun that will store files directly in FS. Caveats here: - 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? - 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. So, which way seems better for you, folks? On Fri, Aug 21, 2015 at 1:59 PM, Adam Heczko ahec...@mirantis.com wrote: Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind of overhead if designed from the beginning. If there are some HTTP authentication/CSR request/key management mechanisms already in place, of course there is no overhead. Regards, A. On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L e...@mirantis.com wrote: Hi Adam, I'm not sure if understand you correctly, what do you mean by overhead for certificate provisioning? We already have all the mechanisms in place in order to provision certificates, the point is currently with user's certificates we work in absolutely different way and store them in absolutely different place. And this way leads to huge problems. Thanks, On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko ahec...@mirantis.com wrote: Hi Evgeniy, what you've proposed is all right, although it adds some overhead for certificate provisioning. In fact, to do it right we should probably define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement
Re: [openstack-dev] [Fuel] SSL keys saving
Hi John, I agree, that we didn't have these problems if we used Barbican and looks like it's a good tool for our needs. But since we are in Hard Code Freeze we should fix it somehow without introducing big changes in our current architecture. But it would be a nice to see it as an improvement in 8.0 release. Thanks, On Mon, Aug 24, 2015 at 3:57 PM, John Dennis jden...@redhat.com wrote: On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library I have not been following this thread nor I do I know or understand all your requirements but I wanted to bring to your attention the fact OpenStack has a project called Barbican whose primary purpose is to safely store keys, plus it has many other features for handling keys. Key handling is tricky so rather than try to design something yourself perhaps it might make sense to leverage the Barbican work. https://wiki.openstack.org/wiki/Barbican/Incubation http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/ http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack -- John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
We could certainly use the pre-existing Barbican capabilities, which would provide a reasonably easy and clean interface for key storage. However, this does not afford much (if any) additional security without the introduction of a Hardware Security Module as the Barbican back-end, and I’m not sure what the cost is of deploying Barbican (would this be on the fuel-master as well? Isn’t it getting crowded in there?). Barbican currently has an integration available for a SafeNet Luna HSM, which runs in the tens of thousands per device, so I don’t think it’s reasonable to expect to use this for each customer environment (although long-term we should be looking to provide a full/secure solution to customers). Sheena *From:* Evgeniy L [mailto:e...@mirantis.com] *Sent:* Monday, August 24, 2015 6:48 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel] SSL keys saving Hi John, I agree, that we didn't have these problems if we used Barbican and looks like it's a good tool for our needs. But since we are in Hard Code Freeze we should fix it somehow without introducing big changes in our current architecture. But it would be a nice to see it as an improvement in 8.0 release. Thanks, On Mon, Aug 24, 2015 at 3:57 PM, John Dennis jden...@redhat.com wrote: On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library I have not been following this thread nor I do I know or understand all your requirements but I wanted to bring to your attention the fact OpenStack has a project called Barbican whose primary purpose is to safely store keys, plus it has many other features for handling keys. Key handling is tricky so rather than try to design something yourself perhaps it might make sense to leverage the Barbican work. https://wiki.openstack.org/wiki/Barbican/Incubation http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/ http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack -- John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
Hi Evgeniy, what you've proposed is all right, although it adds some overhead for certificate provisioning. In fact, to do it right we should probably define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
Hi Adam, I'm not sure if understand you correctly, what do you mean by overhead for certificate provisioning? We already have all the mechanisms in place in order to provision certificates, the point is currently with user's certificates we work in absolutely different way and store them in absolutely different place. And this way leads to huge problems. Thanks, On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko ahec...@mirantis.com wrote: Hi Evgeniy, what you've proposed is all right, although it adds some overhead for certificate provisioning. In fact, to do it right we should probably define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind of overhead if designed from the beginning. If there are some HTTP authentication/CSR request/key management mechanisms already in place, of course there is no overhead. Regards, A. On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L e...@mirantis.com wrote: Hi Adam, I'm not sure if understand you correctly, what do you mean by overhead for certificate provisioning? We already have all the mechanisms in place in order to provision certificates, the point is currently with user's certificates we work in absolutely different way and store them in absolutely different place. And this way leads to huge problems. Thanks, On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko ahec...@mirantis.com wrote: Hi Evgeniy, what you've proposed is all right, although it adds some overhead for certificate provisioning. In fact, to do it right we should probably define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Fuel] SSL keys saving
Hi Stanislav, agree that unification is very useful and it is right direction. While designing implementation changes please remember that we should serve cases: 1). There could be multiple environments served by one Fuel node. IMO we should prepare a way to have different private key per environment. In some cases private key will be common / shared for all environments, in some cases no. 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. This is useful for example with libvirt authentication, soon we'll have mechanism for X.509 Keystone authentication. In other words: - we should remember to have consistent naming policy for X.509 certificates storage, and there should be implemented kind of 'per service' certificate directory - X.509 role will vary, depending on service. Sometimes only encryption, sometimes also authentication. 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. 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. Or take simplified approach, and during cluster provisioning 'hard code' which type of cryptography (which private key) use globally for all services. 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. Just my 2 cents :) On Fri, Aug 21, 2015 at 11:10 AM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
Hi, I absolutely agree with all points mentioned below. Especially about security, because for now, as I know, we have not any mechanisms to cut out certs and keys from snapshots. And as OSTF developer I'll be very grateful if there will be one way to get certificates from the container. On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Alex __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] SSL keys saving
Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. 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: 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. 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. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 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. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 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. 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: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
