Open Stack

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 <strigazi at 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.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
>
>
>
> __________________________________________________________________________
> 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
>