<div dir="ltr">For now we found two ways to get a secret, with secret href or with secret URI(which is `secrets/UUID`).<div>We will turn to use <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>secret URI for now for Heat multi cloud support, but i</span>s there any reason for Barbican client not to</div><div>accept only secrets UUID (Secret incorrectly specified error will shows up when only provide UUID)?</div><div><br></div><div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 4:40 AM Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We're looking at using Barbican to implement a feature in Heat[1] and <br>
ran into some questions about how secrets are identified in the client.<br>
<br>
With most openstack clients, resources are identified by a UUID. You <br>
pass the UUID on the command line (or via the Python API or whatever) <br>
and the client combines that with the endpoint of the service obtained <br>
from the service catalog and a path to the resource type to generate the <br>
URL used to access the resource.<br>
<br>
While there appears to be no technical reason that barbicanclient <br>
couldn't also do this, instead of just the UUID it uses the full URL as <br>
the identifier for the resource. This is extremely cumbersome for the <br>
user, and invites confused-deputy attacks where if the attacker can <br>
control the URL, they can get barbicanclient to send a token to an <br>
arbitrary URL. What is the rationale for doing it this way?<br>
<br>
<br>
In a tangentially related question, since secrets are immutable once <br>
they've been uploaded, what's the best way to handle a case where you <br>
need to rotate a secret without causing a temporary condition where <br>
there is no version of the secret available? (The fact that there's no <br>
way to do this for Nova keypairs is a perpetual problem for people, and <br>
I'd anticipate similar use cases for Barbican.) I'm going to guess it's:<br>
<br>
* Create a new secret with the same name<br>
* GET /v1/secrets/?name=<name>&sort=created:desc&limit=1 to find out the <br>
URL for the newest secret with that name<br>
* Use that URL when accessing the secret<br>
* Once the new secret is created, delete the old one<br>
<br>
Should this, or whatever the actual recommended way of doing it is, be <br>
baked in to the client somehow so that not every user needs to <br>
reimplement it?<br>
<br>
<br>
Bottom line: how should Heat expect/require a user to refer to a <br>
Barbican secret in a property of a Heat resource, given that:<br>
- We don't want Heat to become the deputy in "confused deputy attack".<br>
- We shouldn't do things radically differently to the way Barbican does <br>
them, because users will need to interact with Barbican first to store <br>
the secret.<br>
- Many services will likely end up implementing integration with <br>
Barbican and we'd like them all to have similar user interfaces.<br>
- Users will need to rotate credentials without downtime.<br>
<br>
cheers,<br>
Zane.<br>
<br>
BTW the user documentation for Barbican is really hard to find. Y'all <br>
might want to look in to cross-linking all of the docs you have <br>
together. e.g. there is no link from the Barbican docs to the <br>
python-barbicanclient docs or vice-versa.<br>
<br>
[1] <a href="https://storyboard.openstack.org/#!/story/2002126" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2002126</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-7053465982646249391gmail_signature" data-smartmail="gmail_signature"><div class="m_-7053465982646249391gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="background-image:none!important"><div style="font-size:small"><div><table border="0" cellpadding="0" cellspacing="0" style="color:rgb(0,0,0);font-size:medium;font-family:verdana"><tbody><tr><td colspan="3" align="left"><span style="font-size:13px;font-family:verdana">May The Force of Open<font color="#ff0000">Stack</font> Be With You,</span> <br><b><i><font face="georgia, serif" size="4">Rico Lin<br></font></i></b>irc: ricolin</td></tr><tr><td colspan="3" align="left" style="height:10px;border-bottom-width:1px;border-bottom-style:dashed;border-bottom-color:rgb(221,221,221)"></td></tr><tr><td colspan="3"></td></tr></tbody></table><br></div></div></div><font size="2" face="tahoma, sans-serif" color="#999999"></font></div></div></div></div></div></div></div></div></div></div></div><p style="margin-right:0cm;margin-left:0cm;text-align:justify"><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:small"><img src="https://docs.google.com/uc?export=download&id=0B_UWw7JzTsWYRVNXY1hnbDVzS3M&revid=0B_UWw7JzTsWYMkhOQS8ydXk0SmRWU1gvWVhRUTBLQzdGcEpJPQ"></span><br></p><p style="margin-right:0cm;margin-left:0cm;text-align:justify"></p></a></blockquote></div></div>