<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>I just spoke with Dolph and he suggested an option that seems to solve the problem.</div><div><br></div><div>In Keystone, projects that belong to domains (or other projects as the hierarchy work moves forward) can be marked as Private, which will prevent any role inheritance for users higher in the hierarchy.</div><div><br></div><div>This seems to solve the stated use case? </div><div><br></div><div>Arvind - does this work for you?</div><div><br></div><div><br></div><div>Thanks,</div><div>Jarret</div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Jarret Raim <<a href="mailto:jarret.raim@rackspace.com">jarret.raim@rackspace.com</a>><br><span style="font-weight:bold">Reply-To: </span> OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span> Thursday, May 15, 2014 at 11:40 AM<br><span style="font-weight:bold">To: </span> OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Cc: </span> "Chan, Tim" <<a href="mailto:tim.w.chan@hp.com">tim.w.chan@hp.com</a>>, "Jones, Brant" <<a href="mailto:Brant.Jones@hp.com">Brant.Jones@hp.com</a>>, Morgan Fainberg <<a href="mailto:m@metacloud.com">m@metacloud.com</a>>, "Thyne, Bob" <<a href="mailto:bob.thyne@hp.com">bob.thyne@hp.com</a>><br><span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [keystone] [barbican] Protecting user specific secrets in Barbican<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>So let me try to summarize our conversations from yesterday. </div><div><br></div><div>=== Use Case ===</div><div>Assume we have a Domain D which contains a large number of individual users. Each user in the domain creates a public / private key. This key pair is later used to establish authentication to services, some not from OpenStack. </div><div><br></div><div>=== Challenge ===</div><div>All the user specific projects belong to the D Domain. This means that any user with read permissions on the domain will be able to access the user specific secrets. As it seems likely that many users will be given domain read permissions, this violates
 least privilege by allowing a large number of users access to secret data that they don't need.</div><div><br></div><div>=== Initial Proposal ===</div><div>The original proposal was to scope secrets to a composite key of the project id and the user id from the user who created the secret. There is some concern from both Keystone and Barbican members that this approach violates the base assumption that, in
 OpenStack, the lowest level of authorization is a project.</div><div><br></div><div>=== Open Question ===</div><div>My current thinking is that since these keys are user specific and Keystone owns the user resource in OpenStack, it is starting to feel like this type of data should more properly be owned by the Keystone service rather than Barbican. Of course, Keystone
 could use Barbican for backend storage if desired.</div><div><br></div><div><br></div><div>I'd really like to get some feedback from the Keystone folks on how they think about this one as, more and more, it's feeling like a problem that Barbican shouldn't solve. </div><div><br></div><div><br></div><div>Thanks,</div><div>Jarret</div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span><Tiwari>, Arvind <<a href="mailto:arvind.tiwari@hp.com">arvind.tiwari@hp.com</a>><br><span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span>Thursday, May 15, 2014 at 8:21 AM<br><span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Cc: </span>"Jones, Brant" <<a href="mailto:Brant.Jones@hp.com">Brant.Jones@hp.com</a>>, "Chan, Tim" <<a href="mailto:tim.w.chan@hp.com">tim.w.chan@hp.com</a>>, "Thyne, Bob" <<a href="mailto:bob.thyne@hp.com">bob.thyne@hp.com</a>>,
 Morgan Fainberg <<a href="mailto:m@metacloud.com">m@metacloud.com</a>><br><span style="font-weight:bold">Subject: </span>[openstack-dev] [keystone] [barbican] Protecting user specific secrets in Barbican<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><meta name="Generator" content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:773137154;
        mso-list-type:hybrid;
        mso-list-template-ids:-1247793554 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l1
        {mso-list-id:790247198;
        mso-list-type:hybrid;
        mso-list-template-ids:-1700759950 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal">Barbcan will be used as secret store (or Key Manager) in Open Stack deployments. That means users can store any kind for secrets (ssh keys , access keys, password …..) in Barbican these secrets are not shared secrets.
<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">In below scenario it seems secrets are not well protected in Barbican<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span style="mso-list:Ignore">1.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->Barbican in integrated a OS based cloud deployment.<o:p></o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span style="mso-list:Ignore">2.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->In particular domain there is one (or multiple) project.<o:p></o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span style="mso-list:Ignore">3.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->Users are associated with the project through role (two coworker can have same role e.g. creator) or a admin user have higher role.<o:p></o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span style="mso-list:Ignore">4.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->Users have their secrets (ssh keys , access keys, password …..) for services (VMs per users, resources) saved in Barbican.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Problem<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">1.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->Users with the same role or Admin on project can see each other secrets which are not a shared secrets.<o:p></o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">2.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->Multiple projects (or project hierarchy) per user just to store secrets is not going to help as it will lead to project exposition and confusing. At the same time projects are not meant to go 1 to 1 with user.<o:p></o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span style="mso-list:Ignore">3.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';">      
</span></span><!--[endif]-->Project hierarchy is also not a good solution as user on top of the hierarchy (reseller admin) can inherits role and able to steal the secrets.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Note, Barbican is designed for secret storage and protection, we need better management on secrets in Barbican. We also need better solution to address this problem.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Keystone and Barbican (or interested party) team, can we have a meeting today to brainstorm this issue and come up with better solution?<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Thanks<o:p></o:p></p><p class="MsoNormal">Arvind  <o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p></div></div></div></blockquote></span></div></div></blockquote></span></body></html>