| Zabe | |
| Feb 3 2023, 10:35 AM |
| F36862803: Screenshot 2023-02-20 at 17.31.25.png | |
| Feb 20 2023, 5:31 PM |
| F36862802: Screenshot 2023-02-20 at 17.31.19.png | |
| Feb 20 2023, 5:31 PM |
As I learned in T326752, members of acl*sre-team are allowed to edit acl*security and thus can join any of it's subprojects.
Thus I propose to require 2FA to be enabled for members of acl*sre-team, since we require 2FA to be enabled for members of acl*security.
Can we just remove acl*sre-team's managing rights for acl*security? Most existing members of SRE are already on acl*security_sre, which they can directly manage and which controls access to acl*security. I don't really see the benefit of having acl*sre-team being able to directly manage acl*security as well, especially since this is the only policy relationship like this that I'm (now) aware of. The original intent of adding all of the acl*security sub-team policies was to allow various teams to manage their own access lists as trusted members of acl*security and to avoid situations like this.
Hello @Reedy and @Aklapper - as you both have administrative privileges in Phabricator, could you assist us in revoking the acl*sre-team ability to make changes to acl*security?
The Security-Team would like to manage this through the SRE sub policy in the future.
I can't edit acl*sre-team; Members of the project "acl*sre-team" can take this action....
But for acl*security, before:
After:
@sbassett / @mmartorana: As @Reedy made changes in T328746#8630441 (thanks!), is there anything else to do in this ticket (if yes, what exactly?) or can the status of this task be changed to resolved? Thanks!
Let's confirm with a member or two of SRE that they can no longer edit acl*security. I've added their tag so hopefully this can be a quick thing they can check during their clinic.