Open Stack

Hi,


(The topic doesn't include puppet but ...)
I recently spent some time implementing initial support for SRBAC
in Puppet OpenStack. You can find details in the etherpad[1] I created
as my working note. It includes some items commonly required by all toolings
in addition to ones specific to puppet.
 [1] https://etherpad.opendev.org/p/puppet-secure-rbac

I expect some of them (especially the configuration parameters) would be
used
by TripleO later.

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

I'd add one more question which is;
 Which roles should be assigned for the service users ?

In the project which already implemented SRBAC, system-admin + system-reader
allows any API calls and works like the previous project-admin.

For token validations system-reader(or service role) would be enough but
there are
some system-admin-only APIs (os-server-external-events API in nova called
by neutron,
Create allocation in placement called by nova or neutron) used for
communications
between services.

If we agree system-admin + system-reader is the right set then I'll update
the default role
assignment accordingly. This is important for Puppet OpenStack because
there are implementations
in puppet (which is usually called as providers) to manage some resources
like Flavors,
and these rely on credentials of service users after trying to look up user
credentials.

Takashi

On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard <mark at stackhpc.com> 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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220119/f5af363f/attachment-0001.htm>