[rbac][keystone][kolla][osa][tripleo][charms] RBAC in Yoga for deployment projects

Felipe Reyes 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:
> 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.

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 :-)

https://etherpad.opendev.org/p/charms-secure-rbac


> 
> 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
> 

-- 
Felipe Reyes
Software Engineer @ Canonical
# Email: felipe.reyes at canonical.com (GPG:0x9B1FFF39)
# Launchpad: ~freyes | IRC: freyes




More information about the openstack-discuss mailing list