Open Stack

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.porto at gmail.com> wrote:

> Hi Lance.
>
> On Mon, Feb 26, 2018 at 4:45 PM, Lance Bragstad <lbragstad at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180301/b26f4d4b/attachment.html>