Open Stack

On Wed, 19 Jan 2022 at 19:38, Dmitriy Rabotyagov <noonedeadpunk at ya.ru> wrote:
>
> - все
>
> Hi!
>
> In OSA I've already started topic [1] quite a while ago, that adds service role in addition to admin one for the migration purposes.
> It was intended, that admin can be revoked later on if needed.
>
> So I based on my understanding of the thread, that is exactly the plan for keystone as well.
>
>
> [1] https://review.opendev.org/q/topic:%22osa%252Fservice_tokens%22+(status:open%20OR%20status:merged)

Hi Dmitriy,

Thanks for the update. I see that those patches are adding the service
role. They're also configuring service tokens, which IIUC are
unrelated, and allow for long-running operations to outlive the
original user's token lifetime. Is it intentional?

Mark

>
> 19.01.2022, 12:43, "Mark Goddard" <mark at stackhpc.com>:
>
> Hi,
>
> If you haven't been paying close attention, it would be easy to miss
> some of the upcoming RBAC changes which will have an impact on
> deployment projects. I thought I'd start a thread so that we can share
> how we are approaching this, get answers to open questions, and
> ideally all end up with a fairly consistent approach.
>
> The secure RBAC work has a long history, and continues to evolve.
> According to [1], we should start to see some fairly substantial
> changes over the next few releases. That spec is fairly long, but
> worth a read.
>
> In the yoga timeline [2], there is one change in particular that has
> an impact on deployment projects, "3. Keystone enforces scope by
> default". After this change, all of the deprecated policies that many
> still rely on in Keystone will be removed.
>
> In kolla-ansible, we have an etherpad [5] with some notes, questions
> and half-baked plans. We made some changes in Xena [3] to use system
> scope in some places when interacting with system APIs in Ansible
> tasks.
>
> The next change we have staged is to add the service role to all
> service users [4], in preparation for [2].
>
> Question: should the role be added with system scope or in the
> existing service project? The obvious main use for this is token
> validation, which seems to allow system or project scope.
>
> We anticipate that some service users may still require some
> project-scoped roles, e.g. when creating resources for octavia. We'll
> deal with those on a case by case basis.
>
> In anticipation of keystone setting enforce_scope=True and removing
> old default policies (which I assume effectively removes
> enforce_new_defaults?), we will set this in kolla-ansible, and try to
> deal with any fallout. Hopefully the previous work will make this
> minimal.
>
> How does that line up with other projects' approaches? What have we missed?
>
> Mark
>
> [1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst
> [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#yoga-timeline-7th-mar-2022
> [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1de924f3978fb81a7
> [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577
> [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
>
>
>
>
> --
> Kind Regards,
> Dmitriy Rabotyagov
>