[Beaker-devel] Some thoughts on system access policies

Dan Callaghan dcallagh at redhat.com
Wed Jul 31 03:35:19 UTC 2013


Excerpts from Nick Coghlan's message of 2013-07-31 11:39:46 +1000:
> Putting these thoughts in email form so Dan can either take them into
> account when rewriting the system pools proposals, or else suggest areas
> which seem like unneeded complexity. For example, with ad hoc groups,
> maybe we don't need system pools as a separate notion for tagging
> purposes (just create a group instead). They're all only half-formed
> notions, so definitely take them with a rather large grain of salt :)
> 
> Firstly, I'm thinking that we should ensure the system <-> access policy
> relationship is always one-to-one. Anything else will be too confusing.
> If we decide to later implement a tagging system for referring to kinds
> of systems, that should be a separate thing independent of access policies.

Agreed. I still think that the original reasoning behind system pools 
was valid, which is that people want to group systems into arbitrary 
collections which are not (necessarily) correlated with user groups, 
for:
* purely informational purposes ("these are all inside the wifi tent", 
  "these are out of warranty and should be discarded", ...)
* scheduling purposes
* applying a consistent access policy across the collection
* other purposes which I don't recall, or which we don't know of?

The above purposes sometimes overlap, but not always, and it might be 
a mistake to try and cover all of them with the one concept of "system 
pools". This conflict (a system having multiple access policies does not 
make sense, but a system being in multiple scheduling pools *does* make 
sense) is just one indication that we are trying to over-generalise.

> I'm contemplating up to four different "kinds" of access policy:
> 
> - system access policy. Just a transition mechanism from the current
> system level permissions, these will be created automatically as part of
> the data migration from the legacy access model. These would be
> represented in the UI as a "Custom access policy".
> 
> - user access policy. The default access policy applied to systems owned
> by a particular user if no other policy is nominated. Can only be edited
> by the user themselves.
> 
> - group access policy. An access policy controlled by the owners of a
> particular group. System owners may switch the access policy from an
> implicitly created system policy or their user policy over to a group
> access policy.
> 
> - pool access policy. An access policy independent of any particular
> group. In a certain sense, system access policies are an example of
> this, using a pool containing exactly one system.
> 
> As part of this, I'm wondering if we want to borrow the *nix account
> management notion of creating an implicit group for each user, where
> they're the group owner and only member. Then we can require that access
> policies have an "owning group", and for user access policies, this
> would be the user's implicit group. Similarly, for custom access
> policies, the policy owner would be the system owner's implicit group. I
> suspect there are trade-offs either way (modelling user-owned policies +
> group-owned policies separately, or introducing an implicit group for
> each user), but it's something we should deliberately consider.

I don't think it's necessary that a policy have any kind of owner. The 
ability to modify the policy would be controlled by a permission on the 
policy itself (``edit-policy`` below). The system owner controls what 
policy applies to their system.

(I also think Beaker's current requirement that every system have 
exactly one owner is not adequate, but I don't think we should try and 
tackle that right now.)

What if "predefined access policies" were first class named entities, 
not tied to anything else? The custom access policies for each system 
which be represented in the same table, but as anonymous, hidden 
policies referencing a single system. So the UI at the system level 
would be: pick a predefined policy from the list, create a new named 
policy, or make a custom one for this system. Then users can set up 
predefined policies associated with whatever they want ("Company-wide 
shared systems", "Kernel QE hardware", "dcallagh's systems").

So this is essentially back to the system pools idea, except only for 
access control purposes, not trying to conflate all the other different 
purposes.

> In terms of permissions, the list in the current system pools proposal
> looks pretty good:
> 
>     edit system details (edit-system)
>     loan system to anyone (loan-any)
>     loan system to self (loan-self)
>     issue power and provisioning commands (control-system)
>     implicitly schedule recipes on the system when submitting jobs
> (schedule-recipe)
>     reserve system manually (via web UI or bkr client) (reserve-manual)

The last two are really equivalent, it just depends whether the system 
is set to run scheduled jobs (Automated) or must be manually reserved 
(Manual). I had merged them into one permission ``reserve`` in my patch.

> However, we may want to consider some additions:
> 
>     edit access policy (edit-policy)
>     switch access policy (switch-policy)
>     explicitly request the system when submitting jobs (schedule-explicit)
> 
> edit-policy refers to changing the policy itself. If we don't add it,
> updates would be limited to the owning user (for user access policies)
> or owners of the owning group (for group access policies)

As above, I think edit-policy is good, and should obviate the need for 
an explicit "owner" of the policy.

> switch-policy refers to changing the access policy on a system to a
> different policy. If we don't add it, updates would be limited to the
> system owner.

I'm not sure this makes sense. It feels like escaping the permission 
system. In any case, I think we could safely defer it for now.

> schedule-explicit gets us back to the notion of having systems in the
> general pool that are available to the scheduler, but only when
> explicitly requested in the job XML. This extra field would allow you to
> have a policy where "schedule-recipe" was empty (so the system would
> never be used automatically), but we could add new features to the job
> XML to override the normal rules. Since there would need to a lot of
> other supporting changes to make this happen, it should be a deferred
> feature, but it's something to keep in mind as a future enhancement that
> may guide the underlying implementation details.

I think "schedule-explicit" is an interesting idea but it's really 
orthogonal to the access policy. It's more about what kinds of 
reservations the system will allow: so, not *who* is permitted to 
reserve, but rather *how* they are permitted to reserve it. We are 
already using the Condition field (Broken, Automated, Manual) for that. 
There is also the Type field which serves a similar purpose (requires 
explicitly opting it to the system) but by a completely different 
mechanism. So I think these need to be generalised/simplified rather 
than adding yet another different mechanism through the access policy.

-- 
Dan Callaghan <dcallagh at redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/beaker-devel/attachments/20130731/85a23195/attachment.sig>


More information about the Beaker-devel mailing list