On 11/08/2013 06:07 AM, Andrew Plunk wrote:
> The problem I am trying to solve here is not to secure an output, but to
> provide the ability to only display an output to an end user one time.
>
>> So it seems that the problem you are seeking to solve is limiting access
>> to sensitive outputs. The solution mentioned above certainly narrows
>> the attack surface, but it suffers from a DOS race condition where a
>> bad actor can lock you out of your own resource.
> Also, if an attacker is able to authenticate as your account, you have much
> bigger problems than them locking you out of an output.
A non-malicious race condition would be launching your stack through
Horizon. Just clicking around will very quickly use up your one stack-show.
I would suggest either encryption like Clint suggested, or an extra
attribute to stack-show so that sensitive outputs are only returned when
explicitly asked for.
> Thanks.
> -Andrew
> ________________________________________
> From: Clint Byrum [cl...@fewbar.com]
> Sent: Wednesday, November 06, 2013 8:36 PM
> To: openstack
> Subject: Re: [Openstack] [Heat] Locked Outputs
>
> Excerpts from Andrew Plunk's message of 2013-11-07 06:48:33 +0800:
>> Hello All,
>>
>> Imagine for a minute that you are displaying outputs from heat, but some of
>> those outputs could have sensitive data (think passwords or private keys).
>> It would be beneficial to allow outputs to be accessed once, and then go
>> into a locked state. This could result in the following:
>>
> This is an interesting concept. I'd like to start with a problem
> statement though, as it is not clear what this is meant to solve.
>
>> 1). After an output is accessed for the first time, the output will become
>> locked, and subsequent calls to the engine to return that output will return
>> nothing.
>> example:
>>> show stack
>> "outputs": {
>> "password": "password"
>> }
>>
>>> show stack
>> "outputs": {
>> }
>>
>>
>> 2). Another option is after an output is accessed for the first time, the
>> output will become locked, and subsequent calls to the engine will return
>> the output with a flag saying that this output has been locked, allowing
>> whatever is consuming that output to take the necessary action.
>> example:
>>
>>> show stack
>> "outputs": {
>> "password": {
>> "value": "password",
>> "locked": false
>> }
>> }
>>
>>> show stack
>> "outputs": {
>> "password": {
>> "value": "password",
>> "locked": true
>> }
>> }
>>
>>
>> The outputs section of the template for either case would could look like:
>> outputs:
>> password:
>> value: { get_attr: [ some_resource, some_value ] }
>> description: The password
>> view_once: True
>>
> So it seems that the problem you are seeking to solve is limiting access
> to sensitive outputs. The solution mentioned above certainly narrows
> the attack surface, but it suffers from a DOS race condition where a
> bad actor can lock you out of your own resource.
>
> I have a different idea for that, which is to encrypt the output using
> public key cryptography.
>
> heat stack-create -f mytemplate.yaml -P PasswordRecipientKey="$(gpg
> --armor --print-key m...@foo.com)"
>
> And then have an output type of "Encrypted"
>
> Outputs:
> Password:
> Type: Encrypted
> Keys:
> - {Ref: PasswordRecipientKey}
>
> Now you can simply decrypt this with your local gpg key. heatclient
> could even automatically do this for you making it transparent as long
> as you have a gpg key agent running.
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
