<div dir="ltr"><div>Hi,<br></div><div><br></div><div><br></div><div>(The topic doesn't include puppet but ...)<br></div><div>I recently spent some time implementing initial support for SRBAC</div><div>in Puppet OpenStack. You can find details in the etherpad[1] I created</div><div>as my working note. It includes some items commonly required by all toolings</div><div>in addition to ones specific to puppet.</div><div> [1] <a href="https://etherpad.opendev.org/p/puppet-secure-rbac" target="_blank">https://etherpad.opendev.org/p/puppet-secure-rbac</a></div><div><br></div><div>I expect some of them (especially the configuration parameters) would be used<br></div><div>by TripleO later.<br></div><div><br></div><div>> Question: should the role be added with system scope or in the<br>
> existing service project? The obvious main use for this is token<br>
> validation, which seems to allow system or project scope.</div><div><br></div><div>I'd add one more question which is;<br></div><div> Which roles should be assigned for the service users ?<br></div><div><br></div><div>In the project which already implemented SRBAC, system-admin + system-reader<br></div><div>allows any API calls and works like the previous project-admin.</div><div><br></div><div>For token validations system-reader(or service role) would be enough but there are</div><div>some system-admin-only APIs (os-server-external-events API in nova called by neutron,</div><div>Create allocation in placement called by nova or neutron) used for communications</div><div>between services.</div><div><br></div><div>If we agree system-admin + system-reader is the right set then I'll update the default role</div><div>assignment accordingly. This is important for Puppet OpenStack because there are implementations</div><div>in puppet (which is usually called as providers) to manage some resources like Flavors,</div><div>and these rely on credentials of service users after trying to look up user credentials.<br></div><div><br></div><div>Takashi<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 19, 2022 at 7:40 PM Mark Goddard <<a href="mailto:mark@stackhpc.com" target="_blank">mark@stackhpc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
If you haven't been paying close attention, it would be easy to miss<br>
some of the upcoming RBAC changes which will have an impact on<br>
deployment projects. I thought I'd start a thread so that we can share<br>
how we are approaching this, get answers to open questions, and<br>
ideally all end up with a fairly consistent approach.<br>
<br>
The secure RBAC work has a long history, and continues to evolve.<br>
According to [1], we should start to see some fairly substantial<br>
changes over the next few releases. That spec is fairly long, but<br>
worth a read.<br>
<br>
In the yoga timeline [2], there is one change in particular that has<br>
an impact on deployment projects, "3. Keystone enforces scope by<br>
default". After this change, all of the deprecated policies that many<br>
still rely on in Keystone will be removed.<br>
<br>
In kolla-ansible, we have an etherpad [5] with some notes, questions<br>
and half-baked plans. We made some changes in Xena [3] to use system<br>
scope in some places when interacting with system APIs in Ansible<br>
tasks.<br>
<br>
The next change we have staged is to add the service role to all<br>
service users [4], in preparation for [2].<br>
<br>
Question: should the role be added with system scope or in the<br>
existing service project? The obvious main use for this is token<br>
validation, which seems to allow system or project scope.<br>
<br>
We anticipate that some service users may still require some<br>
project-scoped roles, e.g. when creating resources for octavia. We'll<br>
deal with those on a case by case basis.<br>
<br>
In anticipation of keystone setting enforce_scope=True and removing<br>
old default policies (which I assume effectively removes<br>
enforce_new_defaults?), we will set this in kolla-ansible, and try to<br>
deal with any fallout. Hopefully the previous work will make this<br>
minimal.<br>
<br>
How does that line up with other projects' approaches? What have we missed?<br>
<br>
Mark<br>
<br>
[1] <a href="https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst" rel="noreferrer" target="_blank">https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst</a><br>
[2] <a href="https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#yoga-timeline-7th-mar-2022" rel="noreferrer" target="_blank">https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#yoga-timeline-7th-mar-2022</a><br>
[3] <a href="https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1de924f3978fb81a7" rel="noreferrer" target="_blank">https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1de924f3978fb81a7</a><br>
[4] <a href="https://review.opendev.org/c/openstack/kolla-ansible/+/815577" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/kolla-ansible/+/815577</a><br>
[5] <a href="https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible</a><br>
<br>
</blockquote></div></div>