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.
Cheers! Brian
[0]: http://wiki.centos.org/BrianStinson/GitBranchesandKojiTags [1]: http://wiki.centos.org/SpecialInterestGroup
On Wed, Aug 5, 2015 at 10:01 PM, Brian Stinson brian@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
Cheers! Brian
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 08/06/2015 08:47 AM, Sandro Bonazzola wrote:
On Wed, Aug 5, 2015 at 10:01 PM, Brian Stinson <brian@bstinson.com mailto:brian@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.
Note that Koji doesn't actually limit building, it limits tagging. So you can run scratch builds and skip-tag builds against any tag, regardless of permissions. You just can't tag those builds when they are done.
The 'build' permission in Koji is actually unused currently.
Tagging is limited on two levels in Koji. The basic level is the permission requirement that can be set for each tag. When this is set, only users with the required permission can tag or untag there.
The next level is to adjust the tag policy on the hub (in hub.conf). This gives you more flexibility, and allows for more complex logic, but updating the hub config is a little more complicated than just running some edit-tag commands. You can read more about Koji policies here: https://fedoraproject.org/wiki/Koji/Policies (unfortunately not a complete doc, but better than nothing)
I think syncing FAS groups data to CBS permissions sounds reasonable. Using permissions means you can just use the tag permission settings and not have to worry about hub policy.
On Thu, Aug 6, 2015 at 4:04 AM, Thomas Oulevey thomas.oulevey@cern.ch wrote:
On 08/06/2015 08:47 AM, Sandro Bonazzola wrote:
On Wed, Aug 5, 2015 at 10:01 PM, Brian Stinson <brian@bstinson.com mailto:brian@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 tomirror 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: peoplein 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 theappropriate 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 writtenup 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
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/08/15 22:01, Brian Stinson 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.
Cheers! Brian
So in that configuration, that also means that a SIG Chair has now more "power" but then also more responsabilities. As FAS will be a "self-service" user registration tool, it will be easy for someone to create an account, then be sponsorized within a SIG by a Chair, to then be able to build in Koji (against tags for that SIG) and also commit/push to the correct hierarchy on git.centos.org. I guess (and it's the common scenario now) that we don't want to restrict things like some people from a SIG being able to build only, and not commit to git, or the reverse, but if we want to do it, we can still filter on group membership, like this :
- - FAS TopLevel - SIG-$example - SIG-$example-build - SIG-$example-git
- --
Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab
-
Brian Stinson -
Fabian Arrotin -
Mike McLean -
Sandro Bonazzola -
Thomas Oulevey