Enhanced User Groups¶

Abstract¶

This proposal adds additional self-management capabilities for Beaker’s user groups, adding the ability for a job to be owned by a group, and submitting a job via a submission delegate.

Dependencies¶

None.

Proposal¶

Under Beaker’s current group design, all group management is carried out by Beaker administrators, and groups can own systems, but not jobs.

This proposal enhances the capabilities of the existing group model by:

• allowing users to manage their own groups, rather than requiring administrator involvement
• allowing administrators to create groups that are automatically derived from groups already defined in an LDAP server
• allowing jobs to be submitted on behalf of a group by group members.
• allowing jobs to be submitted by a submission delegate.

A Beaker user can be in zero or more groups, and any Beaker user may create a new group at any time. Group members may be marked as owners of that group, which grants additional permissions. The initial creator of a group is automatically marked as an owner at the time of creation.

All members of a group are able to submit jobs on behalf of the group, and have full access to modify jobs submitted on behalf of the group.

Jobs submitted on behalf of a group are called “group jobs”, while other jobs are called “single-user jobs”.

Submission delegates are able to submit jobs on behalf of a user, but are only able to modify the jobs they submit. A submission delegate does not gain access to modify other jobs that the user can modify.

General use cases¶

The primary use case for the additional features is to simply improve the scalability of Beaker usage in large organisations, by:

• removing the installation administrators as a bottleneck for group updates.
• making it possible to derive group membership directly from an LDAP server.
• allowing a team of submitters to share responsibility for a set of jobs, rather than limiting access to the specific user that carried out the actual submission.

In addition, these changes aim to make it easier for users to set up automated systems that submit jobs on their behalf (for example, as an event triggered by a successful build on a continuous integration server).

Proposed user interface¶

bkr group-create --display-name="My New Group" <mynewgroup>

bkr group-create --ldap <mygroup>

bkr group-members <mygroup>

bkr group-modify --display-name="My Group" <mynewgroup>

bkr group-modify --add-member=<someusername> <mygroup>

bkr group-modify --remove-member=<someusername> <mygroup>

bkr group-modify --grant-owner=<someusername> <mygroup>

bkr group-modify --revoke-owner=<someusername> <mygroup>

Pass the ``--job-group=somegroup`` option to a workflow command.

bkr group-modify --root-password=<thevalue>

bkr user-modify --add-submission-delegate=<someusername> [<username>]

bkr user-modify --remove-submission-delegate=<someusername> [<username>]

Impact on other existing features¶

Currently, group members have some limited control over single-user jobs submitted by members of the same group. This feature will be deemed deprecated and will be removed in a later release (probably Beaker 1.1). This should give users of any existing installations adequate opportunity to start explicitly marking jobs where group access is needed as group jobs.

Upgrading Existing Beaker Installations¶

All members of existing groups in a Beaker installation will be granted job modifications permissions for each group where they are a member.

This means that groups that already existed in a Beaker installations will not have any designated owners after the installation is upgraded. After upgrading, users and administrators of the Beaker installation will need to coordinate the initial allocation of ownership privileges to members of existing groups, as well as deciding which groups can be deleted and replaced with LDAP group references.

Rejected Ideas¶

An earlier iteration of the design used a “job modification” flag to allow group members that could only submit jobs, but not modify them. This approach was judged to be confusing, so has been replaced with the current submission delegation design (also see #952979 and this beaker-devel thread).

Deferred Features¶

These additional features are under consideration, but have been deliberately omitted in order to reduce the complexity of the initial iteration of the design:

• Adding other groups as members of a group (#554802). The initial iteration does not allow groups to be members of other groups, which introduces potential concerns about scalability in large organisations. A subgroups model, with an implementation based on the Closure Table design, would address this concern. If there’s time, we’ll look into adding this to 1.0, otherwise it will be considered for inclusion in 1.1.

  The draft web UI design is the same as that for managing group members, but using the “Sub-group” list instead of the “Members” list. For the CLI:

  bkr group-modify --add-subgroup=<groupname> <mygroup>
  bkr group-modify --remove-subgroup=<groupname> <mygroup>
  bkr group-modify --grant-owner-subgroup=<groupname> <mygroup>
  bkr group-modify --revoke-owner-subgroup=<groupname> <mygroup>
  bkr group-modify --grant-modify-jobs-subgroup=<groupname> <mygroup>
  bkr group-modify --revoke-modify-jobs-subgroup=<groupname> <mygroup>
  

  Beaker will not permit a group to be a member of another group if it forms a cycle.

  This feature will also make it possible to have an LDAP-defined group as part of a group that also allows manual addition of members through Beaker.

• Group descriptions. The display name only allows a short piece of text. Group descriptions could, for example, include external links or instructions on how to request group membership.

• User-level self service to request group membership (including the associated queue interface for group owners to approve/deny requests), or to remove yourself from groups. This capability is likely to be added in a later iteration. In the meantime, the list of group owners will be visible in the web UI.

• More fine-grained group permissions. The initial iteration has only three effective levels of access: job submission delegates, ordinary group members and group (co-)owners. It may be desirable to separate out the last level further in a future release:

  • Add/remove members (currently allowed for all co-owners)
  • Grant/revoke co-ownership (currently allowed for all co-owners)
  • Modify group display name and description (currently allowed for all co-owners)

  For ordinary members, it may also be desirable to separate out:

  • Ability to log into provisioned systems based on their SSH key (currently allowed for all group members with a public SSH key registered in Beaker)
  • Ability to ack/nack job results (currently allowed for all group members)
  • Ability to change the associated product (currently allowed for all group members)
  • Ability to change the job retention policy (currently allowed for all group members)
  • Ability to let submission delegates run jobs on group assets (currently allowed for all group members)

• Group deletion. The initial iteration does not allow groups to be deleted, or even hidden. If subgroup management is added, and the associated UI includes some form of list for group selection, then it is likely that group owners will be granted the ability to mark a group as hidden, so it doesn’t show up in such lists. Creating a usable UI for the Scheduler Integration for System Pools proposal may also lead to this feature being implemented.

• Default groups for job submission. The initial iteration always defaults to no group assocation for submitted jobs. It may be desirable to allow users to designate a “default group” for their jobs, such that members of that group will be granted access to their jobs if no other group is specified.

• Changing the group of a job after submission. While this is potentially useful in some respects, it will mean that the state of the provisioned systems (at least the set of authorized SSH keys and potentially the root password) will no longer match the nominated group. It may make more sense to allow additional groups to be granted edit access on the job.

• Updating the job matrix to allow limiting it to jobs submitted on behalf of a particular group. This would only be useful if irrelevant jobs were being submitted with relevant whiteboard settings, and there’s a straightforward usage policy based workaround (making the whiteboard entries used with the job matrix more specific).

submission delegate

A user that can submit and modify jobs on behalf of another user, and may or may not be a real user themselves (i.e they may be a service, script, etc).

submitting user

This is the user that is directly responsible for submitting a job, which may or may not be a submission delegate.

job owner

The actual owner of a job. In the absence of a submission submission delegate, this is the same as the submitting user.