<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard <<a href="mailto:mark@stackhpc.com">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">On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
><br>
> (The topic doesn't include puppet but ...)<br>
> I recently spent some time implementing initial support for SRBAC<br>
> in Puppet OpenStack. You can find details in the etherpad[1] I created<br>
> as my working note. It includes some items commonly required by all toolings<br>
> in addition to ones specific to puppet.<br>
>  [1] <a href="https://etherpad.opendev.org/p/puppet-secure-rbac" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/puppet-secure-rbac</a><br>
<br>
Thanks for responding, Takashi - that's useful.<br>
<br>
><br>
> I expect some of them (especially the configuration parameters) would be used<br>
> by TripleO later.<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>
> I'd add one more question which is;<br>
>  Which roles should be assigned for the service users ?<br>
><br>
> In the project which already implemented SRBAC, system-admin + system-reader<br>
> allows any API calls and works like the previous project-admin.<br>
<br>
IIUC the direction of travel has changed, and now the intention is<br>
that system-admin won't have access to project-scoped APIs.<br>
<br>
><br>
> For token validations system-reader(or service role) would be enough but there are<br>
> some system-admin-only APIs (os-server-external-events API in nova called by neutron,<br>
> Create allocation in placement called by nova or neutron) used for communications<br>
> between services.<br>
<br>
The token validation API has the following default policy:<br>
<br>
identity:validate_token: (role:reader and system_scope:all) or<br>
rule:service_role or rule:token_subject<br>
<br>
So system-reader, system-admin or service (any scope) should work. The<br>
spec suggests that the service role is intended for use by service to<br>
service APIs, in this case the credentials provided in the<br>
keystone_authtoken config. I would guess that system scope makes most<br>
sense here with the service role, although the rule suggests it would<br>
work with project scope and the service role.<br>
<br></blockquote><div>I noticed I ignored implied roles... Thanks for clarifying that. <br></div><div>I understand and I agree with this. Considering the intention of SRBAC this would fix</div><div>better with system-scoped, as you earlier mentioned but I'll defer to the others.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> If we agree system-admin + system-reader is the right set then I'll update the default role<br>
> assignment accordingly. This is important for Puppet OpenStack because there are implementations<br>
> in puppet (which is usually called as providers) to manage some resources like Flavors,<br>
> and these rely on credentials of service users after trying to look up user credentials.<br>
<br>
I think one of the outcomes of this work is that authentication will<br>
necessarily become a bit more fine-grained. It might not make sense to<br>
have the same role assignments for all users. To your example, I would<br>
say that registering flavors should be done by a different user with<br>
different permissions than a service user. In kolla-ansible we don't<br>
really register flavors other than for octavia - this is up to<br>
operators.<br></blockquote>My main concern was that some service users would require system-admin but</div><div class="gmail_quote">I should have read this part more carefully.</div><div class="gmail_quote"> <a href="https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#phase-2">https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#phase-2</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">So Assigning the service role (for the proper scope which is asked in the original thread)</div><div class="gmail_quote">is the right way to go. For the provider stuff I'll look into any available option to replace usage of service</div><div class="gmail_quote">user credential but that's specific to Puppet which we can ignore here in this discussion.</div><div class="gmail_quote"><br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> Takashi<br>
><br>
> 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>
>><br>
>> 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>
<br>
</blockquote></div></div>