[rbac][keystone][kolla][osa][tripleo][charms] RBAC in Yoga for deployment projects
felipe.reyes at canonical.com
Mon Jan 24 20:30:14 UTC 2022
Hi Mark and all,
On Wed, 2022-01-19 at 10:35 +0000, Mark Goddard wrote:
> 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.
Thanks for highlighting this. In the Charms we are evaluating what
needs to be changed. On a first pass these are the changes needed that
were identified, it's an etherpad that's still evolving though :-)
> The secure RBAC work has a long history, and continues to evolve.
> According to , 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 , 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  with some notes, questions
> and half-baked plans. We made some changes in Xena  to use system
> scope in some places when interacting with system APIs in Ansible
> The next change we have staged is to add the service role to all
> service users , in preparation for .
> 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
> How does that line up with other projects' approaches? What have we
>  https://review.opendev.org/c/openstack/kolla-ansible/+/815577
Software Engineer @ Canonical
# Email: felipe.reyes at canonical.com (GPG:0x9B1FFF39)
# Launchpad: ~freyes | IRC: freyes
More information about the openstack-discuss