Open Stack

Hey all,

Several projects have made significant progress adopting default roles and
system-scope during the Wallaby cycle. One part of that work is obviously
testing and we've been stringing together various tempest jobs with the new
policies enabled to see what falls out. Ironic was working on some of this
last week and it led to an interesting discussion on Friday about how we
should handle system-scope with the current assumptions about administrator
(e.g., project-admin) workflows. The majority of the discussion took place
in IRC, but I tried to consolidate as much of the context as I could into
an etherpad [0].

I'm socializing the overall discussion so we can get feedback from users,
operators, and developers, as well as summarize some comparisons to other
systems.

Today, by default system administrators are anyone with the 'admin' role on
a project. These users are allowed to do things on behalf of users, like
rebooting an instance. This mostly works because the administrator's token
is project-scoped and the resource they're interacting with is owned by a
project. This assumption isn't true in the new default policies.

The question is, should system administrators, or users with system-scoped
tokens, be allowed to use those tokens to make changes to project-specific
resources (e.g., creating a private image in a project, rebooting an
instance, deleting a snapshot, etc)?

The general feeling was that, yes, system administrators should have the
ability to interact with resources owned by projects in their deployment.
The discussion then focused on how we actually make that happen. We came up
with three different solutions, all of which are detailed in the etherpad
[0], but I'll summarize them below.

Option 1: Let system-administrators exchange system-scoped (god-mode)
tokens for tokens scoped to a specific project without an explicit role
assignment on the project
Option 2: Require system-administrators to grant themselves authorization
on the project, obtain a new token, and perform the operation
Option 3: Allow system-administrators to use system-scoped tokens to
operate on project-specific resources

We're iterating through the pros and cons of each approach in the etherpad.
If you haven't taken a look, please do so and add your thoughts. If you're
an operator with an existing workflow, we want to hear your feedback.

My request for additional feedback aside, several people in the discussion
brought up comparison to other identity systems and frameworks (e.g., how
do kerberos admins usually handle this sort of thing? how would we fix this
if we were using OAuth 2.0/OIDC?)

I spent some time Friday thinking through what an OAuth 2.0 flow would look
like in OpenStack [1][2]. I don't think my findings were earth-shattering,
and I'm sure there are other ways we could implement OAuth 2.0 flows. While
adhering to a standard offers guidance and makes some things easier (like
integrating with other systems), I don't think it would be the silver
bullet for fixing our RBAC woes (at least not this late in the game).

OpenStack APIs are massive, complex, and operate at different parts of the
technology stack. Some of those APIs are meant for typical users just
requesting resources. Others are written with the system administrator as
the end user. OpenStack's explosive API and functionality growth out-paced
its authorization tools to protect it, allowing project_id to bake itself
into resources, services, and components (API code, middleware, database
layers). Relaxing the assumption of an always-present project ID in every
token is going to be hard and given OpenStack's distributed approach to
policy enforcement, truly fixing it would require consistency across the
entire ecosystem, regardless of the authentication or authorization
framework. Either way, I thought that was an interesting exercise, and I'm
curious if others have different opinions or perspectives on those findings.

Thanks for reading,

Lance

[0] https://etherpad.opendev.org/p/consuming-system-scope
[1] https://bit.ly/3cjUu6o My first few attempts at mapping this out were
wrong, but I left links to the early drafts in the etherpad
[2] I ignored a lot of assumptions about how clients interact with
OpenStack, or how middleware works. This was purely a thought-experiment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210316/1b9b79d3/attachment-0001.html>