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: 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
