Change Details

We need to decide on and update the permissions for the the WMCS-roots and wmcs-admins groups. The convention we have in the admin data.yaml file is that `$group-roots` are more powerful then `$group-admins`, however it seems that in the WMCS case this is not strictly true. From what I can tell the `wmcs-roots` group is used to give sudo root access to a bunch of wmcs hosts but not all of them. The `wmcs-admins` group is used to allow users to manage wikireplicas specifically it allows users to run: * cluster::management ** /usr/local/bin/secure-cookbook sre.wikireplicas * wmcs::db::wikireplicas ** /usr/local/sbin/maintain-views', ** /usr/local/sbin/maintain-meta_p', ** /usr/local/sbin/maintain-replica-indexes' Currently the members of the `wmcs-roots` and `wmcs-admin` groups are almost identical, the only difference being that @taavi is in the former and not the later. I created a [[ https://gerrit.wikimedia.org/r/c/operations/puppet/+/923684/1/modules/admin/data/data.yaml#808 | change ]] to add `wmcs-roots` to the `wmcs-admins` group. However this would give `wmcs-roots` access to production hosts, in particulate the cumin hosts (arguably the most powerful production hosts) and we have not previously considered this access before. Further it would allow wmcs-roots to preform the above maintenance tasks on the db wiki hosts, possibly less of a concern but would still need someone with knowledge to confirm if this is acceptable. For the `sre.wikireplicas.*` use case I wonder if these cookbooks could be run from the cloudcumin hosts instead of the cumin hosts, then we can simply drop `wmcs-roots` access from `cluster::managment` Also when looking at the `wmcs-roots` group I noticed that it does not have access to all wmcs machines, I believe that the ultimate goal is that wmcs engineers could perform 100% of their role with `wmcs-roots` and would in theory be able to drop global ops membership some time in the future. As such I think we should try and ensure that the `wmcs-roots` group does have the necessary access. I have created a [[ https://gerrit.wikimedia.org/r/c/operations/puppet/+/923681 | change ]] to add what seems to me to be the obvious ones but suspect its missing some. @nskaggs please add, correct or update anything I may have missed .

We need to decide on and update the permissions for the the WMCS-roots and wmcs-admins groups. The convention we have in the admin data.yaml file is that `$group-roots` are more powerful then `$group-admins`, however it seems that in the WMCS case this is not strictly true. From what I can tell the `wmcs-roots` group is used to give sudo root access to a bunch of wmcs hosts but not all of them. The `wmcs-admins` group is used to allow users to manage wikireplicas specifically it allows users to run: * cluster::management ** /usr/local/bin/secure-cookbook sre.wikireplicas * wmcs::db::wikireplicas ** /usr/local/sbin/maintain-views', ** /usr/local/sbin/maintain-meta_p', ** /usr/local/sbin/maintain-replica-indexes' Currently the members of the `wmcs-roots` and `wmcs-admin` groups are almost identical, the only difference being that @taavi is in the former and not the later. I created a [[ https://gerrit.wikimedia.org/r/c/operations/puppet/+/923684/1/modules/admin/data/data.yaml#808 | change ]] to add `wmcs-roots` to the `wmcs-admins` group. ~~However this would give `wmcs-roots` access to production hosts, in particulate the cumin hosts (arguably the most powerful production hosts) and we have not previously considered this access before~~. It would allow wmcs-roots to preform the above maintenance tasks on the db wiki hosts, possibly less of a concern but would still need someone with knowledge to confirm if this is acceptable. For the `sre.wikireplicas.*` use case I wonder if these cookbooks could be run from the cloudcumin hosts instead of the cumin hosts, then we can simply drop `wmcs-admin` access from `cluster::managment` Also when looking at the `wmcs-roots` group I noticed that it does not have access to all wmcs machines, I believe that the ultimate goal is that wmcs engineers could perform 100% of their role with `wmcs-roots` and would in theory be able to drop global ops membership some time in the future. As such I think we should try and ensure that the `wmcs-roots` group does have the necessary access. I have created a [[ https://gerrit.wikimedia.org/r/c/operations/puppet/+/923681 | change ]] to add what seems to me to be the obvious ones but suspect its missing some. @nskaggs please add, correct or update anything I may have missed .

We need to decide on and update the permissions for the the WMCS-roots and wmcs-admins groups. The convention we have in the admin data.yaml file is that `$group-roots` are more powerful then `$group-admins`, however it seems that in the WMCS case this is not strictly true. From what I can tell the `wmcs-roots` group is used to give sudo root access to a bunch of wmcs hosts but not all of them. The `wmcs-admins` group is used to allow users to manage wikireplicas specifically it allows users to run: * cluster::management ** /usr/local/bin/secure-cookbook sre.wikireplicas * wmcs::db::wikireplicas ** /usr/local/sbin/maintain-views', ** /usr/local/sbin/maintain-meta_p', ** /usr/local/sbin/maintain-replica-indexes' Currently the members of the `wmcs-roots` and `wmcs-admin` groups are almost identical, the only difference being that @taavi is in the former and not the later. I created a [[ https://gerrit.wikimedia.org/r/c/operations/puppet/+/923684/1/modules/admin/data/data.yaml#808 | change ]] to add `wmcs-roots` to the `wmcs-admins` group. ~~However this would give `wmcs-roots` access to production hosts, in particulate the cumin hosts (arguably the most powerful production hosts) and we have not previously considered this access before~~. Further itIt would allow wmcs-roots to preform the above maintenance tasks on the db wiki hosts, possibly less of a concern but would still need someone with knowledge to confirm if this is acceptable. For the `sre.wikireplicas.*` use case I wonder if these cookbooks could be run from the cloudcumin hosts instead of the cumin hosts, then we can simply drop `wmcs-rootsadmin` access from `cluster::managment` Also when looking at the `wmcs-roots` group I noticed that it does not have access to all wmcs machines, I believe that the ultimate goal is that wmcs engineers could perform 100% of their role with `wmcs-roots` and would in theory be able to drop global ops membership some time in the future. As such I think we should try and ensure that the `wmcs-roots` group does have the necessary access. I have created a [[ https://gerrit.wikimedia.org/r/c/operations/puppet/+/923681 | change ]] to add what seems to me to be the obvious ones but suspect its missing some. @nskaggs please add, correct or update anything I may have missed .