Re: [openstack-dev] [oslo.config] Encrypt the sensitive options
I think there is a little misunderstanding over here, the key point about this problem is that you store your password as *plaintext* in the configuration file, maybe this password is also the password of many other systems. You can't stop the right person to do the right thing, if someone gets the encryped password, and he can also get into the box, then he is the right person, just like somebody gets your password through "brute force" attack, you can't stop him to do the right thing. If someone gets the entryped password, but he can not get into the box, he can do nothing, and this is our goal. So I think split the global configuration file to "general" and "secure" files, and encrypt the secure file is the right way to do this. 2016-04-26 16:05 GMT-05:00 Doug Hellmann : > Excerpts from Morgan Fainberg's message of 2016-04-26 10:17:30 -0500: > > On Tue, Apr 26, 2016 at 9:24 AM, Jordan Pittier < > jordan.pitt...@scality.com> > > wrote: > > > > > > > > > > > On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange < > berra...@redhat.com> > > > wrote: > > > > > >> On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote: > > >> > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500: > > >> > > Hello, oslo team > > >> > > > > >> > > For now, some sensitive options like password or token are > configured > > >> as > > >> > > plaintext, anyone who has the priviledge to read the configure > file > > >> can get > > >> > > the real password, this may be a security problem that can't be > > >> > > unacceptable for some people. > > >> > > > It's not a security problem if your config files have the proper > > > permissions. > > > > > > > > >> > > > > >> > > So the first solution comes to my mind is to encrypt these options > > >> when > > >> > > configuring them and decrypt them when reading them in > oslo.config. > > >> This is > > >> > > a bit like apache/openldap did, but the difference is these > softwares > > >> do a > > >> > > salt hash to the password, this is a one-way encryption that > can't be > > >> > > decrypted, these softwares can recognize the hashed value. But if > we > > >> do > > >> > > this work in oslo.config, for example the admin_password in > > >> > > keystone_middleware section, we must feed the keystone with the > > >> plaintext > > >> > > password which will be hashed in keystone to compare with the > stored > > >> hashed > > >> > > password, thus the encryped value in oslo.config must be decryped > to > > >> > > plaintext. So we should encrypt these options using symmetrical or > > >> > > unsymmetrical method with a key, and put the key in a well secured > > >> place, > > >> > > and decrypt them using the same key when reading them. > > >> > > > The issue here is to find a "well secured place". We should not only > move > > > the problem somewhere else. > > > > > > > > >> > > > > >> > > Of course, this feature should be default closed. Any ideas? > > >> > > > >> > Managing the encryption keys has always been the issue blocking > > >> > implementing this feature when it has come up in the past. We can't > have > > >> > oslo.config rely on a separate OpenStack service for key management, > > >> > because presumably that service would want to use oslo.config and > then > > >> > we have a dependency cycle. > > >> > > > >> > So, we need a design that lets us securely manage those encryption > keys > > >> > before we consider adding encryption. If we solve that, it's then > > >> > probably simpler to encrypt an entire config file instead of > worrying > > >> > about encrypting individual values (something like how ansible vault > > >> > works). > > >> > > >> IMHO encrypting oslo config files is addressing the wrong problem. > > >> Rather than having sensitive passwords stored in the main config > > >> files, we should have them stored completely separately by a secure > > >> password manager of some kind. The config file would then merely > > >> contain the name or uuid of an entry in the password manager. The > > >> service (eg nova-compute) would then query that password manager > > >> to get the actual sensitive password data it requires. At this point > > >> oslo.config does not need to know/care about encryption of its data > > >> as there's no longer sensitive data stored. > > >> > > > This looks complicated. I like text files that I can quickly view and > > > edit, if I am authorized to (through good old plain Linux permissions). > > > > > > > > >> > > >> Regards, > > >> Daniel > > >> > > > > > oslo.config already supports multiple configuration files. As long as the > > configuration sections are appropriately combined (they should be? if not > > there is a gap), we can rely on that feature to handle the split between > > "secure" options and "general options". I am strongly against encrypting > > the whole file (it doesn't really solve the problem that well). There is > a > > Yes, sorry, I wasn't clear but I assumed this was understood to be how we > would do it -- have
Re: [openstack-dev] [oslo.config] Encrypt the sensitive options
2016-04-26 10:33 GMT-05:00 Daniel P. Berrange : > On Tue, Apr 26, 2016 at 04:24:52PM +0200, Jordan Pittier wrote: > > On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange > > > wrote: > > > > > On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote: > > > > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500: > > > > > Hello, oslo team > > > > > > > > > > For now, some sensitive options like password or token are > configured > > > as > > > > > plaintext, anyone who has the priviledge to read the configure file > > > can get > > > > > the real password, this may be a security problem that can't be > > > > > unacceptable for some people. > > > > > It's not a security problem if your config files have the proper > > permissions. > > Permissions on disk is only one of many problems with storing passwords > in config files. When people report bugs to upstream or vendors they > frequently have to provide their configuration files as attachments to > the bug. This easily compromises their passwords unless they remember > to scrub them before attaching to the bug, which experiance shows most > people forgot todo. We've had countless issues with code inside openstack > logging variables which contain passwords, causing us to come up with > stupid hacks to try to scrub passwords before logging. If you want to > change your database password, you now forced to update the config > files on 100's or 1000's of nodes. Sure mgmt tools can automate this > but it would be better if the problem didn't exist in the first place > > > > > > So the first solution comes to my mind is to encrypt these options > when > > > > > configuring them and decrypt them when reading them in oslo.config. > > > This is > > > > > a bit like apache/openldap did, but the difference is these > softwares > > > do a > > > > > salt hash to the password, this is a one-way encryption that can't > be > > > > > decrypted, these softwares can recognize the hashed value. But if > we do > > > > > this work in oslo.config, for example the admin_password in > > > > > keystone_middleware section, we must feed the keystone with the > > > plaintext > > > > > password which will be hashed in keystone to compare with the > stored > > > hashed > > > > > password, thus the encryped value in oslo.config must be decryped > to > > > > > plaintext. So we should encrypt these options using symmetrical or > > > > > unsymmetrical method with a key, and put the key in a well secured > > > place, > > > > > and decrypt them using the same key when reading them. > > > > > The issue here is to find a "well secured place". We should not only move > > the problem somewhere else. > > There is already barbican which could potentially fill that role: > > "Barbican is a REST API designed for the secure storage, provisioning >and management of secrets such as passwords, encryption keys and X.509 >Certificates." [1] > > On startup a process, such as nova, could contact barbican to retrieve > the credentials it should use for authenticating with each other service > that requires a password. > Barbican is designed for tenancy, right? And it must configure the keystone_authtoken related options to work with keystone, and this will have a dependency problem as Doug mentioned. > > > > > > > > > > Of course, this feature should be default closed. Any ideas? > > > > > > > > Managing the encryption keys has always been the issue blocking > > > > implementing this feature when it has come up in the past. We can't > have > > > > oslo.config rely on a separate OpenStack service for key management, > > > > because presumably that service would want to use oslo.config and > then > > > > we have a dependency cycle. > > > > > > > > So, we need a design that lets us securely manage those encryption > keys > > > > before we consider adding encryption. If we solve that, it's then > > > > probably simpler to encrypt an entire config file instead of worrying > > > > about encrypting individual values (something like how ansible vault > > > > works). > > > > > > IMHO encrypting oslo config files is addressing the wrong problem. > > > Rather than having sensitive passwords stored in the main config > > > files, we should have them stored completely separately by a secure > > > password manager of some kind. The config file would then merely > > > contain the name or uuid of an entry in the password manager. The > > > service (eg nova-compute) would then query that password manager > > > to get the actual sensitive password data it requires. At this point > > > oslo.config does not need to know/care about encryption of its data > > > as there's no longer sensitive data stored. > > > > This looks complicated. I like text files that I can quickly view and > edit, > > if I am authorized to (through good old plain Linux permissions). > > As explained earlier, passwords in text files is awful for both security > and managability at a large scale. File permissions alone cannot
[openstack-dev] [oslo.config] Encrypt the sensitive options
Hello, oslo team For now, some sensitive options like password or token are configured as plaintext, anyone who has the priviledge to read the configure file can get the real password, this may be a security problem that can't be unacceptable for some people. So the first solution comes to my mind is to encrypt these options when configuring them and decrypt them when reading them in oslo.config. This is a bit like apache/openldap did, but the difference is these softwares do a salt hash to the password, this is a one-way encryption that can't be decrypted, these softwares can recognize the hashed value. But if we do this work in oslo.config, for example the admin_password in keystone_middleware section, we must feed the keystone with the plaintext password which will be hashed in keystone to compare with the stored hashed password, thus the encryped value in oslo.config must be decryped to plaintext. So we should encrypt these options using symmetrical or unsymmetrical method with a key, and put the key in a well secured place, and decrypt them using the same key when reading them. Of course, this feature should be default closed. Any ideas? __ 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] [Glance] Policy
I think you should restart the glance-api, because it will not reload the
policy.json like others.
2014-05-28 22:05 GMT+08:00 André Aranha :
> Hello,
> I have a question in Glance about its policy, I'm setting it to deny
> all calls to images.list ("get_image": "!", "get_images": "!",) but it
> doesn't work, I tried this on keystone and worked fine, but on glance it
> ignores the change I made to the policy.
> Does anyone knows if glance code is enforcing the rules in policy?
>
> Thank you,
> Andre Aranha
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
索广宇(Guangyu Suo)
UnitedStack Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][ceilometer] About Grouping Meters
2013/8/8 Julien Danjou > On Thu, Aug 08 2013, Guangyu Suo wrote: > > > Any ideas ? > > The meter name should be sufficient to have such information, no? > Yeah, we can get the info from meter name by filtering prefix of meter name, but I think this is a little weird, and further more, for the user-defined meter, is it a good way to make people to add a specified prefix of their meter name? And if people or other service didn't give the meter prefix, how can we distinguish them? > > -- > Julien Danjou > # Free Software hacker # freelance consultant > # http://julien.danjou.info > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack][ceilometer] About Grouping Meters
Hello, Ceilometer Team, For now, the results listing meters are not grouped, even we can filter the results by resource_id, project_id or meter_name, but I don't think this is a good way to group the meters. See an example: suo@ustack:~/devstack$ ceilometer meter-list ++---+---+--+-+--+ | Name | Type | Unit | Resource ID | User ID | Project ID | ++---+---+--+-+--+ | image | gauge | image | 3e43b8f4-b347-42a4-b189-931fff9538f3 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image | gauge | image | 838f5bce-ce46-4241-88ba-d6bd1c267bf8 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image | gauge | image | b5fbf186-02fa-4279-a918-d71e6abd7020 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.size | gauge | B | 3e43b8f4-b347-42a4-b189-931fff9538f3 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.size | gauge | B | 838f5bce-ce46-4241-88ba-d6bd1c267bf8 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.size | gauge | B | b5fbf186-02fa-4279-a918-d71e6abd7020 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.update | delta | image | 3e43b8f4-b347-42a4-b189-931fff9538f3 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.update | delta | image | 838f5bce-ce46-4241-88ba-d6bd1c267bf8 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.update | delta | image | b5fbf186-02fa-4279-a918-d71e6abd7020 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.upload | delta | image | 3e43b8f4-b347-42a4-b189-931fff9538f3 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.upload | delta | image | 838f5bce-ce46-4241-88ba-d6bd1c267bf8 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | image.upload | delta | image | b5fbf186-02fa-4279-a918-d71e6abd7020 | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | storage.objects| gauge | object| 27ffe3121d4b49c19ebb51548ee7ea88 | None| 27ffe3121d4b49c19ebb51548ee7ea88 | | storage.objects| gauge | object| 2dc999e8e61e43748d3eb5c02b878fe1 | None| 2dc999e8e61e43748d3eb5c02b878fe1 | | storage.objects| gauge | object| 421212a8b3cb43da9eeae077f59c4e40 | None| 421212a8b3cb43da9eeae077f59c4e40 | .. | storage.objects.size | gauge | B | 4a0d19f2e025447ea8567a0ccaf2f74a | None| 4a0d19f2e025447ea8567a0ccaf2f74a | | storage.objects.size | gauge | B | 61e13fab30f9493b814321e6684936a4 | None| 61e13fab30f9493b814321e6684936a4 | | storage.objects.size | gauge | B | b03b0bfc3ccb4dd98d4ad03c6d32e1be | None| b03b0bfc3ccb4dd98d4ad03c6d32e1be | | storage.objects.size | gauge | B | f22454605f2d498fad0b2b5520fba349 | None| f22454605f2d498fad0b2b5520fba349 | ++---+---+--+-+--+ I think this result will confuse users more or little, which meters come from compute service, and which meters come from network service, or can I get all the meters coming from storage service ? So I think the grouping by services will make users more clear about what they have got, and it is also usefull to display them on dashboard. In addition, there is a glossary named 'source' in ceilometer, but I don't think that is the same thing with grouping. So if we can add a field named service/group/namespace to the meter table, that will make the whole world clear. Any ideas ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer][devstack] What are ceilometer/bin/* files used for ?
OK, thanks, Julien, that is what I actually do. 2013/7/17 Julien Danjou > On Wed, Jul 17 2013, Guangyu Suo wrote: > > > # Support potential entry-points console scripts > > if [[ -d $CEILOMETER_DIR/bin ]]; then > > CEILOMETER_BIN_DIR=$CEILOMETER_DIR/bin > > else > > CEILOMETER_BIN_DIR=$(get_python_exec_prefix) > > fi > > > > so, can we move the files to somewhere else, and remove the bin/ > directory > > just like nova does? > > We can't because at least one of the bin script is from Oslo. OTOH, you > can just set CEILOMETER_BIN_DIR=$(get_python_exec_prefix) and that'll be > ok. > > -- > Julien Danjou > /* Free Software hacker * freelance consultant >http://julien.danjou.info */ > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer][devstack] What are ceilometer/bin/* files used for ?
Hi, ceilometer stackers I notice that there are two files (ceilometer-rpc-zmq-receiver, ceilometer-send-counter) in ceilometer/bin directory, when and where we should use them, and why we put them there ? The reason I ask this question is that I want to add mysql support in devstack for ceilometer, but when I executed $CEILOMETER_BIN_DIR/ceilometer-dbsync command, it reported "No such File". It is because the following code cause the problem, which results CEILOMETER_BIN_DIR get the wrong directory: # Support potential entry-points console scripts if [[ -d $CEILOMETER_DIR/bin ]]; then CEILOMETER_BIN_DIR=$CEILOMETER_DIR/bin else CEILOMETER_BIN_DIR=$(get_python_exec_prefix) fi so, can we move the files to somewhere else, and remove the bin/ directory just like nova does? The ceilometer-mysql-support path is https://review.openstack.org/#/c/37413/ Thanks ! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer] Is there need to implement CloudWatch compatible API for Ceilometer?
Hi, all Since ceilometer is becoming stronger at monitoring side, more and more companies will use ceilometer as their monitoring service, and AWS CloudWatch API is more general for monitoring service, so I am wondering whether there is need to implement CloudWatch compatible API to make ceilometer more general. If so, I'd like to do my effort. Thanks ! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
