Re: [openstack-dev] [Solum] Nominating Zhu Rong for Solum core
+1 From: Devdatta Kulkarni Date: Wed, Sep 28, 2016 at 8:32 AM Subject: [Solum] Nominating Zhu Rong for Solum core To: openstack-dev@lists.openstack.org Hi team, I would like to propose Zhu Rong (irc: zhurong) to be included as Solum core. Zhu Rong has been very active in different parts of Solum over several months now. His primary contribution has been moving Solum to use Oslo libraries, thereby making our project satisfy one of the project-wide goals suggested by TC for this cycle [1]. He has also been deeply involved in guiding and contributing to the work on Solum's horizon dashboard, which was started by Swati Dewan as part of her Outreachy internship this summer. Zhu Rong also actively participates on Solum IRC channel, regularly attends IRC meetings, and provides great feedback on patches. You can find Zhu Rong's activity here: http://stackalytics.com/?module=solum-group&user_id=zhu-rong http://stackalytics.com/?module=solum-dashboard&user_id=zhu-rong Please respond with your votes. Regards, Devdatta [1] http://lists.openstack.org/pipermail/openstack-dev/2016-August/101348.html __ 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] [Heat]Heat template parameters encryption
Hi Devs/All,
Does any one have comments/objections for following interim solution?
1. Add a config option to enable/disable parameter encryption and set
default value to disable
2. Encrypt parameters that were marked as hidden or encrypt all parameters
IMO, when a template author marks a parameter as hidden/secret, it seems
incorrect to store that information in plain text.
Thanks,
Vijendar
On 6/5/14 11:54 AM, "Vijendar Komalla"
wrote:
>I am not sure when Barbican would be stable/ready. As an interim solution,
>what do you guys think about having a config option to enable/disable
>parameter encryption (along with my current implementation)?
>
>
>
>On 6/5/14 4:23 AM, "Steven Hardy" wrote:
>
>>On Thu, Jun 05, 2014 at 12:17:07AM +, Randall Burt wrote:
>>> On Jun 4, 2014, at 7:05 PM, Clint Byrum
>>> wrote:
>>>
>>> > Excerpts from Zane Bitter's message of 2014-06-04 16:19:05 -0700:
>>> >> On 04/06/14 15:58, Vijendar Komalla wrote:
>>> >>> Hi Devs,
>>> >>> I have submitted an WIP review
>>>(https://review.openstack.org/#/c/97900/)
>>> >>> for Heat parameters encryption blueprint
>>> >>>
>>>https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters
>>> >>> This quick and dirty implementation encrypts all the parameters on
>>>on
>>> >>> Stack 'store' and decrypts on on Stack 'load'.
>>> >>> Following are couple of improvements I am thinking about;
>>> >>> 1. Instead of encrypting individual parameters, on Stack 'store'
>>>encrypt
>>> >>> all the parameters together as a dictionary [something like
>>> >>> crypt.encrypt(json.dumps(param_dictionary))]
>>> >>
>>> >> Yeah, definitely don't encrypt them individually.
>>> >>
>>> >>> 2. Just encrypt parameters that were marked as 'hidden', instead of
>>> >>> encrypting all parameters
>>> >>>
>>> >>> I would like to hear your feedback/suggestions.
>>> >>
>>> >> Just as a heads-up, we will soon need to store the properties of
>>> >> resources too, at which point parameters become the least of our
>>> >> problems. (In fact, in theory we wouldn't even need to store
>>> >> parameters... and probably by the time convergence is completely
>>> >> implemented, we won't.) Which is to say that there's almost
>>>certainly no
>>> >> point in discriminating between hidden and non-hidden parameters.
>>> >>
>>> >> I'll refrain from commenting on whether the extra security this
>>>affords
>>> >> is worth the giant pain it causes in debugging, except to say that
>>>IMO
>>> >> there should be a config option to disable the feature (and if it's
>>> >> enabled by default, it should probably be disabled by default in
>>>e.g.
>>> >> devstack).
>>> >
>>> > Storing secrets seems like a job for Barbican. That handles the giant
>>> > pain problem because in devstack you can just tell Barbican to have
>>>an
>>> > open read policy.
>>> >
>>> > I'd rather see good hooks for Barbican than blanket encryption. I've
>>> > worked with a few things like this and they are despised and worked
>>> > around universally because of the reason Zane has expressed concern
>>>about:
>>> > debugging gets ridiculous.
>>> >
>>> > How about this:
>>> >
>>> > parameters:
>>> > secrets:
>>> >type: sensitive
>>> > resources:
>>> > sensitive_deployment:
>>> >type: OS::Heat::StructuredDeployment
>>> >properties:
>>> > config: weverConfig
>>> > server: myserver
>>> > input_values:
>>> >secret_handle: { get_param: secrets }
>>> >
>>> > The sensitive type would, on the client side, store the value in
>>>Barbican,
>>> > never in Heat. Instead it would just pass in a handle which the user
>>> > can then build policy around. Obviously this implies the user would
>>>set
>>> > up Barbican's in-instance tools to access the secrets value. But the
>>> > idea is, let Heat worry about being high performing and
>>>introspectable,
&
Re: [openstack-dev] [Heat]Heat template parameters encryption
I am not sure when Barbican would be stable/ready. As an interim solution,
what do you guys think about having a config option to enable/disable
parameter encryption (along with my current implementation)?
On 6/5/14 4:23 AM, "Steven Hardy" wrote:
>On Thu, Jun 05, 2014 at 12:17:07AM +, Randall Burt wrote:
>> On Jun 4, 2014, at 7:05 PM, Clint Byrum
>> wrote:
>>
>> > Excerpts from Zane Bitter's message of 2014-06-04 16:19:05 -0700:
>> >> On 04/06/14 15:58, Vijendar Komalla wrote:
>> >>> Hi Devs,
>> >>> I have submitted an WIP review
>>(https://review.openstack.org/#/c/97900/)
>> >>> for Heat parameters encryption blueprint
>> >>>
>>https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters
>> >>> This quick and dirty implementation encrypts all the parameters on
>>on
>> >>> Stack 'store' and decrypts on on Stack 'load'.
>> >>> Following are couple of improvements I am thinking about;
>> >>> 1. Instead of encrypting individual parameters, on Stack 'store'
>>encrypt
>> >>> all the parameters together as a dictionary [something like
>> >>> crypt.encrypt(json.dumps(param_dictionary))]
>> >>
>> >> Yeah, definitely don't encrypt them individually.
>> >>
>> >>> 2. Just encrypt parameters that were marked as 'hidden', instead of
>> >>> encrypting all parameters
>> >>>
>> >>> I would like to hear your feedback/suggestions.
>> >>
>> >> Just as a heads-up, we will soon need to store the properties of
>> >> resources too, at which point parameters become the least of our
>> >> problems. (In fact, in theory we wouldn't even need to store
>> >> parameters... and probably by the time convergence is completely
>> >> implemented, we won't.) Which is to say that there's almost
>>certainly no
>> >> point in discriminating between hidden and non-hidden parameters.
>> >>
>> >> I'll refrain from commenting on whether the extra security this
>>affords
>> >> is worth the giant pain it causes in debugging, except to say that
>>IMO
>> >> there should be a config option to disable the feature (and if it's
>> >> enabled by default, it should probably be disabled by default in
>>e.g.
>> >> devstack).
>> >
>> > Storing secrets seems like a job for Barbican. That handles the giant
>> > pain problem because in devstack you can just tell Barbican to have an
>> > open read policy.
>> >
>> > I'd rather see good hooks for Barbican than blanket encryption. I've
>> > worked with a few things like this and they are despised and worked
>> > around universally because of the reason Zane has expressed concern
>>about:
>> > debugging gets ridiculous.
>> >
>> > How about this:
>> >
>> > parameters:
>> > secrets:
>> >type: sensitive
>> > resources:
>> > sensitive_deployment:
>> >type: OS::Heat::StructuredDeployment
>> >properties:
>> > config: weverConfig
>> > server: myserver
>> > input_values:
>> >secret_handle: { get_param: secrets }
>> >
>> > The sensitive type would, on the client side, store the value in
>>Barbican,
>> > never in Heat. Instead it would just pass in a handle which the user
>> > can then build policy around. Obviously this implies the user would
>>set
>> > up Barbican's in-instance tools to access the secrets value. But the
>> > idea is, let Heat worry about being high performing and
>>introspectable,
>> > and then let Barbican worry about sensitive things.
>>
>> While certainly ideal, it doesn't solve the current problem since we
>>can't yet guarantee Barbican will even be available in a given release
>>of OpenStack. In the meantime, Heat continues to store sensitive user
>>information unencrypted in its database. Once Barbican is integrated,
>>I'd be all for changing this implementation, but until then, we do need
>>an interim solution. Sure, debugging is a pain and as developers we can
>>certainly grumble, but leaking sensitive user information because we
>>were too fussed to protect data at rest seems worse IMO. Additionally,
>>the solution as described sounds like we're imposing a pretty awkward
>>
[openstack-dev] [Heat]Heat template parameters encryption
Hi Devs, I have submitted an WIP review (https://review.openstack.org/#/c/97900/) for Heat parameters encryption blueprint https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters This quick and dirty implementation encrypts all the parameters on on Stack 'store' and decrypts on on Stack 'load'. Following are couple of improvements I am thinking about; 1. Instead of encrypting individual parameters, on Stack 'store' encrypt all the parameters together as a dictionary [something like crypt.encrypt(json.dumps(param_dictionary))] 2. Just encrypt parameters that were marked as 'hidden', instead of encrypting all parameters I would like to hear your feedback/suggestions. Thanks, Vijendar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] python-heatclient installation failing on Windows
Hi Heat developers,
On Windows platform (windows2012 and windows2008R2), I am seeing below given
error when installing python-heatclient. Did any one see this problem earlier?
c:\users\admin>pip -v install python-heatclient
Downloading/unpacking python-heatclient
Using version 0.2.6 (newest of versions: 0.2.6, 0.2.5, 0.2.4, 0.2.3, 0.2.2,
0.2.1, 0.1.0)
Downloading python-heatclient-0.2.6.tar.gz (68kB):
Downloading from URL
https://pypi.python.org/packages/source/p/python-heatclient/python-heatclient-0.2.6.tar.gz#md5=20ee4f01f41820fa879f92
5aa5cf127e (from https://pypi.python.org/simple/python-heatclient/)
...Downloading python-heatclient-0.2.6.tar.gz (68kB): 65kB downloaded
Hash of the package
https://pypi.python.org/packages/source/p/python-heatclient/python-heatclient-0.2.6.tar.gz#md5=20ee4f01f41820fa879f925
aa5cf127e (from https://pypi.python.org/simple/python-heatclient/)
(8c6b0ae8c7fb58c08053897432c8f15d) doesn't match the expected hash 20ee4f
01f41820fa879f925aa5cf127e!
Cleaning up...
Removing temporary dir
c:\users\admini~1\appdata\local\temp\2\pip_build_Administrator...
Bad md5 hash for package
https://pypi.python.org/packages/source/p/python-heatclient/python-heatclient-0.2.6.tar.gz#md5=20ee4f01f41820fa879f
925aa5cf127e (from https://pypi.python.org/simple/python-heatclient/)
Exception information:
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\pip\basecommand.py", line 134, in main
status = self.run(options, args)
File "C:\Python27\lib\site-packages\pip\commands\install.py", line 236, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle,
bundle=self.bundle)
File "C:\Python27\lib\site-packages\pip\req.py", line 1092, in prepare_files
self.unpack_url(url, location, self.is_download)
File "C:\Python27\lib\site-packages\pip\req.py", line 1238, in unpack_url
retval = unpack_http_url(link, location, self.download_cache,
self.download_dir)
File "C:\Python27\lib\site-packages\pip\download.py", line 624, in
unpack_http_url
_check_hash(download_hash, link)
File "C:\Python27\lib\site-packages\pip\download.py", line 448, in _check_hash
raise HashMismatch('Bad %s hash for package %s' % (link.hash_name, link))
HashMismatch: Bad md5 hash for package
https://pypi.python.org/packages/source/p/python-heatclient/python-heatclient-0.2.6.tar.gz#md5=20ee4f
01f41820fa879f925aa5cf127e (from
https://pypi.python.org/simple/python-heatclient/)
Before python-heatclient installation, I have installed python 2.7 from
http://www.activestate.com/activepython/downloads
Please let me know if you have any workaround for the above error.
Thanks,
Vijendar
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
