[CentOS-devel] Central Auth: Group naming and Process Proposal

Thu Aug 6 08:04:19 UTC 2015
Thomas Oulevey <thomas.oulevey at cern.ch>


On 08/06/2015 08:47 AM, Sandro Bonazzola wrote:
>
>
> On Wed, Aug 5, 2015 at 10:01 PM, Brian Stinson <brian at bstinson.com
> <mailto:brian at bstinson.com>> wrote:
>
>     Hi All,
>
>     We're working on testing instances of FAS for storing our user/group
>     membership information used by the CBS. I'd like to talk about group
>     naming and the permissions model to get some input. The goal is to get
>     these discussions going so we can set up our test environment to mirror
>     what we'll roll out in production. Consider this a proposal, and please
>     send comments my way (on-list please!).
>
>     Groups will use the convention 'sig-<shortname>', for example: people in
>     the Cloud SIG will be members of the FAS group 'sig-cloud'. This
>     convention will allow push access in dist-git to any branch that starts
>     with sig-cloud (sig-cloud7, sig-cloud7-openstack,
>     sig-cloud7-openstack-juno) and grant build permissions under the SIG
>     tags
>     in Koji[0].
>
>     FAS has 3 types of membership in a group: Admin, Sponsor, and User.
>     All 3
>     levels will be granted commit/build permissions, while only Admins and
>     Sponsors can modify members of the group.
>
>     To match our permissions model[1], I propose:
>     - We populate the 'Accounts' (Global Admin) group with the members
>     of the
>        CentOS Board.
>     - The Board member responsible for each SIG will create the appropriate
>        SIG group in FAS
>     - The Board member will add him/herself as an admin of the group
>     - The Board member will sponsor the SIG Chair as a sponsor for the group
>     - From then on, the SIG Chair and Board member can sponsor others
>     into the
>        group as users (and optionally add more sponsors to the group)
>
>     Anyone have thoughts? Once we reach consensus, I'll get this written up
>     for the SIG wiki page.
>
>
> +1 on my side
>

+1 It looks good ; As a side note for koji we will need to have a 
permission that match the SIG ; the default permission for building is 
"build".

What we proposed is to have build-<signame> (build-cloud, build-nfv, 
build-virt ...) so we can match groups between FAS and Koji.

Now I don't think we want finer grained permission to project level e.g 
: build-<signame>-<project> (build-cloud-openstack) as everybody in a 
SIG should be trusted to do the right thing, however if there is some 
use case let us know.

This will be transparent to users, and add an extra security bit (no 
cross SIG errors) but we will need to sync FAS groups with Koji 
users/permissions.

-- 
Thomas Oulevey