Hi. I had added an item for this: https://bugs.launchpad.net/magnum/+bug/1752433
after the last reply and a bit of searching around. It's not urgent but we already got a couple cases in our deployment. Cheers, Ricardo On Thu, Mar 1, 2018 at 3:44 PM, Spyros Trigazis <strig...@gmail.com> wrote: > Hello, > > After discussion with the keystone team at the above session, keystone > will not provide a way to transfer trusts nor application credentials, > since it doesn't address the above problem (the member that leaves the team > can auth with keystone if he has the trust/app-creds). > > In magnum we need a way for admins and the cluster owner to rotate the > trust or app-creds and certificates. > > We can leverage the existing rotate_ca api for rotating the ca and at the > same > time the trust. Since this api is designed only to rotate the ca, we can > add a cluster action to transter ownership of the cluster. This action > should be > allowed to be executed by the admin or the current owner of a given cluster. > > At the same time, the trust created by heat for every stack suffers from the > same problem, we should check with the heat team what is their plan. > > Cheers, > Spyros > > On 27 February 2018 at 20:53, Ricardo Rocha <rocha.po...@gmail.com> wrote: >> >> Hi Lance. >> >> On Mon, Feb 26, 2018 at 4:45 PM, Lance Bragstad <lbrags...@gmail.com> >> wrote: >> > >> > >> > On 02/26/2018 10:17 AM, Ricardo Rocha wrote: >> >> Hi. >> >> >> >> We have an issue on the way Magnum uses keystone trusts. >> >> >> >> Magnum clusters are created in a given project using HEAT, and require >> >> a trust token to communicate back with OpenStack services - there is >> >> also integration with Kubernetes via a cloud provider. >> >> >> >> This trust belongs to a given user, not the project, so whenever we >> >> disable the user's account - for example when a user leaves the >> >> organization - the cluster becomes unhealthy as the trust is no longer >> >> valid. Given the token is available in the cluster nodes, accessible >> >> by users, a trust linked to a service account is also not a viable >> >> solution. >> >> >> >> Is there an existing alternative for this kind of use case? I guess >> >> what we might need is a trust that is linked to the project. >> > This was proposed in the original application credential specification >> > [0] [1]. The problem is that you're sharing an authentication mechanism >> > with multiple people when you associate it to the life cycle of a >> > project. When a user is deleted or removed from the project, nothing >> > would stop them from accessing OpenStack APIs if the application >> > credential or trust isn't rotated out. Even if the credential or trust >> > were scoped to the project's life cycle, it would need to be rotated out >> > and replaced when users come and go for the same reason. So it would >> > still be associated to the user life cycle, just indirectly. Otherwise >> > you're allowing unauthorized access to something that should be >> > protected. >> > >> > If you're at the PTG - we will be having a session on application >> > credentials tomorrow (Tuesday) afternoon [2] in the identity-integration >> > room [3]. >> >> Thanks for the reply, i now understand the issue. >> >> I'm not at the PTG. Had a look at the etherpad but it seems app >> credentials will have a similar lifecycle so not suitable for the use >> case above - for the same reasons you mention. >> >> I wonder what's the alternative to achieve what we need in Magnum? >> >> Cheers, >> Ricardo >> >> > [0] https://review.openstack.org/#/c/450415/ >> > [1] https://review.openstack.org/#/c/512505/ >> > [2] https://etherpad.openstack.org/p/application-credentials-rocky-ptg >> > [3] http://ptg.openstack.org/ptg.html >> >> >> >> I believe the same issue would be there using application credentials, >> >> as the ownership is similar. >> >> >> >> Cheers, >> >> Ricardo >> >> >> >> >> >> __________________________________________________________________________ >> >> 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 >> > >> > >> > >> > >> > __________________________________________________________________________ >> > 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 >> > >> >> __________________________________________________________________________ >> 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 > > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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