<div dir="ltr">Hello,<br><br>After discussion with the keystone team at the above session, keystone<br>will not provide a way to transfer trusts nor application credentials,<br>since it doesn't address the above problem (the member that leaves the team<br>can auth with keystone if he has the trust/app-creds).<br><br>In magnum we need a way for admins and the cluster owner to rotate the<br>trust or app-creds and certificates.<br><br>We can leverage the existing rotate_ca api for rotating the ca and at the same<br>time the trust. Since this api is designed only to rotate the ca, we can<br>add a cluster action to transter ownership of the cluster. This action should be<div>allowed to be executed by the admin or the current owner of a given cluster.<br><br>At the same time, the trust created by heat for every stack suffers from the<br>same problem, we should check with the heat team what is their plan.<br><br>Cheers,<br>Spyros   </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 February 2018 at 20:53, Ricardo Rocha <span dir="ltr"><<a href="mailto:rocha.porto@gmail.com" target="_blank">rocha.porto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lance.<br>
<div><div class="h5"><br>
On Mon, Feb 26, 2018 at 4:45 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:<br>
><br>
><br>
> On 02/26/2018 10:17 AM, Ricardo Rocha wrote:<br>
>> Hi.<br>
>><br>
>> We have an issue on the way Magnum uses keystone trusts.<br>
>><br>
>> Magnum clusters are created in a given project using HEAT, and require<br>
>> a trust token to communicate back with OpenStack services -  there is<br>
>> also integration with Kubernetes via a cloud provider.<br>
>><br>
>> This trust belongs to a given user, not the project, so whenever we<br>
>> disable the user's account - for example when a user leaves the<br>
>> organization - the cluster becomes unhealthy as the trust is no longer<br>
>> valid. Given the token is available in the cluster nodes, accessible<br>
>> by users, a trust linked to a service account is also not a viable<br>
>> solution.<br>
>><br>
>> Is there an existing alternative for this kind of use case? I guess<br>
>> what we might need is a trust that is linked to the project.<br>
> This was proposed in the original application credential specification<br>
> [0] [1]. The problem is that you're sharing an authentication mechanism<br>
> with multiple people when you associate it to the life cycle of a<br>
> project. When a user is deleted or removed from the project, nothing<br>
> would stop them from accessing OpenStack APIs if the application<br>
> credential or trust isn't rotated out. Even if the credential or trust<br>
> were scoped to the project's life cycle, it would need to be rotated out<br>
> and replaced when users come and go for the same reason. So it would<br>
> still be associated to the user life cycle, just indirectly. Otherwise<br>
> you're allowing unauthorized access to something that should be protected.<br>
><br>
> If you're at the PTG - we will be having a session on application<br>
> credentials tomorrow (Tuesday) afternoon [2] in the identity-integration<br>
> room [3].<br>
<br>
</div></div>Thanks for the reply, i now understand the issue.<br>
<br>
I'm not at the PTG. Had a look at the etherpad but it seems app<br>
credentials will have a similar lifecycle so not suitable for the use<br>
case above - for the same reasons you mention.<br>
<br>
I wonder what's the alternative to achieve what we need in Magnum?<br>
<br>
Cheers,<br>
  Ricardo<br>
<div class="HOEnZb"><div class="h5"><br>
> [0] <a href="https://review.openstack.org/#/c/450415/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/450415/</a><br>
> [1] <a href="https://review.openstack.org/#/c/512505/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/512505/</a><br>
> [2] <a href="https://etherpad.openstack.org/p/application-credentials-rocky-ptg" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/application-credentials-<wbr>rocky-ptg</a><br>
> [3] <a href="http://ptg.openstack.org/ptg.html" rel="noreferrer" target="_blank">http://ptg.openstack.org/ptg.<wbr>html</a><br>
>><br>
>> I believe the same issue would be there using application credentials,<br>
>> as the ownership is similar.<br>
>><br>
>> Cheers,<br>
>>   Ricardo<br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>